tooltiperror
Super Moderator
- Reaction score
- 231
What is a hashtable, you might ask? Let's ask our good and always reliable friend, wikipedia.
That is quite a complicated, and technical way of describing what a hashtable is. Perhaps a picture should help.
[size=-8](tinypic killed the side, ignore it.)[/size]
It is a normal X,Y grid. Now, imagine that you could put a unit, or a destructible, or a doodad, or whatever you want in each box. The box you choose on the X axis is called the key, or the identifier. The box you choose on the Y axis is called the index.
Unknown to you, everything in the game that is physically there, like the weather or units or anything like that is called a [LJASS]handle[/LJASS]. These handles are a type of variable. A lot of other variable types (such as units) are just types of handles. Every handle is given a number when it is created. Let's say for example you create a footman, it may get the number 12,774. This number is called the Handle ID. You can use this with a hashtable to do some pretty funky things.
In GUI, you are given a series of functions named pretty similarly. Here's some examples of them.
All of them look pretty much like this.
Fun fact, this will get you ready for JASS. These things you fill in, when you use GUI, these are called Arguments. And, in this case, you have four of these 'arguments'. The first value, the second, the third, and a hashtable. The second value is the one we really want to focus on. It is the box in the X axis, the key. Of course, an actual hashtable goes on forever with it's numbers. And you know how I mentioned that we have those nifty numbers each handle, like a unit, right? We can set that second value to the Handle ID of the unit you want to store data for. Let's say a handy dandy footman. Let's use Hashtable - Save String.
The function Key() gets the Handle ID of the unit for us. Let's say our footman's ID is 12774 (farmiliar, right?) This fills in the twelve-thousand seven hundred and seventy-fourth box on the right and zero up with "" (because it's an empty string). Let's try something different, let's save it as the name of our footman, Sir Vincent.
There we go, it's filled up. Now you may be asking yourself, "Why do I give a damn about this?" And there is actually a very good reason for this. Let's say we have a jewel that only Sir Vincent can pick up. We can do that quickly with our hashtable.
It leaks a position, but you get the idea of the hashtable can then be used, and how you are 'loading' the value back. Now, let's get onto a more serious issue that hashtables actually solve: Making spells MUI. Here we have a spell that will create a special effect, set it to a variable, and then destroy it after a wait. Normally, this is not MUI, because the variable could be reset during the wait. However, because the Triggering Unit always remains the same, we can just use the Triggering Unit's Handle ID. Hashtables have (seemingly) unlimited data storage, so you can save as much stuff about a spell in the hashtable as you want. Instead of using 0 as our index, we'll use the Execution Count of the current trigger which will be unique each time the trigger runs. When you want a lot of things in your trigger and you're only using one hashtable, simply use arrays and base everything off of the execution count.
Now, even if another unit casts the spell during the five seconds, it will still be MUI because of Triggering Unit. You can use this with any spell, or any system in your map, or for whatever data storage you want.
But, there's a teeny-tiny bit more you need to know about hashtables I didn't mention above, and this seemed like the best place to mention it. In order to use a hashtable, you need to create it first (duh). Here's the easy way to do it, with a function and a variable set.
Some other things you may need to know:
You have been enlightened on the way of the hashtable.
In computer science, a hash table or hash map is a data structure that uses a hash function to map identifying values, known as keys, (e.g., a person's name) to their associated values (e.g., their telephone number). The hash function is used to transform the key into the index (the hash) of an array element (the slot or bucket) where the corresponding value is to be sought.
That is quite a complicated, and technical way of describing what a hashtable is. Perhaps a picture should help.
[size=-8](tinypic killed the side, ignore it.)[/size]
It is a normal X,Y grid. Now, imagine that you could put a unit, or a destructible, or a doodad, or whatever you want in each box. The box you choose on the X axis is called the key, or the identifier. The box you choose on the Y axis is called the index.
Unknown to you, everything in the game that is physically there, like the weather or units or anything like that is called a [LJASS]handle[/LJASS]. These handles are a type of variable. A lot of other variable types (such as units) are just types of handles. Every handle is given a number when it is created. Let's say for example you create a footman, it may get the number 12,774. This number is called the Handle ID. You can use this with a hashtable to do some pretty funky things.
In GUI, you are given a series of functions named pretty similarly. Here's some examples of them.
- Hashtable - Save Real
- Hashtable - Save Integer
- Hashtable - Save Boolean
- Hashtable - Save String
- Hashtable - Save Unit Handle
All of them look pretty much like this.
Trigger:
- Hashtable - Save Value as Value of Value in (Last created hashtable)
Fun fact, this will get you ready for JASS. These things you fill in, when you use GUI, these are called Arguments. And, in this case, you have four of these 'arguments'. The first value, the second, the third, and a hashtable. The second value is the one we really want to focus on. It is the box in the X axis, the key. Of course, an actual hashtable goes on forever with it's numbers. And you know how I mentioned that we have those nifty numbers each handle, like a unit, right? We can set that second value to the Handle ID of the unit you want to store data for. Let's say a handy dandy footman. Let's use Hashtable - Save String.
Trigger:
- Hashtable - Save <Empty String> as (Key (Triggering unit)) of 0 in hashtable
The function Key() gets the Handle ID of the unit for us. Let's say our footman's ID is 12774 (farmiliar, right?) This fills in the twelve-thousand seven hundred and seventy-fourth box on the right and zero up with "" (because it's an empty string). Let's try something different, let's save it as the name of our footman, Sir Vincent.
Trigger:
- Hashtable - Save Sir Vincent as (Key (Triggering unit)) of 0 in hashtable
There we go, it's filled up. Now you may be asking yourself, "Why do I give a damn about this?" And there is actually a very good reason for this. Let's say we have a jewel that only Sir Vincent can pick up. We can do that quickly with our hashtable.
Trigger:
- hashtable
- Events
- Unit - A unit Acquires an item
- Conditions
- (Item-type of (Item being manipulated)) Equal to The Vincent Family Jewels
- Actions
- If (All Conditions are True) then do (Then Actions) else do (Else Actions)
- If - Conditions
- (Load (Key (Triggering unit)) of 0 from hashtable) Equal to Sir Vincent
- Then - Actions
- Do nothing
- Else - Actions
- Unit - Order (Triggering unit) to drop (Item being manipulated) at (Position of (Triggering unit))
- If - Conditions
- If (All Conditions are True) then do (Then Actions) else do (Else Actions)
- Events
It leaks a position, but you get the idea of the hashtable can then be used, and how you are 'loading' the value back. Now, let's get onto a more serious issue that hashtables actually solve: Making spells MUI. Here we have a spell that will create a special effect, set it to a variable, and then destroy it after a wait. Normally, this is not MUI, because the variable could be reset during the wait. However, because the Triggering Unit always remains the same, we can just use the Triggering Unit's Handle ID. Hashtables have (seemingly) unlimited data storage, so you can save as much stuff about a spell in the hashtable as you want. Instead of using 0 as our index, we'll use the Execution Count of the current trigger which will be unique each time the trigger runs. When you want a lot of things in your trigger and you're only using one hashtable, simply use arrays and base everything off of the execution count.
Trigger:
- hashtable
- Events
- Unit - A unit Starts the effect of an ability
- Conditions
- (Ability being cast) Equal to Thunder Clap
- Actions
- Special Effect - Create a special effect at (Center of (Playable map area)) using Abilities\Spells\Human\ThunderClap\ThunderClapCaster.mdl
- Hashtable - Save Handle Of(Last created special effect) as (Key (Triggering unit)) of Execution count of (This trigger) in hashtable
- Custom script: call PolledWait(5.00)
- Special Effect - Destroy (Load (Key (Triggering unit)) of Execution count of (This trigger) in hashtable)
- Events
Now, even if another unit casts the spell during the five seconds, it will still be MUI because of Triggering Unit. You can use this with any spell, or any system in your map, or for whatever data storage you want.
But, there's a teeny-tiny bit more you need to know about hashtables I didn't mention above, and this seemed like the best place to mention it. In order to use a hashtable, you need to create it first (duh). Here's the easy way to do it, with a function and a variable set.
Trigger:
- hashtable
- Events
- Map initialization
- Conditions
- Actions
- Hashtable - Create a hashtable
- Set hashtable = (Last created hashtable)
- Events
Some other things you may need to know:
- You can only have 256 Hashtables at a time.
- A hashtable is fast.
- Unfortunately, you can not use hashtables to store data between maps.
You have been enlightened on the way of the hashtable.
p.s. lime