• 🏆 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!
  • It's time for the first HD Modeling Contest of 2024. Join the theme discussion for Hive's HD Modeling Contest #6! Click here to post your idea!

Basic question about the points

Status
Not open for further replies.
Level 6
Joined
Jul 14, 2020
Messages
128
Hello Hive, my question is if I can use the same variable of type point for different points without creating memory leaks.

For example I use a SPELL_TempPosition to save the position of the caster, then I use it again in the same or another trigger to save the position of the target, then I use it again to take the position of units in a group, etc. At the end of it all, I clean it up with the remove Location Script. The example creates memory leaks. Does the example cause memory leaks regarding dot variables or not?

Thank you :grin: .
 
Hello Rasamayu.

Unfortunately, doing so would mean you lose all references to the position of the caster, the position of the target, and the positions of the units in the group (except for the last one). You'll have to clean up SPELL_TempPosition first before assigning it a different value for each instance.
 
Level 39
Joined
Feb 27, 2007
Messages
5,023
For a good reference about memory leaks (it links to a different structured tutorial too if that is helpful): Things That Leak

You are fine to re-use the variable, but each time it is assigned a value (when it becomes some specific location you want (like "position of (Triggering Unit)") you must clean the leak with the RemoveLocation call. For example:
  • Set TempPoint = (Position of (Triggering Unit))
  • Unit - Create one Super Bro Dude for (Owner of (Triggering Unit)) at TempPoint facing Default building facing degrees
  • Custom script: call RemoveLocation(udg_TempPoint)
  • Set TempPoint = (Center of The City <gen>)
  • Unit - Order (Last created unit) to Attack-move to TempPoint
  • Custom script: call RemoveLocation(udg_TempPoint) //note that this line is identical to the one above since it's the same variable
However, this may not always clean every leak. Consider the trigger above as shown, but with this trigger below also in the map. Also presume that the Triggering Unit for the above trigger is currently inside of the The City region:
  • Events
    • Unit - A unit enters (The City <gen>)
  • Conditions
    • (Owner of (Triggering Unit)) Not equal to Neutral Hostile
  • Actions
    • Set TempPoint = (Position of City Jukebox 003 <gen>)
    • Sound - Play EnteringCityMusic.wav at TempPoint using some sound settings but honestly I don't remember how this GUI action looks so just go with it
    • Custom script: call RemoveLocation(udg_TempPoint)
What happens?
  • When the first trigger fires TempPoint is assigned a location that's somewhere inside The City <gen>, and then a unit is created at that location.
  • When the unit is created, since the location TempPoint points to is inside The City <gen>, it activates the event of the second trigger, which pauses the execution of the first trigger just after the create unit line.
  • Because the first trigger was paused, its last action to remove TempPoint has not (yet) been executed... so when the first line of the second trigger is executed, the variable is overwritten and the previous value of TempPoint is lost becoming a (small but) permanent memory leak.
  • Additionally, when the first trigger resumes execution (after the second finishes), the value of TempPoint is now the new location assigned by the trigger that interrupted! This trigger will not work as intended because the location is 'wrong'. In this specific example, the Super Bro Dude would be attack-moving incorrectly to the 3rd City Jukebox instead of directly to the city center.
You must watch out for things like this when you reuse variables across triggers. If one trigger can cause another to fire, then variables in both triggers might be subject to such issues. It's also possible the combination of variables and how they are assigned/used would be immune to such problems; it really depends upon the specifics.
 
Status
Not open for further replies.
Top