Unknown error "Handle2AgentReg"

[Rhevo]

Hi guys, I've been working for 4 years on Battles of Nayvimh, a hybrid RTS-RPG in which we are called to create our own custom army, and face increasing challenges, progressively unlocking new units and game mechanics.
The project is still work in progress, but I would like to share it on the community to have your impressions and suggestions according to your preferences.


The only thing that does not allow me to proceed is an unknown error: "Handle2AgentReg (.? AUHandle2AgentReg @ @) "; Usually after about 30 minutes of play, I get a crash with the following error, which makes the project unplayable.



The project is very large, there are more than 750 different types of units to choose from, and it implements a spellcrafting system with thousands of possibilities, all with a very well-edited general graphics. It's sad that you can't play it for that reason.

I trust in your help!


(it says "risorse di memoria disponibili insufficienti per eseguire il comando" that means "not enough memory to execute command")

Note: I've already tried many times to gradually disable map triggers to isolate the cause, but the project has hundreds of triggers and mechanics merged, and I was unable to trace the culprit. Plus the map loading time is very long, and for each test I am forced to widgetize the map, which takes about 15 minutes

 

[Dr Super Good]

What is the process size of Warcraft III shortly before the crash? If Warcraft III virtual memory address space size is 2-3GB then you likely have run out of memory due to it being a 32bit application.

 

[Rhevo]

What is the process size of Warcraft III shortly before the crash? If Warcraft III virtual memory address space size is 2-3GB then you likely have run out of memory due to it being a 32bit application.

- Starting WarcraftIII.exe: 79 Mb
- Showing my map preview ni map selection menu: 115 Mb
- Map loaded (press any key to continue): 747 Mb
- Battle starts (about 30 seconds from map initialization): 825 Mb
- After 15-20 minutes since the game started: 1,031 Mb
- 60 seconds before the game crashes: 1,263 Mb
- Warcraft III crashes, “Handle2AgentReg” error, ( 25 minutes since the game started): 1.300Mb

Iìm not enough prepared to understand clearly what's causing this problem.

 

[Dr Super Good]

I assume your computer has more than 1.4 GB of free memory (page file + physical memory - sum of all memory used by applications) and is a 64bit OS?

In any case I will ask around.

EDIT: Can you send me both the played version (widgitized?) as well as the unprotected version of the map? This is needed to test crash reproducibility in both versions as well as take other measurements before sending it to Blizzard to investigate. Please state clearly any user input required to recreate the crash, preferably the less the better.

 

[Rhevo]

I assume your computer has more than 1.4 GB of free memory (page file + physical memory - sum of all memory used by applications) and is a 64bit OS?

In any case I will ask around.

EDIT: Can you send me both the played version (widgitized?) as well as the unprotected version of the map? This is needed to test crash reproducibility in both versions as well as take other measurements before sending it to Blizzard to investigate. Please state clearly any user input required to recreate the crash, preferably the less the better.

Sure, i can share the maps to make tests and understand what's going on.

Anyway, i made other tests and i've noticed that each time WCIII process reaches 1.300 Mb, this Error happens. I've 16 GB RAM and a GTX 1080 video card, i don't think that's a hardware problem, and if the virtual memory dedicated to warcraft is about 2-3 GB, it's still strange that the game crashes when 1.3 GB is reached, I really don't know.


This is the link to the map download: MediaFire
(extract the first .rar archive and it will automatically extracts all files)

The game requires custom .mpq files to be played, so i had to create a .rar archive that includes all necessary files. Inside the .rar archive you can find a ReadMe that explains you what are the steps required to reach the crash circumstances.

 

[Dr Super Good]

Downloading all the files now.

The fact there are 4.8 GB of files here has me concerned that you are expecting Warcraft III to do more than it currently is capable of. Warcraft III can only reliably allocate 2GB of memory, with up to 4GB on 64bit OS. If it can actually do this before crashing is another question since the game was designed to run on much less than 512MB of RAM.

In any case I will look further into it over the next few days.

EDIT:

Please update to 1.30.4.11274. We cannot help solve crashes for old versions of Warcraft III. In your case the likely cause is that old versions of Warcraft III are not Large Address Aware so can only allocate under 2GB of memory yet between your mods and maps you have ~6GB of assets to use. The reason I am saying this is your mod appears to require replacing legacy MPQ files rather than being expanded as a file tree or using the special purpose mod MPQ file (sorry the file name escapes me at the moment). The MPQ files to replace no longer exist since Warcraft III migrated to CASC, hence them existing means your install of Warcraft III is not up-to-date.

 

[Rhevo]

Thanks for suggestions, anyway i don't think that the .mpq files are the problem, this error happens exactly at the same way if you use classic.mpq files.

Obviously my game is not designed for the classic .mpq files, then you'll see a lot of models are upscaled/subscaled and replaced by old ones used inappropriately, but the mod is still playable, and the game crash is still there.

Last time i tested the mod with the classic .mpq files, the wcIII process crashed when reached 1.231 Mb, that's approximatively the 1.3 Mb recurring limit.

if you want to test the game with the old .mpq files, you have to run this map: BON - old wc3

Currently i'm on 1.26 patch of WarcraftIII; I'd pass to the 1.30, but since my mod is designed for those custom .mpq files, i cannot replace those files if the new patched version uses CASC archives.

 

[pyf]

[...] old versions of Warcraft III are not Large Address Aware so can only allocate under 2GB of memory [...]

For the record, this restriction was removed by Blizzard since v1.30.1.

 

[Dr Super Good]

I will try running that map file in 1.30.4.11274 without any mods (as you have not provided any that are compatible) to see if the crash can be recreated.

 

[Rhevo]

I will try running that map file in 1.30.4.11274 without any mods (as you have not provided any that are compatible) to see if the crash can be recreated.

Last file i added is compatible with classic warcraft 3 .mpq files: BON - old wc3

this .w3x is compatible with 1.26, then should with 1.30

 

[Dr Super Good]

Although I was not able to recreate the crash. I did let the game run enough that it would have crashed in 1.26 because it had exceeded a virtual memory address size of 2GB (the limit for non large address aware applications).

As such my conclusion is the following.

• You use far too many large sized assets. As I was running without the 5 GB of additional assets mods. I can easily see it crashing a lot sooner after loading even just 1GB of them.
• Your map is extremely leaky. Either triggers are leaking trigger objects, or it is because you are effectively leaking units and items by placing far too many of them on the map faster than players can lose/destroy them.
• Your map is extremely buggy. I observed everything from so many items spawning in an area that my client froze for a minute to an exploit where by pressing stop repeatedly caused a unit to deal insane damage.

In any case the map loaded in ~25 seconds and started at 180 fps and a 1 GB virtual memory size. By the time I gave up playing waiting for the crash that did not happen, after ~50 minutes, the game was running sub 20 FPS with massive periodic stutter (times of 0 FPS) and over 2 GB virtual memory size.

I suggest the following actions.

• Update to 1.30.4.11274. Modern builds of Warcraft III are large address aware which gives one an extra 1 GB of virtual memory space to play with after factoring in CASC memory mapping overhead.
• Cut back on the amount of assets used. I suggest limiting to 2GB of custom assets maximum. Reducing texture quality might help with this.
• Totally overhaul the map. Greatly reduce the number of units on the map at any given time. Periodically remove items that are left on the ground. Optimize triggers. Fix memory leaks. After playing for 1 hour the game should still be running at over 100 fps odd and have no periodic stutter.

 

[Rhevo]

I suggest the following actions.

• Update to 1.30.4.11274. Modern builds of Warcraft III are large address aware which gives one an extra 1 GB of virtual memory space to play with after factoring in CASC memory mapping overhead.

I actually want update my WCIII to the latest version, the addictional virtual memory could resolve the problem by itself, but how can i do that if my whole project is based on custom .mpq files? is there a way to make the new game version to recognize .mpq files? Otherwise i'm stuck in 1.26.

 

[Dr Super Good]

I actually want update my WCIII to the latest version, the addictional virtual memory could resolve the problem by itself, but how can i do that if my whole project is based on custom .mpq files? is there a way to make the new game version to recognize .mpq files? Otherwise i'm stuck in 1.26.

You expand the MPQs into a flat file system with use local files registry setting set, or compact them into a single MPQ to take advantage of dedicated mod MPQ (which file name escapes me).

Use MPQEdit to manipulate files inside MPQs.

 

[Rhevo]

You expand the MPQs into a flat file system with use local files registry setting set, or compact them into a single MPQ to take advantage of dedicated mod MPQ (which file name escapes me).

Use MPQEdit to manipulate files inside MPQs.

You mean to import al the custom resources inside the .w3x file?

 

[Dr Super Good]

You mean to import al the custom resources inside the .w3x file?

That would also work on top of what was previously mentioned as long as the resources are less than 2GB in total.

No limit is the flat file system which uses "use local files" registry setting to replace or expand game files. One could have dozens of GB of files this way.

With a 2GB limit the dedicated mod MPQ file is another limited choice. This can augment existing MPQ files with asset data.

 

[Rhevo]

No limit is the flat file system which uses "use local files" registry setting to replace or expand game files. One could have dozens of GB of files this way.

I'm afraid I'm not preparared enough to understand what does that means :S i'm not a professional

If i'm correctly understanding what you are suggesting me, the target is to recreate an archive external from .mpq files that my map can "call" externally as an extension of its own import manager, correct me if i'm wrong;

Currently i've already extracted all the files from my custom .mpqs, and i've put them all in a single directory, but now i don't know what's the next step, probably because i'm not understanding what does "flat file system" means.

 

[Dr Super Good]

If i'm correctly understanding what you are suggesting me, the target is to recreate an archive external from .mpq files that my map can "call" externally as an extension of its own import manager, correct me if i'm wrong;

Calling it does not really make any sense as there is no code from what I understand.

In any case the idea is to first enable local files. In regedit navigate to "Computer\HKEY_CURRENT_USER\Software\Blizzard Entertainment\Warcraft III" and then set Allow Local Files to a value of 1.

Now one can go about replacing data files using the standard file system of the Warcraft III install directory. For example, one currently removes the terrain raise/lower limits by replacing the MiscData.txt file. In newer versions of Warcraft III one places this file at "Warcraft III\war3.mpq\UI\MiscData.txt" in the Warcraft III install directory. Much like this file removes the terrain raise/lower limits from WorldEdit, other files can be placed in other folders to replace or augment files at the same path inside the CASC archive. Use CASCView to look up the internal folder structure of Warcraft III and extract your mod's MPQ file content into the appropriate new folders. RoC and TFT assets share a MPQ with all localized assets going inside the appropriate locale folders. This approach likely has no reasonable limit to the amount of data one can use, although it is not generally multiplayer compatible due to the use of modified data.

The other approach is to use the dedicated mod MPQ with at most 2GB of assets inside it. I recall people mentioning this in discussion about one of the patches however I am unsure what file name it is or even if it still is used since the migration to CASC.

 

[Rhevo]

Tnx for your help, Dr Super Good. I've still a lot to learn to solve this bug

 

[Rhevo]

You expand the MPQs into a flat file system with use local files registry setting set, or compact them into a single MPQ to take advantage of dedicated mod MPQ (which file name escapes me).

In another Hive post i've found:

"If you are using 1.28+, place all of the files you want to use inside of "War3Mod.mpq" and put it in your WC3 directory. If you are using a previous patch use "War3Patch.mpq".

Is this what you were trying to say abouth the "dedicated mod MPQ"?

 

[Dr Super Good]

Is this what you were trying to say abouth the "dedicated mod MPQ"?

Yes, if it still works since the CASC migration. That said War3Mod.mpq is limited to 2GB, possibly 4GB if it works using unsigned 32bit internally.

 

[Rhevo]

This CASC-conversion thing it's a misstep that creates distances between Warcraft3 game and modders, a comunity that have already created a lot of 3rd party softwares for the classic warcraft3 verison as 1.26. It comports unnecessary additional problems to who started big projects based on the original files organizations.

I've seen a lot of complaints about that on the Hive, and as a modder i can perfectly understand them. Regarding me for example, i've based my 4 year project on custom .mpq files, and obviously, who could imagine that now i've probably abandon my project? that's what happen when i try to open my custom .mpq on mpw viever:



How could i then create a custom .mpq that organizes files altered in such way?

This circumstances forces me to remain on the 1.26, and invite my comunity to downgrade their warcraft as is the only way to play my game.

 

[Dr Super Good]

I've seen a lot of complaints about that on the Hive, and as a modder i can perfectly understand them. Regarding me for example, i've based my 4 year project on custom .mpq files, and obviously, who could imagine that now i've probably abandon my project? that's what happen when i try to open my custom .mpq on mpw viever:



How could i then create a custom .mpq that organizes files altered in such way?

Looks like you lost your list file, or are not loading the MPQ with the appropriate list file. This is your problem since you were the one who edited the MPQs. If I was making a mod I would keep a copy of the contents of the mod in the appropriate native file system folder structure.

This circumstances forces me to remain on the 1.26, and invite my comunity to downgrade their warcraft as is the only way to play my game.

This will almost certainly kill the player base for your project. You cannot expect people to not upgrade, especially with more features being added.

I suggest also looking into why your map is leaking 100MB of memory every 5 minutes. Solving this might make it considerably more stable. Additionally if you want to stick with 1.26 you will need to delete a lot of your mod assets since the 2GB memory limit includes all loaded assets. You will want to reduce from 6GB odd of custom content down to 1GB or less. This is less of a concern for newer versions of Warcraft III which can use up to 4GB of memory (although less is possible). With Reforged it will likely be a non issue as hopefully it will be native 64bit so support a unreasonable amount of memory.

 

[Rhevo]

Sorry, the circumstances are little bit different, I haven't specified that the custom .mpq files i'm using are not made by me, then those listfile that you are talking about could have been intentionally removed by their creator, and obviously that's an aspect of which i've never had to consider, since there was no evidence that blizzard would completely revolutionize the archive organizations suddenly.

Therefore i expect you understand the frustation of who like me, worked for a lot of years on a project based on aspects that never had to discuss, such the .mpq archive system.

Regarding the enormous leak of memory, i'm currently working on it, even if i'm having a lot of difficulties to understand what is causing it: you suggested to reduce the number of units/active instances that are simultaneously in-game, so i'm re-intending the game in this direction.
Anyway, those aspect doesn't solve the patch problem. You suggested me to pass to 1.30, but how can i do it if my entire project is based on such custom .mpqs?

 

[Dr Super Good]

since there was no evidence that blizzard would completely revolutionize the archive organizations suddenly.

People like myself have warned of this for nearly 3 years since work started back up on Warcraft III... StarCraft remastered was proof it was going to happen.

If they are based on the standard game archives, one can use the standard game listfiles to detect most (but not necessarily all) files. Even with Blizzard archives the patch.mpq never had a listfile. A list file is basically a list of file path strings to resolve against the MPQ archive hash table, so as long as you know the file path of most of the content, which you must since you were using the content, you can always make a custom listfile to resolve the archives against. In MPQEdit there is an option to open a MPQ file with a custom listfile, which is basically a line separated list of potential file paths. Listfiles do not need to contain just existing paths, any that do not exist so fail resolution against the hash table will be gracefully ignored from the results meaning that a master listfile with all known standard Warcraft III file paths could be used to make this process easier.

 

[Rhevo]

i'm not a starcraft player, nor a programmer or professional user, maybe you are all of those things. anyway, you are saying then that i could import a listfile (that should be a .txt or something?) inside those custom mpq to recreate their non-corrupted form?

 

[Dr Super Good]

anyway, you are saying then that i could import a listfile (that should be a .txt or something?) inside those custom mpq to recreate their non-corrupted form?

No I am saying you can load them with a listfile (MPQEdit gives you this option when doing an advanced MPQ open) to view the contents. No files are imported.

Technically the MPQ is not corrupt, it is just missing a listfile which is not mandatory anyway (patch.mpq never had one for example).

The listfile to use would be some complete Warcraft III one which had all standard file paths.

 

[Rhevo]

Ok, so while i open those custom .mpq i have to select something from this field in MPQedit?



i've selected (one by one )all the .txt that appears here that are inside the main WCIII directory, but nothing changes. am i trying in wrong way?

 

[Dr Super Good]

i've selected (one by one )all the .txt that appears here that are inside the main WCIII directory, but nothing changes. am i trying in wrong way?

Yeh you specify the path to a listfile containing all the Warcraft III standard path strings, and any custom ones you know of that were added by the mods. If you have a 1.26 install you can get most of these by extracting the listfiles from the MPQs and merging them. As mentioned earlier, patch.mpq never had a listfile so do not expect one from it, although third party ones might be available online.

 

[Rhevo]

Yeh you specify the path to a listfile containing all the Warcraft III standard path strings, and any custom ones you know of that were added by the mods. If you have a 1.26 install you can get most of these by extracting the listfiles from the MPQs and merging them. As mentioned earlier, patch.mpq never had a listfile so do not expect one from it, although third party ones might be available online.

Thanks for your help, i've been able to recover custom files from those custom mpq using the 1.26 listfile. I've installed patch 1.30, now i have both version installed. Since my custom files are more than 4 GB i've enabled local files via regedit on Computer\HKEY_CURRENT_USER\Software\Blizzard Entertainment\Warcraft III path.

Now i have opened the 1.30 Casc archive usinc Cascview, but it doesn't let me add files or create any directory. Can you explain me how to proceed?

 

[Dr Super Good]

Now i have opened the 1.30 Casc archive usinc Cascview, but it doesn't let me add files or create any directory. Can you explain me how to proceed?

Yeh you cannot modify the CASC local storage.

Instead place your files in a folder in the install directory. Specifically the Warcraft III\war3.mpq\ folder. For example when disabling editor terrain limits one places the file as Warcraft III\war3.mpq\UI\MiscData.txt. The "Warcraft III" folder is the install folder in those paths.

 

[Rhevo]

place your files in a folder in the install directory. Specifically the Warcraft III\war3.mpq\ folder. .

Then i have to create a custom .mpq? But how to solve the 2GB limit?

 

[Dr Super Good]

Then i have to create a custom .mpq? But how to solve the 2GB limit?

No you create a folder named "war3.mpq". It is not a file and has nothing to do with MPQ archives.

This is because it matches how the data is stored in the CASC archive. There is a logical folder named "war3.mpq" which all the data is placed in, which also has nothing to do with MPQ archives. The reason the folder has a mpq like name is likely for compatibility with internal code or something to do with how the migration was performed.

 

[Rhevo]

Interesting! so could i replace the classic warcraft 3 models with my custom ones, simply recreating their mpq path inside this "war3.mpq" directory, and putting my models in it, even if this is not an mpq?

For es. could i replace the classic warcraft 3 footman model with mine, creating a path like units/human/footman inside this special directory and putting my model in it?

Also, do i have to specify in thepath that the model was originally inside the mpq called "war3"? So war3/units/human/footman?

 

[Dr Super Good]

Interesting! so could i replace the classic warcraft 3 models with my custom ones, simply recreating their mpq path inside this "war3.mpq" directory, and putting my models in it, even if this is not an mpq?

For es. could i replace the classic warcraft 3 footman model with mine, creating a path like units/human/footman inside this special directory and putting my model in it?

In theory yes. It works for MiscData.txt for sure.

Also, do i have to specify in thepath that the model was originally inside the mpq called "war3"? So war3/units/human/footman?

Check the file paths using CASCView. Both RoC and expansion MPQ files were merged into the war3.mpq folder. The paths should still be the same however since this was designed to be backwards compatible with asset paths specified by old maps.

 

[Rhevo]

Some News:
As i said, m project crashes after 25 -30 minutes of game due to memory usage that increases from 800 Mb to 1350 MB.

That means that the memory is leaking away.

Considering that i can't understand why the game doesn't use the whole 2Gb dedicated (since it ALWAYS crashes when it uses barely 1.3 MB), i've worked for more than 1 year on removing the leaks via variables on unit groups, locations and special effects, everything that could leak is correctly structured via GUI, then the problem must be something else.

For testing purposes, i've created a trigger that spawns 25 different units with different models associated (obviously removing their location via GUI); each timethe trigger is fired, it removes the previous 25 units and creates 25 new random units. When the trigger is fired multiple (8 -10) times, the game crashes due to memory usage. this happens because each time, the memory usage increases by 100Mb!!! obviously that's not a problem of points leaking, since if this trigger was not correctly created it could not take so much memory for 25 points inside the map.

Really don't understanding the problem :/

 

[Dr Super Good]

Considering that i can't understand why the game doesn't use the whole 2Gb dedicated (since it ALWAYS crashes when it uses barely 1.3 MB)

I suspect you are reading the wrong measurement. Since the game for sure is using a lot more than 1.3 MB of memory, even getting to the main menu. For example it ran up to 2GB for me before I stopped playing.

then the problem must be something else.

From my brief play experience it felt like units and items were effectively leaking since more and more of them were piling up on the map faster than they could be removed by dying.

For testing purposes, i've created a trigger that spawns 25 different units with different models associated (obviously removing their location via GUI); each timethe trigger is fired, it removes the previous 25 units and creates 25 new random units. When the trigger is fired multiple (8 -10) times, the game crashes due to memory usage. this happens because each time, the memory usage increases by 100Mb!!! obviously that's not a problem of points leaking, since if this trigger was not correctly created it could not take so much memory for 25 points inside the map.

Is this with your multiple gigabytes of game assets? Warcraft III dynamically loads assets as required but does not unload them when not in use. As such loading random units will load in random assets and so increase memory usage with each iteration as more unit assets get loaded in.

If you think it is the trigger, you can post it.

 

[Rhevo]

I suspect you are reading the wrong measurement. Since the game for sure is using a lot more than 1.3 MB of memory, even getting to the main menu. For example it ran up to 2GB for me before I stopped playing.

Warcraft 3 starts with 80 Mb usage and raise at approximatively 800 Mb when my map starts, since it loads more than 10.000 files from the import manager. after 30 minutes of game, the Ram value i've indicated reaches 1250 - 1300 Mb. When this value is reached, the game always crashes and the "Handle2AgentReg" error appears. On my computers my map never reached more than 1250 - 1350 Mb without crashing. Currently i'musing a gaming laptop and WCIII is a 2002-2003 game, it's not a problem of hardware obviously.

Consider however that those are the results that i obtain on 1.26 patch. i've also patch 1.30, i've made some tests and the game crashes when it reaches 1.7 Gb instead of 1.3 Gb. That's why i'm saying that's odd for me that the game doesn't use all the dedicated memory. I've noticed however that on 1.30 the game starts to lag more and more, then stutters a lot, and then crashes at 1.7 Gb of RAM usage, while on 1.26 i cannot even see these problems becouse it crashes directly before showing any lag/stutter signs.

You said that on your computer my game reached more than 2GB of RAM usage, but the software was running while you were playing or it was running alone just after you have started my map? maybe this makes some differences?

From my brief play experience it felt like units and items were effectively leaking since more and more of them were piling up on the map faster than they could be removed by dying.

Since you suggested me this thing, i've created a trigger that shows how many instances are on the map each 2 seconds; according to my game architecture, the unit's number doesn't decrease, nor increases by much (max 20 - 30 units) since the game starts. the total amount of simultaneous units/items on the map cannot overcome 300 on my project, that should be an acceptable number of istances for WC3.

Is this with your multiple gigabytes of game assets?

Yeah i've tested it with both my custom .mpq and with standard .mpq files. For better comprehension, my custom assets are both in the .mpq and inside the import manager, and when the map loads with standard .mpq the memory usage when the game starts is much lower than 800 Mb, infact it is always 420 - 440 Mb. that means that the game last longer before crashing, but even with this solution the memory leaks away, faster and faster.

 

[Dr Super Good]

Consider however that those are the results that i obtain on 1.26 patch. i've also patch 1.30, i've made some tests and the game crashes when it reaches 1.7 Gb instead of 1.3 Gb. That's why i'm saying that's odd for me that the game doesn't use all the dedicated memory. I've noticed however that on 1.30 the game starts to lag more and more, then stutters a lot, and then crashes at 1.7 Gb of RAM usage, while on 1.26 i cannot even see these problems becouse it crashes directly before showing any lag/stutter signs.

The actual cause of the crash happens when the game tries to allocate a chunk of virtual memory pages when there is no such unallocated unfragmented chunk available within its virtual memory address space. As such one has to look at the "virtual size" and not the task manager memory figure.

For example getting Warcraft III to the main menu shows a "Memory" value of 97MB, but the application already has a virtual memory size of 523MB according to Process Explorer. The difference comes from the use of memory mapped IO with the CASC local storage.

If we add this 426 MB discrepancy to your 1.7GB operating "Memory" value one gets 2.1GB which is already past the point that a non large address aware 32bit application will crash and is in the danger zone for large address aware 32bit applications.

Since you suggested me this thing, i've created a trigger that shows how many instances are on the map each 2 seconds; according to my game architecture, the unit's number doesn't decrease, nor increases by much (max 20 - 30 units) since the game starts. the total amount of simultaneous units/items on the map cannot overcome 300 on my project, that should be an acceptable number of istances for WC3.

When I was playing there were a lot more than 30 units. One starts with more than 30 units from what I could tell. I also ended up with around 200+ items visible because at times some bug would suddenly make around 50-70 spawn for no reason, freezing the game for a good 30-60 seconds.

I suggest checking for handle index leaks. A well made map should not be incrementing the maximum handle value of newly created objects by a huge amount over time. If it does then either there are object leaks, or one is leaking handle indices (commonly caused by the local declared local agent variable reference counter leak on return bug which plagues some GUI actions and functions).

 

[Pyrogasm]

or one is leaking handle indices (commonly caused by the local declared local agent variable reference counter leak on return bug which plagues some GUI actions and functions).

For clarity and consistency, @Rhevo, this is exactly the memory leak I am talking about with my post in your other thread regarding visibility modifiers.

 

[Rhevo]

I suggest checking for handle index leaks. A well made map should not be incrementing the maximum handle value of newly created objects by a huge amount over time. If it does then either there are object leaks, or one is leaking handle indices (commonly caused by the local declared local agent variable reference counter leak on return bug which plagues some GUI actions and functions).

I barely understand this part, due my incompetence.. what does "handle index" means?

Surely you have centered the problem.. Unfortunately all what i'm able to do is removing leaks related to locations and unit groups via global variables :/

Is there a procedure that i could follow or a guide for better comprehension?

 

[Pyrogasm]

• Set UnitVariable = (last created unit) //or whatever
• Custom script: call BJDebugMsg(I2S(GetHandleId(udg_UnitVariable))) //change the variable name to match yours, keep udg_ prefix

This will print the 'handle id' of the unit that the variable is assigned to. It's like a serial number for objects in the wc3 engine, and it goes up as more objects are created. In theory, removing a unit from the map frees up its handleid to be re-used by something else, but with the return leak DSG mentioned that number actually doesn't get re-used. You can periodically print the handle id of a recently created unit to see if the game is recycling old handleids (the number goes up and down over time) or is giving them all new ones (the number always keeps going up) as a simple kind of test to see if you are leaking handleids.

 

[Rhevo]

Thank you! then i have to put this command on each trigger i've created? Or could i put this in a single trigger to register simply each unit that enters in playable map area?

Also, this works for units/items/destructables?

And what should i do if i find that handle id goes up continually?

 

[Pyrogasm]

It literally just shows a number on the screen. You use it wherever feels appropriate to you to keep track of the numbers and see what's changing. Yes you can use other variable types just use the right variable name in the custom script line.

 

[Rhevo]

It literally just shows a number on the screen. You use it wherever feels appropriate to you to keep track of the numbers and see what's changing. Yes you can use other variable types just use the right variable name in the custom script line.

ok, but what if i see the handle index goes on and then i find this is the cause of game crashes?

 

[Pyrogasm]

...then you try to fix the problem.

 

[Rhevo]

If the handle index grows too fast, is there some function that i have to use like for points and unit groups leaks? or should i do something else? Is usually the problem related to the amount of units/items that are in game simultaneously ? what do i have to consider as main cause of this kind of problem?

 

[Dr Super Good]

If the handle index grows too fast, is there some function that i have to use like for points and unit groups leaks?

It means either you are still leaking those kinds of objects, or you need to use custom functions which have the local declared local agent variable reference counter leak on return bug fixed. For example the GUI "Wait Game Time" action is known to have one such handle leak.

 

[Rhevo]

It means either you are still leaking those kinds of objects

could that be a syntax error related to function i enter "call RemoveLocation(udg_z_temp_point)"? maybe is "call RemoveLocation (udg_z_temp_point)" or "call RemoveLocation( udg_z_temp_point )"? and maybe this happen also for DestroyGroup?

you need to use custom functions which have the local declared local agent variable reference counter leak on return bug fixed.

Since i have no experience with jass, where can i find those custom functions to remove this kind of leak?

Also, if the "Wait X Seconds" function causes leak, how can i fix all the triggers that uses this function?

 

[Dr Super Good]

could that be a syntax error related to function i enter "call RemoveLocation(udg_z_temp_point)"? maybe is "call RemoveLocation (udg_z_temp_point)" or "call RemoveLocation( udg_z_temp_point )"? and maybe this happen also for DestroyGroup?

If there was a syntax error the map would not run.

Since i have no experience with jass, where can i find those custom functions to remove this kind of leak?

You need to learn JASS. This is why Warcraft III mapping is not as easy as one might think.

Also, if the "Wait X Seconds" function causes leak, how can i fix all the triggers that uses this function?

Only Wait Game Time leaks. The other is a native that does not leak as far as I am aware (TriggerSleepAction). That said one should avoid using it due to its real time net synced nature.

 

[Rhevo]

Is there a custom script just like "RemoveLocation()" to fix those leaks via GUI?

if not, then i imagine that the only thing that i can do to save my years of work is to learn Jass..

Effectively, i've tried in 3 different moments on these years to learn Jass, but i had a lot of difficulties to understand its main architecture.. that's because i worked for 4-5 years on GUI.

i'm willing to learn Jass, i've also tried using JassCraft for better code comprehension, but i really can't understand 90% of things currently.. when i see jass, my mind tries to read it like if it is a GUI trigger, searching codes to interpretate events, conditions, etc.. but can't understand where an event begins, where are conditions... i've read many tutorials but none of those was enough explicative for me to stop me from using using GUI..

Stalemate :/