• Listen to a special audio message from Bill Roper to the Hive Workshop community (Bill is a former Vice President of Blizzard Entertainment, Producer, Designer, Musician, Voice Actor) 🔗Click here to hear his message!
  • Read Evilhog's interview with Gregory Alper, the original composer of the music for WarCraft: Orcs & Humans 🔗Click here to read the full interview.

efficiency of triggers

Status
Not open for further replies.
Level 17
Joined
Mar 21, 2011
Messages
1,611
hi everyone, i have a REALLY simple question

first case:
Set Caster[1] = Casting unit
Set Target[1] = Targeted unit of ability being cast
cause Caster[1] to damage Target[1] dealing 500 damage

second case:
Set Caster = Casting unit
Set Target = Targeted unit of ability being cast
cause Caster to damage Target dealing 500 damage


is the second trigger more efficient than the first?
are there any other negative points for first case EXCEPT of the variables cost more bytes?
 
Level 33
Joined
Mar 27, 2008
Messages
8,035
Actually, both triggers are inefficient :)
Why ?

Because you actually can directly call the function and use it (because you just use it once per run-time, it's fine).

So, this is the most efficient by far:
  • Unit - Cause (Triggering unit) to damage (Target unit of ability being cast), dealing 500.00 damage of attack type Spells and damage type Normal
If you're gonna call the function only once per run, you should just call it without saving them into a variable.
 
Level 10
Joined
Jun 6, 2007
Messages
392
Correct me if I'm wrong, but I think there's no difference in your examples in terms of efficiency (speed). However, the first example uses much more memory (as far as I know the size of all arrays is 8192).

As defskull said, only if you refer to a value more than once, set it to a variable. Also triggering unit is more efficient than casting unit or target unit.

Well, if it is a negative point, using arrays when you can use variables makes the trigger look messy, at least in my opinion.
 
Level 33
Joined
Mar 27, 2008
Messages
8,035
Arrays is used for, well, to reduce the amount of variable;

Let's say you need to have 12 Player variable, you need only 1 array variable to represent all 12 of them, instead of creating 12 variable, 1 variable for each player.

Each of it has its own advantage, use it wisely.
 
Level 33
Joined
Mar 27, 2008
Messages
8,035
It is VERY unefficient to do that, since each array slot will keep increasing (takes more space) unless you dynamic indexing (clears the array after use).

I suggest to use 1 (depends how many) global variable for all unit in the map.

For example, you have TempUnit1 and TempUnit2 variable.
Just use both of these variable at all times.

But make sure that those spells are instant, this way, the variable will not be overwritten and can be MUI by just using those 2 variables for all triggers.

You don't need to create 1 variable for 1 trigger, dude.

That's why we name it "Temp", to acknowledge users that the variable is just used for "Temporarily".
 
Level 17
Joined
Mar 21, 2011
Messages
1,611
so i should use TempUnit for each instant spell and a own variable for duration spells?
about dynamic indexing..
im using bribes unit indexer, and i have some skills where i need array (to load some data i did based on the units value), for example a Spellpower stat that i add to a unit.
so i have to load the Integer_Spellpower[UnitValue] to get the spellpower.
do i need to do dynamic indexing in that case?
 
Level 33
Joined
Mar 27, 2008
Messages
8,035
Not to advertise or something but, can you check on my Signature the Spell Power system ?
It does the same thing, you get the Spell Power value from an item that is pre-set via triggers before the game starts.

Also, don't get confuse with Unit Indexer and Indexing, they're both different thing.

For more info (difference between Hashtable/Unit Indexer/Indexing):
http://www.hiveworkshop.com/forums/triggers-scripts-269/arrays-hashtables-223616/#post2225726
http://www.hiveworkshop.com/forums/triggers-scripts-269/arrays-hashtables-223616/#post2225735
 
Status
Not open for further replies.
Top