[Trigger] Locals and conditions failing?

[Br0]

Why doesn't this work?

[trigger=]
Events
Unit - A unit Starts the effect of an ability
Conditions
(Ability being cast) Equal to Load
Actions
Custom script: local unit udg_caster = GetTriggerUnit()
Custom script: local unit udg_tgtdunit = GetSpellTargetUnit()
If (All Conditions are True) then do (Then Actions) else do (Else Actions)
If - Conditions
(Unit-type of tgtdunit) Equal to Peon
Then - Actions
Unit - Add Battle Stations - peon to caster
Else - Actions
If (All Conditions are True) then do (Then Actions) else do (Else Actions)
If - Conditions
(Unit-type of tgtdunit) Equal to Grunt
Then - Actions
Unit - Add Battle Stations - grunt to caster
Else - Actions
If (All Conditions are True) then do (Then Actions) else do (Else Actions)
If - Conditions
(Unit-type of tgtdunit) Equal to Raider
Then - Actions
Unit - Add Battle Stations - raider to caster
Else - Actions
If (All Conditions are True) then do (Then Actions) else do (Else Actions)
If - Conditions
(Unit-type of tgtdunit) Equal to Tauren Chieftain
Then - Actions
Unit - Add Battle Stations - hero tauren chief to caster
Else - Actions
Custom script: set udg_tgtdunit = null
Custom script: set udg_caster = null
[/trigger]

 

[Mr_Bean]

How are you able to use the GUI actions to add abilities to local units? Have you declared the global variables caster and tgtdunit in the variable editor?

 

[ap0calypse]

How are you able to use the GUI actions to add abilities to local units? Have you declared the global variables caster and tgtdunit in the variable editor?

Locals > globals. If you have 2 variables with the same name, 1 a global and the other a local, then the trigger will only read the local.
This is useful to trick GUI into being able to use locals the way Br0 did (by creating a local with the same name as the global).
He needs to have it initialized in the variable editor, otherwise he cannot use it in GUI, so I think he did do that


In any case, why are you even doing this trick? There aren't any waits in your trigger or anything else that could cause a variable mix-up.
Besides, triggering unit is always a local so there's no need for that.
Just use the normal GUI set variable actions, see if that works.

 

[Br0]

The triggering unit wouldn't fail however the target unit of ability being cast would surely fail on being MUI wouldn't it?

 

[ap0calypse]

The triggering unit wouldn't fail however the target unit of ability being cast would surely fail on being MUI wouldn't it?

Here's an example:

• Actions
  • Custom script: local unit udg_target = GetSpellTargetUnit()
  • Unit - Add Invisibility to target
  • Custom script: set udg_target = null

• Actions
  • Set target = (Target unit of ability being cast)
  • Unit - Add Invisibility to target

Do you think both of them are equally MUI?
(Answer: they are both MUI).

This is actually what your trigger does: it just sets a unit variable and adds an ability to that unit.
Since there are no waits, everything happens in an instant: variables cannot be overwritten while a trigger is still running.

If you had done this:

• Actions
  • Set target = (Target unit of ability being cast)
  • Wait 1.00 seconds
  • Unit - Add Invisibility to target

This is NOT MUI. If people cast it fast enough it will fail.
Using locals here is a good option.


I hope you got the point of my stupid trigger-examples? If not, I can try to explain it with words as well

 

[Mr_Bean]

Locals > globals. If you have 2 variables with the same name, 1 a global and the other a local, then the trigger will only read the local.

Of course I know locals are better than globals...
I was just confused because I didn't know of this trick because I never use GUI.

 

[Br0]

Thank you ap0calypse.

 

[ap0calypse]

Of course I know locals are better than globals...
I was just confused because I didn't know of this trick because I never use GUI.

Oh no, I don't mean "better than", I mean they have a higher priority. So locals > globals priority-wise
So a local named "unit" will always be used in a trigger, even when there's a global named "unit".
I'm sorry for the confusion, didn't mean to insult you by spouting out obvious things.

 

[Mr_Bean]

Oh okay. It's no problem! Thanks for the information.

 

[WaterKnight]

Conditions in GUI are organized in private functions. Locals only exist within a function call. So in the above trigger, the conditions read the global variable.

In addition to waits presenting a problem with global variables for MUIness, you should also pay attention if you have actions there that trigger other parts of the code.

 

[blit_40912]

noob here, how am i suppose to know if a variable is global/local. I know from c/c++ a global is something that can be used anywhere and it can be supplied to other function that can be changed by using refs and ptrs. A local in the other hand can be only within a function and it has a limited scope. i'm just not sure how to classify thing here in trigger editor

 

[Adiktuz]

globals are created in the variable editor for GUI, and inside global blocks in vJASS
while locals are created using the local blocks local type name