[Trigger] Point Leak: when -exactly- does it happen ?

[Foar]

Hello everyone !

I have a question concerning Point Leaks, i know how to prevent them, but now i need to know a certain detail about it:

1 Set Temp_Point = (Event Response - Target point of Ability being cast.)
2 Unit - Create 1 Footman for Player 1 (Red) at Temp_Point
3 Point - Remove Temp_Point

My Question is: What Line exactly creates the leak ? The setting of the point, or the creation of the unit AT the point ?

On in other words: Do we just have to reset the point before it is used again, or do we need to reset the point between every single reference to it ?

I ask this to find out wether the following leaks or not:

1 Set Temp_Point = (Event Response - Target point of Ability being cast.)
2 Unit - Create 1 Footman for Player 1 (Red) at Temp_Point
3 Unit - Create 1 Footman for Player 2 (Blue) at Temp_Point
4 Point - Remove Temp_Point

Thanks for your time !

PS: The Remove Point function comes from WEU

 

[Saif]

trigger 2 does not leak. You just have to reset the point if it is going to be used in another trigger again.

 

[Foar]

That was fast ! Thank you, knowing this clarifies the nature of leaks a lot.

 

[Saif]

setting points is like buying ketchup and using the points is like applying the ketchup. You do not need to buy another ketchup once you have already bought one. as simple as that

 

[Magtheridon96]

The first trigger doesn't leak as well.

These point leaks occur whenever you create a point object or reference one
In the above triggers, you're referencing "Target point of Ability being cast".
This returns a location object.

The last line removes this location object.

Location objects are like RAM Pacmen. You shouldn't let ANY of them stick around D:

That's why we set locations in variables and destroy them later, because we can't leave any of them sticking around to eat our RAM D:

 

[defskull]

My Question is: What Line exactly creates the leak ? The setting of the point, or the creation of the unit AT the point ?

Both will leaks if you don't handle them very well.

1. Footman will leak (if it's a dummy and stays there and never dies), but if it's a summon or what, it doesn't called as leaks.

2. Once you have set a point, it will leak as long you doesn't clean them at the end of its usage. Therefore, leak per setting (if you don't clean them well)

For the second trigger, using an action upon a point setting variable will not leak no matter how much action is acted upon a single point, as long you clean it up after the end of its usage.

 

[WaterKnight]

You just have to reset the point if it is going to be used in another trigger again.

No, you can use the same location for the other trigger too if you want. You just have to pay attention that when you request more locations meanwhile, to save them in different places to be able to reference each of them afterwards when you want to destroy them.

That's why we set locations in variables and destroy them later, because we can't leave any of them sticking around to eat our RAM D:

Well, they do not roam individually throughout the memory to require more of that tasty stuff on their own. It's just that each new object needs its space and that the leak might be enlarged by running the same problematic code multiple times.

1. Footman will leak (if it's a dummy and stays there and never dies), but if it's a summon or what, it doesn't called as leaks.

2. Once you have set a point, it will leak as long you doesn't clean them at the end of its usage. Therefore, leak per setting (if you don't clean them well.

It's called a leak when you lose the opportunity to release requested memory. You can have that location the whole game inside the variable without being a leak as long as you do not lose all references to the object. What you mean is what I would rather call a potential leak in terms of explanation, that is allocated memory during runtime. This is how the consumption grows and what you can lose control of.

 

[Magtheridon96]

Well, they do not roam individually throughout the memory to require more of that tasty stuff on their own. It's just that each new object needs its space and that the leak might be enlarged by running the same problematic code multiple times.

How about this:

They're RAM Pacmen who eat a piece of your RAM, but happen to be on a diet, so they limit their consumption of RAM to 1 per map execution in order to stay healthy? ^)^

 

[WaterKnight]

Or you should not play Pacman MMORPG.

 

[Foar]

Woah ! Thanks for all the details guys.

It's called a leak when you lose the opportunity to release requested memory.

That's exactly what i wanted to know. Thanks !

In my campaign, the main and side characters have acess to a total of 160 abilities. They are all trigger-controlled with only few exceptions, so that's a lot of leak possibilities, using the knowledge here i can finally be sure that they are all leakless.

PS:
Is it just me, or are there actually some severe leaks in a few official maps ?
ROC NELF Map 02, where the doomguards constantly patrol, started to lag and reached very long game save/load times after playing on it for a longer time.

 

[IsaacNewbton]

yes some maps and games are great ideas that were executed poorly