The map could really start glitch out and become unplayable
How often does a leak need to happen for the map to start glitching? My map has 75 leaks. I have played it over 1 hour and nothing happened.
a lot, just open the game in window mode, and open task manager, and check the memory rising, if it goes up steadily you are in deep trouble.
Generally, you could have 10000 leaks but if every one of them only happens once per the whole map, thats not even big deal(unless you leak super expensive stuff).
If you have single leak, for instance location, or group, and it is placed inside "Every 0.03 seconds" the map may very well become unplayable(lag to oblivion) after maybe half hour or hour
4 bytes per leak.
So if you have a lot of leaks it is very likely to make your map lag after a few minutes of playtime.
My map is 3v3 and avarage play time is 20-30 minutes. Most of the leaks are in some of the heroes spells. Will that be a big problem?
Yes. Everytime someone cast the spell, WC3 CPU usage increases. They are not one time leak and it can eventually cause wc3 to crash if someone keeps spamming the spell.
I don't think that anyone would spam a spell and if 1000leaks are needed for the game to crash I think I'm safe
Post the triggers that you made for doubling monsters.but when there are too many units the game often crashes.
Post the triggers that you made for doubling monsters.
You could post the triggers of the spells and have the tech guys here manually check them for leaks.
@edo & chaosy: bite sized! Like those corned-beef cut potatoes
Well, you fixed the memory leaks in the loop trigger.
As for the leaks in the cast trigger, you can follow this guide: http://www.hiveworkshop.com/forums/...quick-tutorial-common-triggering-tips-190802/
As a rule of thumb: leaks more or less only matter in periodic triggers or on long game sessions.
Really the leaks you definitely want to mitigate are the ones that occur if you are leaking a point when you run a trigger every 0.01-0.03 seconds or even every 30 seconds.
i think you just need to add a "call DestroyGroup(udg_unit_group_spell_charge)" each
to fix the 3 unitgroup leaks.
maybe you also need to null them and the effects.
on my map i even did it with local vars because somebody said that's better
Leaks are a lot more than 4 bytes each. The handle id management structures alone are likely several times 4 bytes.4 bytes per leak.
Leaks are really bad and unnecessary, even outside a looping trigger. I have this saying that ~ Just because your code is working, doesn't it mean that you code it correctly. You should always ALWAYS strife to make your code as efficient as possible, not only in wc3 put in every programming language. In your spell for example, you should turn the looping trigger off when you don't use it because it only waste processing that could have been spend on something more important.
As a second note, it is recommended that you study this tutorial: Making MUI spells. You may think that it is not a must because you will probably never cast 2 looping spells of the same type in your map, well that is not true. If you want to add a mod where more than 1 of the same hero type can be played then the looping spells will get buggy when 2 of the same looping spells are cast at once. The point is that you sould try to make your code flexible so you can easily add updates without adjusting existing code.
Leaks are a lot more than 4 bytes each. The handle id management structures alone are likely several times 4 bytes.
That still would be more than 4 bytes as the handle id management structures are likely at least 12. 4 bytes for the id, 4 bytes for the reference counter and 4 bytes for a pointer to next element ( to allow them to be more easily recycled). You can then count a few bytes for alignment or memory management overhead still.As I said, it might have been unnulled GUI variables that was 4 bytes, I don't really remember.
Yes but then you have 8-12 byte linked list structures to hold recycled handle ids. Would make allocated handle id structures smaller but increase the overhead of recycled handle id values.Theres really no need for pointer to next element, so they could be 8 bytes
One cannot say that. Compilers are allowed to apply extra padding as they find appropriate. Additionally the allocation algorithm might constrain the packing and also has overhead.4+4+4 is perfectly aligned so no alignment payment
Lol,that's why I avoid the spell section and any sections related to spells and triggersI wish I understood what you guys are talking about.
It might be aligned to fit evenly inside a page or to fit inside processor cache lines. It still might need a virtual table pointer as well which is an extra 4. The reality is that you cannot say what alignment such a structure would take if you made it. Sure you can say what alignment the structure is by reverse engineering but that is different.The memory still has to be word aligned, and since 4 + 4 + 4 is perfectly aligned, there is no need to add padding into this. Even if one of these was character, it would still be the same alignment.
Handle IDs are more than a reference counter though. They at least contain an object pointer (what the handle references), a reference counter and possibly the handle id number itself. They might also contain 1-2 pointers to other handle ID structures for freeing purposes once the game session ends. The virtual table might be needed so that various kinds of hand ids can be dereferenced (based on the handle type).Ref count needing virtual table pointer? what kind of ref counter needs to be polymorphic.