Linking multiple variables?

[Shaeam]

I'm not too sure how to describe what I need to do adequately; but essentially, I'd like to make a variable that serves as a table for another variable. I've never really done anything like that before and I feel like it's incredibly simple; I'm just not sure how to approach it.

To give an example; Each unit has it's own variable, that variable allows the system to determine which table it should use between the unit's individual common/rare/incredibly rare drops.

 

[HappyTauren]

What kind of triggering can you use? GUI, jass, vjass?

 

[TriggerHappy]

A hashtable would be easiest.

You would create an array (or multiple) containing the data for each "table".

Then in the hashtable you store the array index of the table you want to associate with your unit.

Hashtable - Save ArrayIndex as 0 of (Key YourUnit) in (Last created hashtable)

Then you can load the array index of your table with the hashtable load function.

Alternatively you could implement a unit indexing system and use arrays, which would be better performance-wise.

 

[HappyTauren]

Or you could do it in accordance with the unit type and just save all the data in a Hashtable. It is not a performance based systems so a Hashtable's a pretty good choice, plus very easy to implement.

 

[Wietlol]

Happy party here hehe

The first thing that you have to choose is on what level of uniqueness you want the tables to be.
For each unit type? For each specific unit? etc.

If it should be for each unit type, then you pretty much already have your stuff done following the above replies.
However, it could be helpfull to give you a small explaination of what you really want to store in that hashtable.

What you describe as a table is simple one, 1, fourhundred minus threehundred-nintynine object.
An object can be anything that you want it to be and in this case it is a table of items.
In JASS/vJASS (meaning GUI as well), objects are referenced simply by an integer.
The integer is used to access the fields (data) of that object from arrays or a hashtable where the actual data is stored.
In those arrays, you will have stored a few items with their corresponding drop rates and amounts and whatever you want to have as features.

What you want to store per unit type is simply that integer that is used as index.
Unfortunately, in JNGP (which you should have though), you cant use keys in GUI to access hashtable data.
So you should use a small custom script to get the unit type id of a unit to use it as an integer as key of the hashtable.

"Custom Script: set udg_TempInteger = GetUnitTypeId(udg_TempUnit)"
This custom script will store the unit type id of TempUnit (a global variable) in TempInteger (another global variable)
Then you can use TempInteger in the hashtable as key.

 

[Shaeam]

What kind of triggering can you use? GUI, jass, vjass?

GUI, specifically. I know how to modify VJASS and call custom scripts but I'm still in the process of fully learning the system.

A hashtable would be easiest.

You would create an array (or multiple) containing the data for each "table".

Then in the hashtable you store the array index of the table you want to associate with your unit.

Hashtable - Save ArrayIndex as 0 of (Key YourUnit) in (Last created hashtable)

Then you can load the array index of your table with the hashtable load function.

Alternatively you could implement a unit indexing system and use arrays, which would be better performance-wise.

Thank you; I actually didn't think of using hashtables since it's something I rarely use, since they've been suggested twice I think I'm going to experiment with them and see if they will actually work.

Happy party here hehe

The first thing that you have to choose is on what level of uniqueness you want the tables to be.
For each unit type? For each specific unit? etc.

If it should be for each unit type, then you pretty much already have your stuff done following the above replies.
However, it could be helpfull to give you a small explaination of what you really want to store in that hashtable.

What you describe as a table is simple one, 1, fourhundred minus threehundred-nintynine object.
An object can be anything that you want it to be and in this case it is a table of items.
In JASS/vJASS (meaning GUI as well), objects are referenced simply by an integer.
The integer is used to access the fields (data) of that object from arrays or a hashtable where the actual data is stored.
In those arrays, you will have stored a few items with their corresponding drop rates and amounts and whatever you want to have as features.

What you want to store per unit type is simply that integer that is used as index.
Unfortunately, in JNGP (which you should have though), you cant use keys in GUI to access hashtable data.
So you should use a small custom script to get the unit type id of a unit to use it as an integer as key of the hashtable.

"Custom Script: set udg_TempInteger = GetUnitTypeId(udg_TempUnit)"
This custom script will store the unit type id of TempUnit (a global variable) in TempInteger (another global variable)
Then you can use TempInteger in the hashtable as key.

It's for a specific unit-type; for example I'd like to make a specific table for each hero-type. To clarify; I'm creating some AI inside of my map. Each Hero-type has a table of items they can purchase (I used the item-drop example because I feel that it would've been easier to understand without in-depth explanation) each Hero-Type table needs three different values; first off it needs to check when the Hero reaches max gold of the highest valued item they can purchase (which varies from Hero to Hero; so it needs it's own variable), then inside of another variable would be the specific items, and then another variable would be the prices of those said items. Hopefully that helps to understand what I'm trying to create.

Though; with your explanation of the Hashtables; I think you're right in suggesting them over variables... I think I'll end up swapping over to those and give that a try.

I am using JNGP, just for the record though.



REP for all the people who responded! Thanks!

 

[Wietlol]

Using a hashtable can be of 2 reasons:
1, you need to store data on a key above 8190. (object types like units, items, doodads, abilities, etc)
2, you need to have more than 8190 instances of your object. (this is hardly imaginable but it is a valid reason)

For everything else, you could just use arrays which is a good habit.

The price of the items should not depend on the hero right?
The ring of protection doesnt cost more for the paladin than it does for the archmage.
The price of the items should be stored under their items' keys.
For these features, a hashtable is used often (to store data per item/unit type specific).
If you simply use the gold value from the object editor, you can even use the Object Data Extractor (just google it) to load in those values automatically.

All you should be storing per hero type is the items they should be buying (preferably in the order they should be bought).

 

[Shaeam]

Using a hashtable can be of 2 reasons:
1, you need to store data on a key above 8190. (object types like units, items, doodads, abilities, etc)
2, you need to have more than 8190 instances of your object. (this is hardly imaginable but it is a valid reason)

For everything else, you could just use arrays which is a good habit.

The price of the items should not depend on the hero right?
The ring of protection doesnt cost more for the paladin than it does for the archmage.
The price of the items should be stored under their items' keys.
For these features, a hashtable is used often (to store data per item/unit type specific).
If you simply use the gold value from the object editor, you can even use the Object Data Extractor (just google it) to load in those values automatically.

All you should be storing per hero type is the items they should be buying (preferably in the order they should be bought).

The price of the 'item' DOESN'T cost more on a per-hero basis; that'd be silly. What I mean is the MAX item cost of the total of the hero's pools of items does change per-Hero basis. For example; if the Hero's item pool had a Ring of Protection, Claws of Attack, or a Mask of Death; the Hero's maximum item cost would be 800 (for the Mask of Death) whenever the bot has gold over or equal to the maximum cost for the item; that's when they head to the shops.

Hopefully that makes sense, hah.

 

[Wietlol]

It would make sense that they would go back to the shop to buy items as soon as they can buy some, but ok.
You can still just loop through all the 6 (not so much) items that the hero wants (still wants) and calculate the required money.
It wont make much of a difference.

The easiest way would be to store their items in a hashtable directly.
Key hero type and Key 1 to 6 (or 0 to 5 if you prefer that)
Then you can just read in the values in the hashtable to find your required items.

• Init Hero Item Data
  • Events
    • Time - Elapsed game time is 0.00 seconds
  • Conditions
  • Actions
    • Hashtable - Create a hashtable
    • Set HI_Hashtable = (Last created hashtable)
    • -------- - --------
    • Set HI_HeroType = Paladin
    • Set HI_ItemType[0] = Claws of Attack +15
    • Set HI_ItemType[1] = Claws of Attack +15
    • Set HI_ItemType[2] = Claws of Attack +15
    • Set HI_ItemType[3] = Claws of Attack +15
    • Set HI_ItemType[4] = Claws of Attack +15
    • Set HI_ItemType[5] = Claws of Attack +15
    • Trigger - Run Register Hero Item Data <gen> (ignoring conditions)
    • -------- - --------
    • Set HI_HeroType = Archmage
    • Set HI_ItemType[0] = Claws of Attack +15
    • Set HI_ItemType[1] = Claws of Attack +15
    • Set HI_ItemType[2] = Claws of Attack +15
    • Set HI_ItemType[3] = Claws of Attack +15
    • Trigger - Run Register Hero Item Data <gen> (ignoring conditions)
    • -------- - --------
    • Set HI_HeroType = Mountain King
    • Set HI_ItemType[0] = Claws of Attack +15
    • Set HI_ItemType[1] = Claws of Attack +15
    • Set HI_ItemType[2] = Claws of Attack +15
    • Set HI_ItemType[3] = Claws of Attack +15
    • Trigger - Run Register Hero Item Data <gen> (ignoring conditions)

• Register Hero Item Data
  • Events
  • Conditions
  • Actions
    • Custom script: set udg_TempInteger[2] = udg_HI_HeroType
    • For each (Integer TempInteger[1]) from 0 to 5, do (Actions)
      • Loop - Actions
        • Custom script: set udg_TempInteger[0] = udg_HI_ItemType[udg_TempInteger[1]]
        • Custom script: set udg_HI_ItemType[udg_TempInteger[1]] = 0
        • Hashtable - Save TempInteger[0] as TempInteger[1] of TempInteger[2] in HI_Hashtable

Ofcourse you may want to use other data than claws of attack, but this is one way of doing the item type registration.

At any time of the game, you can load in those item types from the hashtable.
The only problem is that a hashtable doesnt load and save item types, but instead it loads and saves integers. There is little difference except in GUI, where you have to parse them to different variables like I did in the Register Hero Item Data:
"Custom script: set udg_IntegerVariable = udg_ItemTypeVariable"