1. Updated Resource Submission Rules: All model & skin resource submissions must now include an in-game screenshot. This is to help speed up the moderation process and to show how the model and/or texture looks like from the in-game camera.
    Dismiss Notice
  2. DID YOU KNOW - That you can unlock new rank icons by posting on the forums or winning contests? Click here to customize your rank or read our User Rank Policy to see a list of ranks that you can unlock. Have you won a contest and still havn't received your rank award? Then please contact the administration.
    Dismiss Notice
  3. We have recently started the 16th edition of the Mini Mapping Contest. The theme is mini RPG. Do check it out and have fun.
    Dismiss Notice
  4. Dismiss Notice
  5. The Highway to Hell has been laid open. Come along and participate in the 5th Special Effect Contest.
    Dismiss Notice
  6. Check out the Staff job openings thread.
    Dismiss Notice
Dismiss Notice
60,000 passwords have been reset on July 8, 2019. If you cannot login, read this.

Hashtable as GUI leak protection?

Discussion in 'World Editor Help Zone' started by George Stinz, Jan 16, 2020 at 6:19 AM.

  1. George Stinz

    George Stinz

    Joined:
    Jan 12, 2020
    Messages:
    5
    Resources:
    0
    Resources:
    0
    Given an action like such:
    Create 1 Footman for Player 1 (Red) at (Center of (Playable map area)) facing ...

    (Center of (Playable map area)) will create a point which will not be garbage collected, as I understand it.

    Therefore, most tutorials will recommend the following explicit action:

    Set Temp_Point = (Center of (Playable map area))
    Unit - Create 1 Footman for Player 1 (Red) at Temp_Point facing Default building facing ...
    script: call RemoveLocation (udg_Temp_Point)

    Question:
    Would this be sufficient/preferred to the above leak protection?
    Hashtable - Save (Center of (Playable map area)) as 1 of Key(This Trigger) in GameProperties
    Unit - Create 1 Footman for Player 1 (Red) at (Load 1 of Key(This Trigger)) facing Default building facing ...

    It's one less line of "code" but is it better?

    Edit: in fact, does this actually avoid a leak?
     
    Last edited: Jan 16, 2020 at 9:28 AM
  2. Sabe

    Sabe

    Joined:
    Jul 30, 2018
    Messages:
    367
    Resources:
    1
    Spells:
    1
    Resources:
    1
    Leak happens when a point is referenced to, thus the point is "created", but then you lose the information it actually stores. I.e. If you imagine this point as actual object: you create this object at the center of the playable map area when you reference to that point upon creation of the unit. Then when you create another unit, it creates another new object at some location. But the first point object that is standing at the middle of map is still there, and you literally have no way to now have access to that information. It is lost, but still exists, thus taking up memory. That's why you have to destroy the point object when you still have access to it, but don't need it anymore.

    You're system is just the same as saving the point to a variable: you would still have to clear the information from the hashtable (hashtables can actually leak quite a lot, if they aren't cleared correctly, because they can store large amounts of information). You can, however, use hashtables just as you could use temp variables, and I've even seen this in some maps. I just find temp variables a lot easier to handle.
     
  3. Pyrogasm

    Pyrogasm

    Joined:
    Feb 27, 2007
    Messages:
    3,409
    Resources:
    1
    Spells:
    1
    Resources:
    1
    Even clearing the hashtable wouldn't fix the leak in this case. You'd simply remove the reference to the point object but it still exists.
     
  4. George Stinz

    George Stinz

    Joined:
    Jan 12, 2020
    Messages:
    5
    Resources:
    0
    Resources:
    0
    Thanks, it makes sense. A further question would be then, can you help to clarify:

    Assigning a global variable to something, then clearing it, in a function (trigger), in the normal programming world would precisely be non-MUI. But here in WC land it's considered MUI. My question is:

    Is it MUI because:
    - With no waits, the trigger will run so fast it's highly unlikely to be run twice at the same time (but still possible)
    - The trigger doesn't commit the value of the variable until end of function (each run will go as expected but will clobber values)
    - Something else

    Trying to understand why exactly it's OK to use globals to achieve this, so I can decide how to handle leaks on my map.
     
  5. Pyrogasm

    Pyrogasm

    Joined:
    Feb 27, 2007
    Messages:
    3,409
    Resources:
    1
    Spells:
    1
    Resources:
    1
    Wc3 is single-threaded. A trigger can interrupt another trigger if something the initial trigger does causes the secondary one to fire, but otherwise only one trigger can be 'running' at a time.
     
  6. Wrda

    Wrda

    Joined:
    Nov 18, 2012
    Messages:
    1,205
    Resources:
    3
    Maps:
    1
    Spells:
    2
    Resources:
    3
    On one hand, triggers are never run at same time, in fact, the same trigger can't be run at same time if for example 2 units are damaged by an AoE spell and the trigger detects when a unit gets damaged, it will run twice, sequencially from the first created unit to last. On the other hand, the same trigger can be "run" again while it is being executed.
     
  7. George Stinz

    George Stinz

    Joined:
    Jan 12, 2020
    Messages:
    5
    Resources:
    0
    Resources:
    0
    OK, so the fact that it's global actually makes no difference then, as the game will only move on to the next in queue if there's a wait (I'm deducing).
    Then that at least simplifies things dramatically. Thanks.
     
  8. Pyrogasm

    Pyrogasm

    Joined:
    Feb 27, 2007
    Messages:
    3,409
    Resources:
    1
    Spells:
    1
    Resources:
    1
    Correct.