Local variables

[Freyleyes]

So if I am not mistaken the normal variables you declare are Global variables so is there a way to create local variables for GUI triggers? Just a quick variable to use for calculations.

And one more thing : If it is possible to create local variables, would that use less memory than Globals and wouldn't that be better to use?

Thanks for your time.

 

[Deaod]

You can abuse a bug in Jass where you overwrite a global with a local of the same name. But that only works once per trigger. Other than that, you'll have to stick with Jass to use locals. And no, local dont use less memory, their only advantage is their speed (i believe theyre about 9% faster than globals).

 

[Need_O2]

But that only works once per trigger

thanks much, I didnt know this and a problem caused by it (was helping someones GUI spell) completly driven me crazy

 

[MaD[Lion]]

when u declare a local with same name as global, you get into something called "shadowing" (where one var shadow the other). And WE doesnt detect tat so ye

and to use local in GUI:
on top of the gui in either of the Action/Condition or Event use custom script, example for an integer: local integer MyLocalVar

 

[Freyleyes]

So is there a way to declare a local variable using custom script in GUI?
It doesn't have to have the same name as the Globals.

 

[Need_O2]

no...

 

[Eleandor]

Yes, that's possible. You can write down

Custom script: local integer int = 0

Note that as there is no udg_ prefix, you can only use 'int' in custom scripts, and the variable won't appear at your variable list in your GUI actions.

 

[Need_O2]

About the local limit per trigger I think its 2 btw

 

[Eleandor]

There's no limit per trigger. You can, however, only abuse the "udg_" bug once per trigger.

 

[Dr Super Good]

You can declare a reasnoable number of locals per function of atleast 30+ (any more is beyond practical use but probably possiable).
However the "shadowing" problem also occurs with passed parameters if you call those variables the same name as a global.

Also remember that you can not use locals in GUI in some structures if the locals were made at the start of the trigger (eg for groups and if statements) as those make new pointless functions and do not pass locals to them. You however can make new locals within them as they are new functions.

I would advise if you want to use locals to move straight to JASS as GUI's stupid structure will make your life difficult.

 

[Need_O2]

I meant udg abuse
I was using it for A loop
ya know
bj_forLoopAIndex (or whatever its)

 

[Freyleyes]

Thanx people. So if I want to use a local variable I just use the call custom script :

• Custom script - Local Variable Int = 0

where "int" is your variable name.

Thanks for the help. +rep

 

[Need_O2]

actually its

• Custom script: local <variable type> <variable name>

 

[Vegavak]

Thanx people. So if I want to use a local variable I just use the call custom script :

• Custom script - Local Variable Int = 0

where "int" is your variable name.

Thanks for the help. +rep

Use lowercase.

For GUI locals, you need to declare the locals at the beginning of the trigger. You can change them anywhere else in the trigger, however.

• Custom script - local integer int
• Custom script - set int = 200

Like so.

 

[Need_O2]

BTW by limit thing I ment shadowing

 

[Beast(TrOg)]

Oh good, was wondering about GUI local variables also. BTW, how do you call these in GUI, like for damaging:

Cause Triggering unit to damage target unit, dealing (local real) damage of attack type Spells and damage type Normal.

I guess I should start learning JASS also.

 

[Need_O2]

Since Triggering is local only shadowing target unit will be enough (since shadowing limit is 1)
lets say TARGET is a unit variable
Custom script: local unit udg_TARGET
Set TARGET = (Target of Ability Being Cast)
Wait WTFOWNED seconds
Cause (Triggering Unit) to do X damage to TARGET

Oh you want Damage Real as local too ?... well I guess you need to store it inside the custom value of TARGET in this way I guess....

anyway
The thing white line is called shadowing I guess, I mean declaring a local variable with name of a global variable
Its using benefit of a bug and can be only done once in a trigger, a second shadowing wont work