Hashtables go both ways?

[CaptainHero]

Hey i just wondered if i can use a hash-table both ways..
Like checking the x-axis and look for y, or checking the y-axis and look for x?

Well i guess i need to create two hash-tables..

So anyway the thing I want to achieve is this:

There is this Bronze Bowl Item (like an urn), that is carried by a hero.
When the Hero dies, the Urn is replaced with a Bronze Bowl Full, and dropped at the Point where the Hero died.
At this Point I would have to save the Hero in a Hash-table with the Handle of the Item, but I would also need the Item saved with the Handle of the Hero..

Since this "Urn" can be brought back by your allies to an altar, which will resurrect your Hero instantly, at the same time replace the Bronze Bowl with an empty version..

However if your Hero resurrects after a certain Time, the Urn should also be emptied...

I'm also having problems saving Units in Item Handles and vise versa :S

 

[Chaosy]

I am having problems understanding what you want.

1. item x is carried by hero.
2. hero dies and drops item y and item x is removed
3. when item y is taken to a certain building the hero who dropped it is revived.

correct?

 

[CaptainHero]

that is correct

 

[Chaosy]

What happens if the hero is already revived? should the player still be able to turn it in?

 

[CaptainHero]

Nope in that case item y has to be replaced with item x again...
So the urn is emptied... The hero's ash teleported to the altar where he got revived

 

[Chaosy]

well, either way. I think something like this would work for saving the owner and/or the unit specifically.

• drop and save
  • Events
    • Unit - A unit Dies
  • Conditions
    • Or - Any (Conditions) are true
      • Conditions
        • (Item-type of (Item carried by (Triggering unit) in slot 1)) Equal to x
        • (Item-type of (Item carried by (Triggering unit) in slot 2)) Equal to x
        • (Item-type of (Item carried by (Triggering unit) in slot 3)) Equal to x
        • (Item-type of (Item carried by (Triggering unit) in slot 4)) Equal to x
        • (Item-type of (Item carried by (Triggering unit) in slot 5)) Equal to x
        • (Item-type of (Item carried by (Triggering unit) in slot 6)) Equal to x
  • Actions
    • Item - Remove (Item carried by (Triggering unit) of type x)
    • Item - Create y at (Position of (Triggering unit))
    • -------- use the following to save the player if you prefer that. --------
    • Custom script: call SaveInteger(udg_your_hashtable, GetHandleId(udg_y), 0, GetOwningPlayer(GetTriggeringUnit())
    • -------- use the following to save the specific unit that died. --------
    • Custom script: call SaveUnitHandle(udg_your_hashtable, GetHandleId(udg_y), 0, GetTriggeringUnit())

 

[Wietlol]

I think you are not so much dependant on hashtables and for efficiency matters this should be without.

But that is not an answer to your question.

A hashtable is a simple 2 dimensional array and is very similar to multiple arrays.
Lets make an example:
You want to save an integer for each player.
In that case you will create a simple integer array with the size of 12 (12 players)

If you want to save the name, the ranking number, the amount of units, the number of gold/wood/stone/food (alternative resource systems), etc.
You need one array for each kind of data.
string array for name
integer array for ranking number
integer array for amount of units
integer array for gold
integer array for wood
integer array for stone
integer array for food

You can easily see this data as a table: (Remember we are still talking about arrays not hashtables)

Player	1	2	3	4	5	6	7	8	9	10	11	12
Name
Rank
Units
Gold
Wood
Stone
Food

This is just a small picture of how 7 arrays would look like.
There is a way that you can convert an unit into an integer (GetHandleId()).
This handle id can be used to store data in an array and retrieve it by calling out the data in the array with the index of the handle id.
There is a little problem that arrays do NOT support enough data to make a referrence with such a high index.
Hashtables on the other hand do.

In hashtables, you can save data in column "handle id" and in row "0" to save a value to the unit with that handle id.
You could also make your own indexer instead of using handle id. In that case you can make everything in an array and it should work faster.

There is one other benefit that a hashtable has and cannot be done (easily) with arrays.
You can create dynamic data...
Well lets say that you want to save buffs of a unit in arrays/a hashtable.
In the table you saw before, there was a header and 7 rows. Every row is a pre-made array variable.
Hashtables creates those arrays if it has to do it.
You can check if the data in column 0 row 0 is empty and if not then you go to row 1. etc. etc. etc. until you see an empty spot.
Regular arrays cannot be (easily) automatically made and so a hashtable could be of far better use.

You might not completely understand that last stuff but you will find out if you keep creating stuff.

If this won't give you a clear view of hsahtables, you should look for some tutorials.

 

[Wietlol]

• -------- use the following to save the player if you prefer that. --------
• Custom script: call SaveInteger(udg_your_hashtable, GetHandleId(udg_y), 0, GetOwningPlayer(GetTriggeringUnit())
• -------- use the following to save the specific unit that died. --------
• Custom script: call SaveUnitHandle(udg_your_hashtable, GetHandleId(udg_y), 0, GetTriggeringUnit())

You do know that you can just retrieve the unit and then do "GetOwningPlayer(u)" right?
Saving the player is waste ram data in my opinion.

 

[Chaosy]

true. but if he only wants one, he might as well just use that.