Variables, when to use them?

[SckZ]

Hello!

As the title says, when should I use a variable?

I'm checking over all my triggers and everytime I see something like casting unit, owner of triggering unit, etc. I just put it in a variable and use that variable everytime I need it in the same trigger.

I got a few questions about it...

I know a few things that leak memory, an example of it would be a unit group. I can use destroygroup custom script to.. destroy it. Is there something similar for a single unit? for a single player?

Does it matters if I don't destroy a unit variable at the end of a trigger and use it right away in another trigger?

Now that may sound strange, but I fear that if I use the same variable in 2 triggers that could.. trigger.. like.. at almost the same time that could cause some trouble.. am I right? or do I have nothing to fear about it?

If someone has a tutorial or know a few things about variable I could use such informations.

Thats about all I can think of.. for now

Thanks!

 

[Radicool]

A variable is used whenever you need to remember something. You do not need to store a variable unless it is required by another trigger. Causing triggers to set variables that are not needed, only makes the trigger more laggy (redundant).


Here, you do not need to set the triggering unit to a variable. This is because your computer does not need to remember the triggering unit.

• Trigger 1
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
  • Actions
    • Unit - Add a 60.00 second Generic expiration timer to (Triggering unit)

This trigger causes another trigger to turn on when the unit casts an ability. "Trigger 3" makes every enemy around the casting unit to get hurt every 2 seconds. The computer needs to remember the caster of "Trigger 2" so it can make "Trigger 3" work properly.

• Trigger 2
  • Events
    • Unit - A unit Starts the effect of an ability
  • Conditions
  • Actions
    • Set Unit_Variable = (Triggering unit)
    • Trigger - Turn on Trigger 3 <gen>
    • Wait 10.00 seconds
    • Trigger - Turn off Trigger 3 <gen>

• Trigger 3
  • Events
    • Time - Every 2.00 seconds of game time
  • Conditions
  • Actions
    • Set Unit_Group_Variable = (Units in (Playable map area) matching (((Matching unit) belongs to an enemy of (Owner of Unit_Variable)) Equal to True))
    • Unit Group - Pick every unit in Unit_Group_Variable and do (Actions)
      • Loop - Actions
        • Unit - Cause Unit_Variable to damage (Picked unit), dealing 100.00 damage of attack type Spells and damage type Normal
    • Custom script: call DestroyGroup (udg_Unit_Group_Variable)

Now to your second question: You cannot destroy unit variables (as far as I know). If you have another trigger which sets the unit variable, the old unit that was stored in the variable is forgotten, and the new unit will be remembered in the variable. So, unit variables do not leak.

Third Question: If two triggers use the same unit variable at the same time, one of the units will be forgotten, causing one of the triggers to not work properly. You can fix this by having 1 variable for each trigger.

 

[SckZ]

About the third question. I don't have two triggers starting at the exact same moment but I guess this could happen somehow? I guess triggers are just not smart enough to wait for the first trigger using the variable to finish before using it

 

[Radicool]

About the third question. I don't have two triggers starting at the exact same moment but I guess this could happen somehow? I guess triggers are just not smart enough to wait for the first trigger using the variable to finish before using it

Yeah unfortunately they are not smart enough, lol. If theres a possibility that two triggers will run at the same time, using the same variables, you should make a new variable for each trigger. This ensures they will both work properly.

 

[WaterKnight]

Triggers do not randomly overlap their execution. Wc3 is single-threaded. The trigger that fires first, is served first. When trigger A calls B, then A waits for B to finish. Exceptions are when you include waits since waits push the trigger back in the execution queue and do not pause other triggers.

The equivalent to DestroyGroup for units would be RemoveUnit, which you should know from GUI, too. Players do not have to be destroyed. You do not allocate them dynamically during runtime.

And you should differ between an object and a variable. You do not create nor destroy the group variable either, at least not global variables you know from GUI, you create a new object to store in the variable/destroy the current content. Since you create objects, they should be destroyed when you do not need them anymore. This counts for groups as well as units and other handles. It's called a leak when you cannot release the memory taken anymore, most due to having no possibility to reference the object (e.g. no variable points to it). Units only have the advantage that they have other means of destruction by the native interactive engine (decaying after death).

 

[SckZ]

Triggers do not randomly overlap their execution. Wc3 is single-threaded. The trigger that fires first, is served first. When trigger A calls B, then A waits for B to finish. Exceptions are when you include waits since waits push the trigger back in the execution queue and do not pause other triggers.

The equivalent to DestroyGroup for units would be RemoveUnit, which you should know from GUI, too. Players do not have to be destroyed. You do not allocate them dynamically during runtime.

And you should differ between an object and a variable. You do not create nor destroy the group variable either, at least not global variables you know from GUI, you create a new object to store in the variable/destroy the current content. Since you create objects, they should be destroyed when you do not need them anymore. This counts for groups as well as units and other handles. It's called a leak when you cannot release the memory taken anymore, most due to having no possibility to reference the object (e.g. no variable points to it). Units only have the advantage that they have other means of destruction by the native interactive engine (decaying after death).

That means I can use the same temporary variable for every trigger without fearing that two triggers will use the same variable at the same moment?

 

[WaterKnight]

If the triggers do not have waits and do not call each other/no recursion, then yes.

 

[SckZ]

If the triggers do not have waits and do not call each other/no recursion, then yes.

In case of unit groups or player groups? I mean, does it count as a recursion?

 

[WaterKnight]

A recursion is when a trigger runs itself. Or trigger A runs B and B runs A again etc.

 

[Meticulous]

A variable is used whenever you need to remember something. You do not need to store a variable unless it is required by another trigger. Causing triggers to set variables that are not needed, only makes the trigger more laggy (redundant).

As far as I know, this is false. Variables aren't only useful between different triggers - they save memory within a single trigger as well. Anything you see in brackets - (Picked unit) for example - is a function call. The game engine has to figure out what "picked unit" is EVERY TIME you reference it, as it's very possible (Picked unit) has changed.

Whereas, if you define (Picked unit) as a variable, it doesn't have to figure out what unit you're talking about every time, only when you set the variable to something else. So if you have a trigger that references (Picked unit) 10 times, setting it to a variable instead cuts it from 10 function calls to 2.

Also, it's usually easier to use a variable than to scroll through the drop down menu, so that's another bonus.

 

[defskull]

• Trigger 2
• Events
• Unit - A unit Starts the effect of an ability
• Conditions
• Actions
• Set Unit_Variable = (Triggering unit)
• Trigger - Turn on Trigger 3 <gen>
• Wait 10.00 seconds
• Trigger - Turn off Trigger 3 <gen>

LoL ???
Doesn't make any sense, at all.
You saved a variable of unit, then you turn the trigger off, what the...

MUI-ness of (Triggering unit)
Also, (Triggering unit) act as native function that doesn't require any variable for the trigger to be MUI (NOTE: This only work for (Triggering unit))

But still, meti has his point
If you are using a function call without saving it in a variable, each time the system need to do work (which is less efficient than saving variable and use it many times)

It totally depends on your situation, but all in all, a variable is a must for a programming language.

 

[Radicool]

LoL ???
Doesn't make any sense, at all.
You saved a variable of unit, then you turn the trigger off, what the...

MUI-ness of (Triggering unit)
Also, (Triggering unit) act as native function that doesn't require any variable for the trigger to be MUI (NOTE: This only work for (Triggering unit))

But still, meti has his point
If you are using a function call without saving it in a variable, each time the system need to do work (which is less efficient than saving variable and use it many times)

It totally depends on your situation, but all in all, a variable is a must for a programming language.

The variable set in trigger 2 is utilized by trigger 3. Of course trigger 2 has no purpose alone.........