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!
For GUI/JASS, I've seen some people say you should always set all your variables at the beginning of the trigger instead of always using "Get Last Created Unit" or "Player # of Owner of Picked Unit" etc. Instead they will just set everything in variables at the beginning of the trigger.
The idea of setting things into variables at the beginning of the trigger is related to "Optimization", besides allowing further actions (like leak removal).
See, whenever you see a pair of parentheses -> ()'s <- The game searches in the data for that value, that can be a unit, a number, an order, or anything. Now, if you're using 20 times (Triggering Unit) the game is looking in the data 20 times for the same unit. It's like going to the market to buy 20 beers, but buy 1, and come back home, and go to the store again... 20 times.
When you set the value to the variable, you're just requesting the data once, to store it into the variable, from there on, you use the variable, which data is already known to the system. This means the trigger runs faster, requires less memory, less system resources, and so on.
This is most important on periodic triggers, which run every 0.03 seconds (nearly 33 times per second). Looking 20 times for the (Triggering Unit) every 0.03 seconds would mean 33*20 = 660 data requirements (for second). Now, set the Unit life to a variable, and you're requesting data once, that would turn into 33*1 = 33. Still, it's a good practice to do it everytime, even on Map Initialization, which runs once.
That's trigger optimization: Turn 660 system data retrievings into 33, and achieve the same results.
Now, difference between Locals and Globals (in matters of efficiency) are that variables are a peace of memory that's reserved to store a certain type of data, like a unit. If you have 10 global variables for units, you're retrieving a certain amount of memory for those globals, even if you don't use them, which would mean a waste. Locals are dinamically created and nulled/destroyed, so they just require memory when they're being used, and then release it. Locals are also usefull just inside the function they're being used at.
It also reduces script size: If you're using "p" a a player variable, it's a lot shorter than "(Triggering Player)" or jassed "GetTriggerPlayer()". Be aware that all the triggers and scripts are writed on the map save, and read leter on map loading: More text -> More time. More variables -> More time. More functions -> More time. Longer Functions -> More time. That's why everyone tries to use the less, exact and precise data.
JASS:
local player TriggerPlayer = GetTriggerPlayer()
set TriggerPlayer = null
// That's a lot longer than
local player p=GetTriggerPlayer()
set p=null
It is really like this: variable value return is much faster than function return, which means that it is much better to store Trigger Unit/GetTriggerUnit() in a variable, and then use that variable for operations later. Of course, null any local handles at the end, remember that.
It is really like this: variable value return is much faster than function return, which means that it is much better to store Trigger Unit/GetTriggerUnit() in a variable, and then use that variable for operations later.
I was emphasizing on this statement.
You should at least mention that there are few cases which you should not store value in a variable.
I know it's obvious for you, but not obvious for new-learners.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
Melee Initialization
Events
Unit - A unit Starts the effect of an ability
Conditions
Actions
Set u = (Triggering unit)
