[Solved] Dynamic Locations leak: symptoms?

[Helheim]

Some questions about locations leaks.
- How locations memory leaks manifested in game?
- Will it happen only with <Playable map area> or it affects any custom region?
- Will solution with "TempPoint" cause a conflict if occasionaly many triggers would use this variable at same time?

While I've dealed with Unit Group leaks and special effect leaks (which were pretty messy), I've never got a problem with locations... or just did not notice them yet.

Just wonder, how important is it, before I've start rewriting hundreds of triggers...

Thanks for help!

 

[Dr Super Good]

- How locations memory leaks manifested in game?

When a location object is created, used, no longer needed but left as is (not removed).

- Will it happen only with <Playable map area> or it affects any custom region?

Any function that returns a new location can cause a location leak if that location is not eventually removed after it is no longer useful.

- Will solution with "TempPoint" cause a conflict if occasionaly many triggers would use this variable at same time?

Yes they will cause a conflict if 2 threads are using it at the same time. This can only happen if 1 thread yields to allow another thread to execute. A thread can yield explicitly, such as with the wait action yielding to all other triggers for the wait duration. A thread can also yield implicitly, such as when dealing damage to a unit and yielding to all damage response triggers. Two trigger threads will never execute concurrently (at the same time), even on a processor with multiple concurrent threads, only 1 thread will ever be actively executed at any given time.

The correct solution is to use local variables. However GUI lacks direct access to these so one might need multiple temporary variables to hold the values.

 

[Helheim]

When a location object is created, used, no longer needed but left as is (not removed).

Does it mean that I can't use one variable TempPoint multiple times?

Anyway, some dozens of leaked location objects should not being so scary. Am I right ?

The correct solution is to use local variables.

Any way I can use them with GUI arrays?

For ex:

• Actions
  • Custom script: set bj_wantDestroyGroup = true
  • Unit Group - Pick every unit in (Units owned by Player 12 (Brown) matching ((((Matching unit) is A structure) Equal to Нет) and ((((Matching unit) is dead) Equal to Нет) and (((Matching unit) is A flying unit) Equal to Нет))).) and do (Actions)
    • Loop - Actions
      • Unit - Order (Picked unit) to Move To RegionsCentersPoint[(Custom value of (Picked unit))]

I've tried this

• Actions
  • Custom script: set bj_wantDestroyGroup = true
  • Unit Group - Pick every unit in (Units owned by Player 12 (Brown) matching ((((Matching unit) is A structure) Equal to Нет) and ((((Matching unit) is dead) Equal to Нет) and (((Matching unit) is A flying unit) Equal to Нет))).) and do (Actions)
    • Loop - Actions
      • Set VariableSet TempPoint_Debug = RegionsCentersPoint[(Custom value of (Picked unit))]
      • Unit - Order (Picked unit) to Move To TempPoint_Debug
      • Custom script: call RemoveLocation(udg_TempPoint_Debug)

But it worked only once for only one unit.

 

[Dr Super Good]

Does it mean that I can't use one variable TempPoint multiple times?

You can use variables as much as you want. There is no limit to how often or how much a variable can be set.

Anyway, some dozens of leaked location objects should not being so scary. Am I right ?

A few dozen leaks is no issue. The problem is constant persistent leaks like a few dozen locations every second. These sort of leak quickly builds up and degrades map performance.

Any way I can use them with GUI arrays?

GUI variables are global variables. Local variables are not available in GUI without hacky custom script. Like global variables, local variables can also be arrays.

But it worked only once for only one unit.

In that trigger you do not need to remove the location as you are recycling the same location object multiple times (still is useful).

A good way to improve performance and get rid of location leaks from "centre of rect" functions is to assign the location to a global variable at map initialization and reuse that global variable each time the centre of the rect is needed.

 

[IcemanBo]

Memory Leaks

 

[Helheim]

Memory Leaks

Ofc I've read it, but some questions were not discussed there.

Will UnitGroup leak involves Pick RandomUnit from UnitGroup? If it so, will

• set bj_wantDestroyGroup = true

help?

• Unit - Order Hero_Type_RED to Orc Shadow Hunter - Healing Wave (Random unit from (Units within 600.00 of (Position of Hero_Type_RED) matching (((Owner of (Matching unit)) Equal to Player 12 (Brown)) and ((((Matching unit) is dead) Equal to Нет) and ((Life of (Matching unit)) Less than (Max life of (Matching unit)))

 

[IcemanBo]

"Pick RandomUnit from UnitGroup"

• Does it use a unit group to operate with?
  -> Yes, a unit group variable can be used.
  
  
• Can unit groups leak?
  -> Yes.
  
  
• Is a new unit group created, or does it use an already existing one?
  -> "Units within 600.00 of (Position of Hero_Type_RED)" is used which creates a new unit group object.
  
  
• Yes, bj_wantDestroyGroup can be used.

 

[Helheim]

Another question is how to put UnitCustomValue in variable array I want to clean.

• Actions
  • Custom script: set bj_wantDestroyGroup = true
  • Unit Group - Pick every unit in (Units owned by Player 12 (Brown) matching ((((Matching unit) is A structure) Equal to Нет) and ((((Matching unit) is dead) Equal to Нет) and (((Matching unit) is A flying unit) Equal to Нет))).) and do (Actions)
    • Loop - Actions
      • Unit - Order (Picked unit) to Move To RegionsCentersPoint[(Custom value of (Picked unit))]
  • Custom script: call RemoveLocation(udg_RegionsCentersPoint[(Custom value of (Picked unit))])

ofc it says about wrong syntax, but unfortunatelly I'm not a coder.

 

[IcemanBo]

You can use an extra integer variable for that, that you assign with GUI. And then use the integer variable in your custom script with "udg_" prefix.

You currently only destroy one location, after the group enumeration.

 

[Helheim]

You can use an extra integer variable for that

Thanks! I've also found this solution in some Blizzard maps.