RemoveLocation question

[kentzeus]

Hi, I'm just wondering if I always have to remove locations in the same trigger like this

• Set tempLoc = (Position of unit)
• Special Effect - Create a special effect at tempLoc using Abilities\Spells\Human\MassTeleport\MassTeleportTarget.mdl
• Custom script: call RemoveLocation(udg_tempLoc)
• Set tempLoc = (Position of unit2)
• Unit - Move unit instantly to tempLoc
• Custom script: call RemoveLocation(udg_tempLoc)

Or could I simply do it like this?

• Set tempLoc = (Position of unit)
• Special Effect - Create a special effect at tempLoc using Abilities\Spells\Human\MassTeleport\MassTeleportTarget.mdl
• Set tempLoc = (Position of unit2)
• Unit - Move unit instantly to tempLoc
• Custom script: call RemoveLocation(udg_tempLoc)

 

[Pyrogasm]

You need to remove it before you overwrite the variable. The first one.

 

[Cespie]

Hi, I'm just wondering if I always have to remove locations in the same trigger like this

• Set tempLoc = (Position of unit)
• Special Effect - Create a special effect at tempLoc using Abilities\Spells\Human\MassTeleport\MassTeleportTarget.mdl
• Custom script: call RemoveLocation(udg_tempLoc)
• Set tempLoc = (Position of unit2)
• Unit - Move unit instantly to tempLoc
• Custom script: call RemoveLocation(udg_tempLoc)

Or could I simply do it like this?

• Set tempLoc = (Position of unit)
• Special Effect - Create a special effect at tempLoc using Abilities\Spells\Human\MassTeleport\MassTeleportTarget.mdl
• Set tempLoc = (Position of unit2)
• Unit - Move unit instantly to tempLoc
• Custom script: call RemoveLocation(udg_tempLoc)

The first example is the correct one.
Think of the variable as a name or reference. It isn't actually the location itself, it's just a way to refer to it.
This means, that when you run "Set tempLoc = (Position of unit)", you are creating a position, and using tempLoc as a reference for it, lets call it "location 1".
Now, if you were to run "Set tempLoc = (Position of unit2)", you are now creating a new position (location 2), and using the tempLoc name as a reference for it.
The current situation is that you have 2 locations, location 1 and location 2, and you have 1 reference, tempLoc, which refers to Location 2. If you remove "tempLoc", you remove location 2, but not location 1, since that is no longer referred to as tempLoc. In fact, you don't really have a reference to Location 1 at all anymore, so it has essentially become a "memory leak", meaning a useless object cluttering up the game's memory, that you can't clean up anymore. It is possible to clean stuff like this automatically with LUA now, but I personally prefer keeping a bit of distance from that until the first movers like DSG can iron out potential issues.

 

[Wrda]

It is possible to clean stuff like this automatically with LUA now

Just like it is possible with vjass. But still pointless. Either remove them manually, or move to (v)jass or lua.

 

[kentzeus]

The first example is the correct one.
Think of the variable as a name or reference. It isn't actually the location itself, it's just a way to refer to it.
This means, that when you run "Set tempLoc = (Position of unit)", you are creating a position, and using tempLoc as a reference for it, lets call it "location 1".
Now, if you were to run "Set tempLoc = (Position of unit2)", you are now creating a new position (location 2), and using the tempLoc name as a reference for it.
The current situation is that you have 2 locations, location 1 and location 2, and you have 1 reference, tempLoc, which refers to Location 2. If you remove "tempLoc", you remove location 2, but not location 1, since that is no longer referred to as tempLoc. In fact, you don't really have a reference to Location 1 at all anymore, so it has essentially become a "memory leak", meaning a useless object cluttering up the game's memory, that you can't clean up anymore. It is possible to clean stuff like this automatically with LUA now, but I personally prefer keeping a bit of distance from that until the first movers like DSG can iron out potential issues.

I see, very good explaination! Thanks

 

[JsonDalao]

Just like it is possible with vjass. But still pointless. Either remove them manually, or move to (v)jass or lua.

Lua cannot automatically clear War3 object.
Version 1.31 I seem to find that Lua is a variable that does not automatically drain Lua objects and discard them, so I need to turn on the timer and manually recycle them

 

[Pyrogasm]

Lua cannot automatically clear War3 object.

Yes it can. Here’s an example: [Lua]Obliterate all GUI leaks with 1 trigger!

 

[Dr Super Good]

The script has some issues, but not ones that could not eventually be solved if people cared. For example hashtable references.

 

[JsonDalao]

The script has some issues, but not ones that could not eventually be solved if people cared. For example hashtable references.

HT reference object is not excreted? Or will it drain the object referenced in HT? (HT=HashTable)

 

[Dr Super Good]

HT reference object is not excreted? Or will it drain the object referenced in HT? (HT=HashTable)

Hashtables do not hold references to the Lua wrappers. As such it may incorrectly destroy objects stored in hashtable which are still accessible as there are no Lua references to them so the Lua wrapper is garbage collected but the object itself is still reachable from the hashtable.

For reference the behaviour is such that if an object is placed inside a hashtable and the wrapper is still alive then the same wrapper will be returned as was used to place the object inside the hashtable. However if garbage collection were to run between placing the object in the hashtable and retrieving it then the wrapper may be destroyed if no Lua references to it exist in which case the retrieval operation will return a brand new wrapper object.

This is where my garbage collector breaks because it will incorrectly destroy the object as it ties the object life to that of the Lua wrapper. The object may then be returned in future but has been destroyed. The theoretical solution is to proxy hashtable functions so that they can keep an Lua reference to the wrapper.

 

[JsonDalao]

Dr Super Good Can I use a table instead of hashtable？Is this not have a problem?

 

[Dr Super Good]

Dr Super Good Can I use a table instead of hashtable？Is this not have a problem?

Yes that will not have a problem as Lua tables do keep Lua wrapper objects alive. One could in theory replace hashtable with a custom implementation that internally uses table and it would work.

Jass arrays may also have a similar issue. They can be replaced with tables as well working in list mode.

 

[JsonDalao]

I have one more question. How to solve the problem of out of sync by traversing a string as the index of Table?
Dr Super Good

 

[Dr Super Good]

I have one more question. How to solve the problem of out of sync by traversing a string as the index of Table?

This is a problem? As long as the mapping was not set locally I do not see why it should cause an OoS.

 

[JsonDalao]

This is a problem? As long as the mapping was not set locally I do not see why it should cause an OoS.

Is "in pairs" working locally?so，It will out of sync.right?

 

[Dr Super Good]

Is "in pairs" working locally?so，It will out of sync.right?

I am not sure what you are asking. OoS only happens if the game state deviates enough that a checksum mismatch occurs between two or more clients.

Running code locally will not cause a checksum mismatch unless it changes the synchronized game state locally.

 

[JsonDalao]

Dr Super Good I tested it with a couple of friends, and it's true that traversing a table using a string as an index is asynchronous because the order in which the strings are indexed is arranged on each client, so the data in the same index on each player's table may be different.

 

[Dr Super Good]

I tested it with a couple of friends, and it's true that traversing a table using a string as an index is asynchronous because the order in which the strings are indexed is arranged on each client, so the data in the same index on each player's table may be different.

I think I get what you are saying. Creating an iterator for all key value pairs in a table returns an iterator that operates in internal order and that internal order is not synchronous between clients and so the order the mappings are iterated is not synchronous and can cause OoS. I will speak with William about it.

 

[JsonDalao]

I think I get what you are saying. Creating an iterator for all key value pairs in a table returns an iterator that operates in internal order and that internal order is not synchronous between clients and so the order the mappings are iterated is not synchronous and can cause OoS. I will speak with William about it.

Please let me know if you have a solution,thanks~

 

[Dr Super Good]

Please let me know if you have a solution,thanks~

Have you tried sorting the iterator into a list and then iterating the list? Slow but may be a work around if it works.

 

[JsonDalao]

Have you tried sorting the iterator into a list and then iterating the list? Slow but may be a work around if it works.

It is possible to sort lists, but if you have too much data you have to write a directory, which can be cumbersome, but it is much easier to use strings as an index, which causes asynchrony using "pairs" and not "ipairs".

 

[Dr Super Good]

It is possible to sort lists, but if you have too much data you have to write a directory, which can be cumbersome, but it is much easier to use strings as an index, which causes asynchrony using "pairs" and not "ipairs".

I would imagine it should only cause OoS if you use the iteration to do something order dependant such as creating new handles.