• 🏆 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!
  • 🏆 Hive's 6th HD Modeling Contest: Mechanical is now open! Design and model a mechanical creature, mechanized animal, a futuristic robotic being, or anything else your imagination can tinker with! 📅 Submissions close on June 30, 2024. Don't miss this opportunity to let your creativity shine! Enter now and show us your mechanical masterpiece! 🔗 Click here to enter!

Hashtables go both ways?

Status
Not open for further replies.
Level 8
Joined
Sep 30, 2012
Messages
205
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

Tutorial Reviewer
Level 40
Joined
Jun 9, 2011
Messages
13,185
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())
 
Level 24
Joined
Aug 1, 2013
Messages
4,657
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)
Player123456789101112

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.
 
Level 24
Joined
Aug 1, 2013
Messages
4,657
  • -------- 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.
 
Status
Not open for further replies.
Top