• 🏆 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!

UnitHandleId to UnitHandle? Hashtable leaks?

Status
Not open for further replies.
Level 4
Joined
Jan 19, 2008
Messages
69
I am creating a summoning spell which summons units that deal damage based on the caster's intelligence upon attacking. I've done it by attaching the caster's handle id to the summoned units and saved the caster in a hashtable in the key his own handle id. It looks something like this:
JASS:
local unit u = GetTriggerUnit()
local integer id = GetHandleId(u)
call SaveUnitHandle(hashtable, id, 0, u)
set u = null
Once the summoned unit attacks I retrieve its attached id, load the unit handle of that key and make the caster deal his damage.

It currently works fine, but Im uncertain of a few things -
1) Using the method which I displayed above; Does it create a leak if I overwrite the existing unit handle before flushing the hashtable?

2) Is it possible to store a unit's handle id and then at a later point convert the handle id to an actual unit handle without using a hashtable? It was the only option I could think of.
 
(1) No it does not create a leak. When you overwrite it, the old memory is discarded.
(2) It is possible, through typecasting. See this:
http://www.hiveworkshop.com/forums/jass-ai-scripts-tutorials-280/typecasting-232039/

But there is no real reason for it except to replace older systems. I'm pretty sure there is alternative to your problem, you just have to explain your problem in detail.

At first glance, the code you wrote doesn't make too much sense. You store the caster in a hashtable, but you store it under its own ID. Since you can only get that unit's ID from the unit itself, you have created a problem. The solution would be to store the ID separately, but that doesn't make logical sense.

Usually you'll use the handle ID of something else for storage in a hashtable. For example, in most timed spells, we'll save the data under the timer's ID (since we can retrieve the timer in the callback function via GetExpiredTimer()). Similarly, in your case, think of what data you have to work with: you have a summoned unit that will attack. Instead of storing the caster under his own ID, store the caster under the summoned unit. That way, when the summoned unit attacks, you can just load the caster with LoadUnitHandle(hashtable, GetHandleId(GetTriggerUnit()), 0). Hopefully that makes sense, let me know if you need a better explanation. :) Hashtables are a rather confusing structure to work with at first, but they will become your best friend when you get used to them.
 
Level 4
Joined
Jan 19, 2008
Messages
69
Thank you for the answer Purge, the typecasting thing was pretty interesting.

Regarding your comment:
At first glance, the code you wrote doesn't make too much sense. You store the caster in a hashtable, but you store it under its own ID. Since you can only get that unit's ID from the unit itself, you have created a problem. The solution would be to store the ID separately, but that doesn't make logical sense.
I wrote it like that because the spell summons alot of units simultaneously, so in order to reduce the the amount of data saved in the hashtable I went with this approach as I figured it would be more efficient.
 
Status
Not open for further replies.
Top