Is a hash table as easy as saying (Hash table of unit(footman)) which I set as 1, same as point value?
Sorry, if I had an example of how to set 3 units' IDs in a hash table and then use them in the trigger I should be able to apply that same method to the other 50 or so. Would you be able to give me 3 examples of the method? (just so I can be certain what changes and what stays the same between units)
A Hashtable is
basically an Array with an extra [index]. Also, known as a 2D array.
The first thing you need to understand is the concept of a Handle Id. In Warcraft 3 (and basically any game), each Object has a unique Integer Id that represents it. This is a way for the program to distinguish things apart, you can think of it like a phone number, a state id, a ssn, etc. In this case it's often a long Integer like 1249358447.
A normal Array, which is what was being used for ModelPath, has a limitation where it can only use an index ranging from [0] to [32768]. This is an efficiency thing and is limited in order to preserve memory since a computer would struggle to store Arrays with huge ranges. Although it doesn't really apply to modern hardware but Warcraft 3 is 20 years old and has limitations related to that era. This is why we rely on things like Unit Indexing and Point-Values since we can control those and keep them within the bounds of the Array.
Anyway, with that limitation in mind it means that we cannot plug a Handle Id inside of an Array [index], which is a shame because it'd be great to be able to do something like this:
-
Events
-

Unit - A unit Acquires an Item
-
Conditions
-

(Item-type of (Item being manipulated) Equal to Mage's Staff
-
Actions
-

Set Variable Spell_Power[(Hero manipulating item)] = 100
^ So when a Hero acquires an Item we increase their "Spell Power" stat by 100. We use the Unit directly as the [index], which would actually be it's Handle Id. Unfortunately, that's not actually possible with a standard Array...
Fortunately, Hashtables solve this problem! Here's the same trigger using this new technique:
-
Events
-

Unit - A unit Acquires an Item
-
Conditions
-

(Item-type of (Item being manipulated) Equal to Mage's Staff
-
Actions
-

Hashtable - Save 100 as 1 of (Key (Hero manipulating item)) in MyHashtable
^ This does the same thing as the above trigger but we've now introduced a new [index] and can use our Unit as one of the two [indexes].
This effectively does the following:
-
Actions
-

Set Variable MyHashtable[(Hero manipulating item)][1] = 100
You can change the number
1 to ANY Integer that you want, it basically acts like a unique category. In this case I am using
1 to represent Spell Power. But if I wanted even more custom stats then I would want to use a different number for them.
Here's a more advanced example with some extra variables to help with the clarity (they're optional). Let's introduce Block_Chance as another custom stat and let's actually increase the values rather than overwrite them:
-
Events
-

Unit - A unit Acquires an Item
-
Conditions
-

(Item-type of (Item being manipulated) Equal to Mage's Shield
-
Actions
-

-------- Let's get an efficient reference to our unit's Handle --------
-

Set Variable TempHandle = (Hero manipulating item)
-

-------- --------
-

-------- Let's load our unit's Spell Power and Block Chance from our Hashtable --------
-

Set Variable TempSpellPower = (Load 1 of TempHandle from MyHashtable)
-

Set Variable TempBlockChance = (Load 2 of TempHandle from MyHashtable)
-

-------- --------
-

-------- Let's increase the unit's Spell Power by 100 and Block Chance by 50 --------
-

Set Variable TempSpellPower = (TempSpellPower + 100)
-

Set Variable TempBlockChance = (TempBlockChance + 50)
-

-------- --------
-

-------- Let's save these values, updating them in our Hashtable --------
-

Hashtable - Save TempSpellPower as 1 of TempHandle in MyHashtable)
-

Hashtable - Save TempBlockChance as 2 of TempHandle in MyHashtable)
So we've effectively Loaded data from our Hashtable, increased it, then Saved it, overwriting their previous values.
"Loading" and "Saving" is just another way of saying "Getting" and "Setting" data, which you've been doing all of this time with normal Variables.
Remember, you can Load this data whenever you want, so it wouldn't be difficult to Load these custom stats in say a trigger that uses Spell Power to increase your damage dealt or a trigger that handles Block Chance to reduce damage taken. Also, a Hashtable can Save any
TYPE of data, it doesn't just have to be Integers. So Block Chance could be a Real like 50.00%, etc.
Variable
Types used here:
TempHandle =
Handle
TempSpellPower =
Integer
TempBlockChance =
Integer
Lastly, but extremely important, you have to actually create and store your Hashtables manually:
-
Events
-

Map initialization
-
Conditions
-
Actions
-

Hashtable - Create a hashtable
-

Set Variable MyHashtable = (Last created hashtable)
Do this before you try to use it! A Hashtable can contain a massive amount of data so this creation is necessary (again, efficiency thing). You're limited to 255 Hashtables in a single map, however, that's basically impossible to reach and you're using them wrong if you how somehow get even close to that number.
Edit: Nvm I've just realised a problem with this idea. My map is basically a melee map but with some elaborate creep camps, creep settlements, and some custom heroes. But outside of that it's supposed to be a regular VS map where you can use reforged graphics and skins. So if I set the archmage unit model as 1 in an array (only heroes can enter the arena with the Scorpion) and then someone using the Jaina skin gets impaled, the special effect will be a regular archmage.
I'll either have to drag the unit around or scrap the idea. Probably better to just give them a stunning poison or something.
Like Pyro and I said, it's easier to Move the Unit rather than a Special Effect. You're just creating extra steps with the Special Effect.
If you're on the latest patch I can show you how to do it, although I'm sure there's a "Flaming Lasso" (DotA ability that drags a unit) on Hive which you could use as a starting point.