[Solved] Does this leak? Setting a point to be equal to itself offset by a distance

[Uncle]

Quick question. In this trigger does tempPoint[0] leak? I'm curious about this line "Set tempPoint[0] = (tempPoint[0] offset by (_0, _n3))", setting it to itself plus an offset, does this cause a leak in regards to it's previous position?

• Untitled Trigger 001
  • Events
  • Conditions
  • Actions
    • Set tempPoint[0] = (RoomTL[RoomCount] offset by (_n6, _p6))
    • Set tempPoint[0] = (tempPoint[0] offset by (_0, _n3))
    • Custom script: call RemoveLocation( udg_tempPoint[0] )

 

[IcemanBo]

Correct, it does indeed leak. Once you overwrite the variable value with a new value (a new point-object actually), the old one can't be removed anymore. That is a normal leak.

 

[Uncle]

Thanks, I thought as much

 

[Uncle]

Correct, it does indeed leak. Once you overwrite the variable value with a new value (a new point-object actually), the old one can't be removed anymore. That is a normal leak.

While I have your attention, would you happen to know if cleaning up a Point that doesn't currently exist could cause a problem? In other words, what happens if I try to "call RemoveLocation( udg_tempPoint[0] )" when it doesn't exist yet?

 

[IcemanBo]

It's pretty easy to try it out. Or what do you mean exactly?

 

[Uncle]

It's pretty easy to try it out. Or what do you mean exactly?

• Untitled Trigger 001
  • Events
  • Conditions
  • Actions
    • For each (Integer A) from 1 to 10, do (Actions)
      • Loop - Actions
        • Custom script: call RemoveLocation( udg_tempPoint[0] )
        • Set tempPoint[0] = (Center of (Playable map area))

There's a reason why I have to have it setup this way before you ask Anyway, the trigger works as intended, but I was just wondering if it was bad practice to remove a location that hasn't been created yet. The first time this loop runs it tries to remove tempPoint[0] which hasn't been created yet. I guess that's fine?

 

[IcemanBo]

I'm not sure it works as intended with using index 0 always. Also, have you tried printing a message after it? When trying to use an unitialisized variable it will crash the thread, meaning no further action will continue in the trigger.

So basically trying to destroy ...

1. ... something that was not initiailized, yet, aka holds no value yet, will crash the thread. Leading to stop further trigger exectuion.
2. ... something initialisized but already destroyed, should just do nothing.

 

[Uncle]

I'm not sure it works as intended with using index 0 always. Also, have you tried printing a message after it? When trying to use an unitialisized variable it will crash the thread, meaning no further action will continue in the trigger.

So basically trying to destroy ...

1. ... something that was not initiailized, yet, aka holds no value yet, will crash the thread. Leading to stop further trigger exectuion.
2. ... something initialisized but already destroyed, should just do nothing.

What's the issue with using a Point Array? Also, that trigger is just an example, I removed all of the other actions to make it look clean. The real trigger seems to run fine, everything works beyond that line. Just to be safe though, I put the RemoveLocation inside an If/Else Statement so it doesn't fire the first time.

 

[IcemanBo]

What's the issue with using a Point Array?

In regards of what I meant might be not working is using always the same arrays index in the loop "0" instead of IntegerA.

 

[Uncle]

Ah, I see, I simply wanted to show an example of removing a point that didn't exist, the loop was just leftover from the original trigger I pulled from my map. No worries, everything seems to work fine.

 

[Dr Super Good]

Yes it is bad practice to remove null or double remove an already removed location. I would hope Blizzard added safety checks to the RemoveLocation native to prevent this being a problem so in worst case it should just result in functionally wasted cycles.