• 🏆 Texturing Contest #33 is OPEN! Contestants must re-texture a SD unit model found in-game (Warcraft 3 Classic), recreating the unit into a peaceful NPC version. 🔗Click here to enter!
  • ✅ HD Level Design Contest #1 POLL is now OPEN! Check out the stunning visuals of the final entries. 🔗Click here to cast your vote!

[Crash] Memory use of Warcraft

Status
Not open for further replies.
Level 31
Joined
Jun 27, 2008
Messages
2,555
Hey.

Not sure if this is the place to post this, but here it goes.

I start Warcraft, processes analysis tells me it uses 400 MBs of memory. Then I play for several minutes, triggers doesn't contain any major leak, maybe few location leaks, nothing major at all. Game starts lagging, analysis tells 650 MBs used just in few minutes and from the past experience game crash when getting close to 2 GBs.

For another map I removed 90% of leaks, leaving few location leaks, so there are leaks, but nothing really big. It immediately starts eating up memory and crash in the long run.

Is this normal for Warcraft to keep gathering memory at this speed? Does every action have their effect on the memory no matter what? Is there something that could be done? Would setting 98 / 2000 windows compatability, that limits memory, work?

It is really frustrating to work many months on the project and realise it might not be playable.

If this is not normal and memory taken should always maintain its level when coding is flawless, I would like some really experienced person to take a close look at the map, because I got burnt by this in the past and I see the same coming.

Thank you.
 
Level 15
Joined
Oct 29, 2012
Messages
1,474
As far as I know, limiting memory may cause the game to crash, thus you have to really clean ALL the leaks, because some small leaks may be used over and over in the memory and then take useless space from it.
What I really recommend is to clean all leaks, that's the best you can do, and try to optimize your map, because I tested something which is, when I play my unprotected map the same happens, but after optimizing the usage of the memory will be OK.
 
I haven't ever checked that in particular. But there is probably a good way to test it. Copy & paste the map, and in the copied map, delete all the triggers. Then test it out and see how it impacts memory.

In general, yeah--Warcraft 3 isn't that great at managing memory. It will sometimes even render things off-screen, particularly destructables (source). It tends to climb a bit in memory, but it usually stabilizes for me at some point.

Also, for leak detection--it may help to use a handle counter. Mentioned here:
http://www.hiveworkshop.com/forums/general-mapping-tutorials-278/debugging-188204/
Now, handle counters aren't completely accurate. A lot of times they'll bounce between values. They are also a bit misleading for GUI triggers, since some GUI functions have unavoidable reference leaks (but they aren't leaking the actual object itself).

I would recommend testing those things out to diagnose the issue. The first one (testing a blank map) can have many implications: if it does not increase in RAM too much, then it is most likely the triggers causing an issue. If it does increase in RAM anyway, it may be a computer-specific issue (try having someone else test it) or in the worse case, you would have to reduce the graphic load. As for testing the handle counter, it may or may not imply leaks. If it is constantly increasing (even when you're just doing nothing), then it should be something to look into.
 
Level 12
Joined
Mar 13, 2012
Messages
1,121
Is this normal for Warcraft to keep gathering memory at this speed?
No it's not.

The best first approach is usually to use a handle counter like this:

JASS:
function HandleCount takes nothing returns nothing
    local location L = Location(0,0)
    call BJDebugMsg(I2S(GetHandleId(L)-0x100000))
    call RemoveLocation(L)
    set L = null
endfunction

//===========================================================================
function InitTrig_HandleCounter takes nothing returns nothing
    local trigger t = CreateTrigger()
    call TriggerRegisterTimerEvent(t,0.09,true)
    call TriggerAddAction(t,function HandleCount)
endfunction
Look whether it grows very large and if yes when.
 
Level 17
Joined
Jul 17, 2011
Messages
1,864
if youve coded a big project with gui triggers you deserve props and also to know that you have doomed your peoject :thumbs_up::thumbs_up:

anyway just follow what purge said delete all triggers and test it out if that does not work then there may be a bug with wc3 or its files may be corrupt
 
Level 31
Joined
Jun 27, 2008
Messages
2,555
For this memory detection I opened warcraft with window mode and opened the process analysis window beside and followed it carefully. I noticed some actions, for example clicking and firing some triggers does cost me 10-30 MBs of memory, but repeating the same action over and over does not cost me at all. Some actions took no memory, some did. Most surprising was that I was able to rise like 500 MBs of memety JUST by moving my mouse over units, not selecting anything, just moving mouse around the screen and it gathered this amount of memory and then stopped. What the hell? After a while it stopped gathering memory. Oh and when I just stand and do completely nothing, it doesn't take any memory at all. Then I used some custom spells and it costed me nothing. Reached 1.5 GB of memory, clicked quests window and it crashed. All this is big mystery for me. Must be the coding then I suppose even though it looks okay despite few location leaks.

GUI dooms big projects? Why? :(
 
Level 17
Joined
Jul 17, 2011
Messages
1,864
i suppose i cant link anything relatable but wc3 projects (especially large ones) require some real world programming concepts. this can be achieved with jass but gui is best kept for small time things, its hard to explain just think of gui as being very limiting when it comes to telling wc3 to do something, its kind of like trying to draw something with a really dull pencil, its gonna work but you cant touch up on the finer details or something like that ... anyway youd best get someone knowledgeable to take a look at your project i doubt youd get help this way
 
Level 31
Joined
Jun 27, 2008
Messages
2,555
But I made big projects in the past and all made in GUI, but it was quite successful and I managed to achieve all what I wanted without Jass. Except this issue of memory storage remained. I will try to get rid of ALL leaks before project expands too much, because right now not much is done, and then see what happens. I will use memory analysis to detect what action force that memory and see what I can do about it. All this Jass and other methods looks quite complex for me to be mastered in a short time.

But I will attach the map, feel free to take a look at the coding, it does have location leaks, but I doubt if that might be the case. Repeating the trigger does not increase memory, only for the first time, that's odd.
http://www.hiveworkshop.com/forums/pastebin.php?id=dp7vh1
 

Zwiebelchen

Hosted Project GR
Level 35
Joined
Sep 17, 2009
Messages
7,236
This behaviour is not normal. For example, I can play Gaias for hours (which is a massive map) and have the general memory usage only go up for a few megabytes...

There's some leaks related to the game engine that you can not fix, since it's part of WC3's internal coding:
1) special effects always leak, even if you destroy them they leave a (very) small footprint ... but that shouldn't cause memory to shoot up by 150 megs suddenly.
2) creating and destroying thousands of units or other highly interactive objects like destructables will make the memory usage go up (I suspect this is due to the game logging any actions for the replay) ... a unit recycler might be a solution if you have too many units created/destroyed (but that really shouldn't matter unless you make a tower defense map)
3) not really a leak, but memory can go up when certain objects (sounds, music, images, etc.) get used for the first time.

However, I think the much more likely cause for the memory clogging is ordinary leaks.
If you're short on time, only check the periodic triggers and enumerations and loops. A leak in those cases can have a huge impact.


I can only recommend starting to learn vJASS or getting a good programmer if you still rely on GUI. Fixing leaks in GUI is a pain in the ass and once you get used to JASS, you will notice that it's not only faster to write (no more clunky clicking), but also easier to read in most cases. When people show me giant GUI triggers, it often takes me several minutes to even understand what is going on there. With nicely structured vJass, that is almost never the case.
Plus, structs. You definitely want those structs...
People sometimes create these giant GUI trigger clusterfucks and then tell me that they don't have time to learn JASS. The thing is: those giant GUI triggers take hours to make, due to the annoying interface. An equivalent JASS code will only take several minutes to write. Plus it's much easier to debug.
 
Level 31
Joined
Jun 27, 2008
Messages
2,555
The most mind bugging thing was that I was able to store a ton of memory just by moving mouse around the screen over units without selecting, it store nothing when not moving.
I will try removing ordinary leaks and see what happens then. But yeah, GUI for complex systems is really a pain in the ass, the most painful part is creating variables and then applying, kills all the fun.

Weird, it is Jass that looks so complex for me, all those hundreds of lines in one place, wooh. Scares the shit out from me. And the idea that all must be hand written nails it.
I will try to learn some vJass, but I wonder how long it will take me to master the code and come up with equivalent systems as right now. I hope hours vs minutes is the case here, Zwiebelchen.

Thanks for the help, guys. And tutorial, almost got through half already. But I guess I will need much more of these, hehe.
 

Zwiebelchen

Hosted Project GR
Level 35
Joined
Sep 17, 2009
Messages
7,236
Weird, it is Jass that looks so complex for me, all those hundreds of lines in one place, wooh. Scares the shit out from me. And the idea that all must be hand written nails it.
Apples and oranges here, really. The only reason you see all those lines and confusing data structures is that the systems you are looking at usually try to accomplish something that is a lot more complex than what you would do with GUI.

The beauty about vJass (compared to GUI) is that it allows you to automate stuff by writing your own modules and libraries.
This idea behind this method of creating content is that you organize your objectives and break it down into repeatables, then write data structures to automate those repeatables.

Where in GUI, you'd endlessly copy and paste the same triggers over and over again with minimal adjustments, in JASS you'd just write a single function with input parameters and then just pass the parameters over to the function. Don't repeat yourself (DRY) is the basic principle of programming.

It sounds counter intuitive at first, but the better you get with coding, the less code you will actually produce.

Take for example an advanced spell that fires a missile, damages all enemies in a line-shaped AoE based on the intelligence of the hero, then reduce the armor of enemies for 10 seconds.
If you would try to create something like this in GUI, you'd need dozens of triggers just for the basic functionality. You'd probably use dummy casters and apply a debuff based on inner fire? But you'd also need a repeating trigger for the traveling missile. And you'd need to memorize the stats of the caster during the missile travel (so that if he changes equipment during missile travel, it doesn't affect damage), so you'd need an array and actual indexing. But what if you want the debuff to stack from multiple sources? You'd also need to store the number of stacks for each unit seperately now. And what if someone uses dispel magic and you want dispel to only remove one of the buffs? Damn, inner fire doesn't stack by default, so all stacks will be removed at once?
All this would bloat up your GUI triggers ad absurdity. And the likelyhood of unwanted bugs occuring is HUGE.


In vJASS, you basicly just import a missile struct provided by a premade missile library and just use the provided "onHit" method to apply a buff struct. Then you'd use bonus mod to apply and remove the armor reduction at "onApply" and "onRemove" of the buff.
What if someone dispels? Well, no problem, the buff struct handles that. You want the buff to stack? No problem, just set the parameter for that. What if you want to detect who applied the debuff initially? Well, no problem, the buff struct always has it's owner stored by default. What if you want a unit to "steal" the debuff? No problem either, there's a function for that. What if you want a spell to deflect the missile? No problem either, just change the X and Y velocity of the missile while it travels and the spell adapts on it's own as everything is nicely organized in data structures!

That one spell that would literally take a dozen GUI triggers to make. And it would always be static. Anything that tries to interfere from the outside would bloat your trigger up even further.
And now think you have a map with dozens of spells. You can't possibly keep track of all possible combinations, so there will always be situations you haven't thought of that will bug.

In vJass, all this can be done in like 20-30 lines if done right. And there's no possibilities for bugs either, as the imported systems and libraries have been proven to work in thousands of cases.


I will try to learn some vJass, but I wonder how long it will take me to master the code and come up with equivalent systems as right now. I hope hours vs minutes is the case here, Zwiebelchen.
Depends on how much repetition is in your map.

But just for coding spells alone, it's already worth it.
 
Level 31
Joined
Jun 27, 2008
Messages
2,555
I see, so it is much easier and faster to do using Jass, plus less bugs, but only then when this code lengauge is mastered.

Do I need to start with Jass or I can go for vJass immediately? I still don't know if it is worth to study deeply though, because I am afraid warcraft 3 may fade one day. Or I simply should get someone good at this and let them do few systems for me, because I am okay with GUI spells as these doesn't seem to store memory at all so far.

I did however remove almost every leak, only few units are not put into variables, yet still when I trigger the system, it stores 15 MBs. And how to explain this: mouse is placed over unit and it stores 10 MBs of memory, no clicking, just moving mouse over. How is that even possible?
 

Zwiebelchen

Hosted Project GR
Level 35
Joined
Sep 17, 2009
Messages
7,236
It's just the syntax that would "fade away" with WC3. At heart, it's basic object orientated programming - so you can start with a general tutorial about object orientated programming before hopping right into vJass.

Vanilla Jass is somewhat the "limited" brother of vJass. vJass just adds more freedom to the language through advanced data structures.
 
Level 31
Joined
Jun 27, 2008
Messages
2,555
I took PurgeandFire's advice and copied the map, deleted ALL triggers so the map is clean of coding:
zALssKt.png

Then I started the map and at start and the memory taken was around 360 MBs, it was not growing when doing nothing:
jeyzFfp.png

What I did then, I moved to my talent tree and vendor menus and started JUST moving my mouse over those units, nothing else, no clicking. It stored 10 MBs per unit I moved my mouse over, moving again per same unit does not store memory anymore, so it grew into 1.1 GB memory taken:
b7ljl4B.png


8NTN2LF.png

Then I started clicking units, it stored 10 MBs per click for a unit as well, no more than 10 MBs per unit, so repeating a click does not store anymore. I kept clicking different units and when it reached 1.5 GB of memory, it crashed. I checked twice, reaching 1.5 GB the next click is a crash click.
TgumudH.png

So this is not triggers, what is it then? Object Editor has minimal changes and yet it does this! How to explain this? Is this my warcrafts fault? Can anyone else try this and see if this happens? I am really confused. (error says: not enough saving space for this action)
 

Zwiebelchen

Hosted Project GR
Level 35
Joined
Sep 17, 2009
Messages
7,236
I took PurgeandFire's advice and copied the map, deleted ALL triggers so the map is clean of coding:
zALssKt.png

Then I started the map and at start and the memory taken was around 360 MBs, it was not growing when doing nothing:
jeyzFfp.png

What I did then, I moved to my talent tree and vendor menus and started JUST moving my mouse over those units, nothing else, no clicking. It stored 10 MBs per unit I moved my mouse over, moving again per same unit does not store memory anymore, so it grew into 1.1 GB memory taken:
b7ljl4B.png


8NTN2LF.png

Then I started clicking units, it stored 10 MBs per click for a unit as well, no more than 10 MBs per unit, so repeating a click does not store anymore. I kept clicking different units and when it reached 1.5 GB of memory, it crashed. I checked twice, reaching 1.5 GB the next click is a crash click.
TgumudH.png

So this is not triggers, what is it then? Object Editor has minimal changes and yet it does this! How to explain this? Is this my warcrafts fault? Can anyone else try this and see if this happens? I am really confused. (error says: not enough saving space for this action)
This is fucked up. Maybe it has something to do with faulty imports? What are the icons on the ground? Doodads? Do the models have a sound attached? Did you try copying said part into another map?

There's something really fishy here. I suspect a problem with the models or the textures mapped to those models.

There's issues with certain compression settings on textures. If a texture has only 1 mipmap, for example, the texture crashes Macs. Check the BLPs in BLPlab if you are not sure.
Then there might be some messed up nodes in the model used to apply those images. Does it have a sound file attached to it? How do you change the texture of the model [do you use the warclub ability for that?] or is it one model per image?
 
Last edited:
Level 31
Joined
Jun 27, 2008
Messages
2,555
Fucked up indeed. Those icons on the ground are those units, it is vendor / talent tree system, it is those units that store memory. No sound attached. No, I did not try to copy into another map, perhaps it would work if I jut changed model and do the same analysis and see if it makes difference, if it does, then it is model's fault indeed.

All models are very simple, these are based on this wall model. It was rotated and fits very well, because it is flat and wrapping takes whole texture. Texture is a simple one, compressed at 90% quality, alpha set to Spec Decides For You, converted into BLP1. Did not check for mipmap, but I will. These are all separate models used for units, it doesn't change and has no abilities except invulnerability so it is a model per image. Doodad with same model basis do not store anything.

EDIT1: So I changed all of those units' models into Footman model but problem remains, it still stores 20 MBs after first click and first time moving mouse over. Probably not model's fault then, or perhaps something can be influenced not directly? Okay, I will import few of those models into new map, put some footman and other units with these models, will compare.

EDIT2: Created new empty map, changed few unit's models into those icons so that units could be with these models like in main map. Added some units with normal WC3 models and it stored no serious memory. It did however store 0.3 MB per select only, but stopped after a while, by constantly clicking and swtiching units between like 30 units I gained 10 MBs, moving mouse over has no effect either on unchanged units or units with changed models. So this proved again that it is not model's fault, but map's itself then. Since in main map it still stored memory even with all triggers deleted, so what could it possibly be then? This is driving me nuts. So conclusion is clear I guess, it is not model's or texture's fault after all, well it seems like it, right? Maybe Object Editor data? But it has minimal changes. Will try putting standard units into main map and compare to those.

EDIT3: Added some regular Knights and Riflemans beside those units and these units store 0.3 MB only per click, while those icon units 20 MB when clicked and *moused*. What the hell? I'll try to experiment with Object Editor.

EDIT4: Bah... Solved it.. Since I wanted to get rid of unit's selection circle, I set the value for selection scale to -1000, it appeared to fully eliminate the circle and life bar without any consequences, after all there were some serious consequences, but not noticeable so simply. I guess I will have to find another way to get rid of selection circle, any approved and working ideas? Thank you, Zwiebelchen and PurgeandFire, for putting me on the right path, problem is solved now. By the way, is it normal for usual units to store 0.3 MB per first click?
 
Last edited:

Zwiebelchen

Hosted Project GR
Level 35
Joined
Sep 17, 2009
Messages
7,236
Some overhead is expected in terms of memory. Remember that the game loads any model, texture, etc into memory on first use for performance reasons. But 0,3 mb is still way too much. Theres still sonething going on. Setting the selection circle to -1 is a common solution to the circle prroblem. Never heard of this messing things up. Have you tried it on -1 or 0? No need for -1000. Still i doubt this is the problem. Did you try the map on another machine? Maybe your wc3 could need a reinstall...
 
Level 31
Joined
Jun 27, 2008
Messages
2,555
0.3 Appears to be much to me as well, tested on clear map - this happens. Maybe it is my Warcraft even though I had my laptop reinstalled not long ago.

-1 Value removes life bar, but selection circle remains, I need both to be gone. 0 Value brings it to 0,10 and both are visible, plus messes up with nearby units' life bars. However -1000 value completely deals with the issue, but brings another one sadly. But yeah, -1000 value made 20 MBs per first click, now only 0.3 MB. I guess I will have to stay with 0.01 and a black dot on unit when selected as for now.
 
Status
Not open for further replies.
Top