Triggering Player Variable

[DistantHaze]

Do commands such as "Player Number of Triggering Player" create more "computer drain" in very long triggers? If so, is it better than to set a variable at the start of the trigger (something such as Set X = Player Number of Triggering Player), as in the following example:

Untitled Trigger 001
Events
Conditions
Actions
Player - Set (Triggering player) Current gold to 750
Set Hero[(Player number of (Triggering player))] = (Last created unit)
Set Unit[(Player number of (Triggering player))] = (Sold unit)
Set Target[(Player number of (Triggering player))] = (Target unit of ability being cast)

or

Untitled Trigger 001
Events
Conditions
Actions
Set PlayerNumber = (Player number of (Triggering player))
Player - Set (Player(PlayerNumber)) Current gold to 750
Set Hero[PlayerNumber] = (Last created unit)
Set Unit[PlayerNumber] = (Sold unit)
Set Target[PlayerNumber] = (Target unit of ability being cast)

 

[Tooolbox]

Yes, doing functions repeatedly does consume more computer resources in the long run.

 

[paskovich]

You won't notice that in-game anyway..
But GUI triggers themselves suck more energy than a problem like this... For the best efficiency, do it with jass.

 

[PurplePoot]

Using GUI is much more of a memory eater than that (as paskovitch said), and it's impractical without locals anyhow

 

[DistantHaze]

Thanks for the replies, fellas; but in truth I'm quite noobish at all of this, and all the GUI talk is Greek to me.

Of the 2 examples listed in my post, which would be the more efficient? If it's the latter, would subscribing the same variable PlayerNumber to EVERY trigger pose a problem?

 

[PurplePoot]

The latter, and it wouldn't cause a problem without waits.

It's just that GUI is so inefficient even if you write "perfect" "code" that it's a little weird to be worrying about inefficiency in it (other than leaks or attempted inefficiency)

 

[edge[d1]]

okay, he gets it, gui bad, jass divine... good answer for every gui question...

yes you should save the function result in a variable instead of calling the function 5 times. aside from making your trigger code more efficient, you must know that some of those (Event Response - XXX) functions lose their value after a smallest wait...

mentioning waits brings us to your second question:

would subscribing the same variable PlayerNumber to EVERY trigger pose a problem?

generally, yes. problem lies in waits. whenever you say wait 5 game-time seconds, other triggers will get executed within those 5 seconds (perhaps hundreds), and that can include other instances of the waiting trigger. in a plastic example:

• set X = 7
• Wait 5 game-time seconds.
• Do something important with X

after the wait, X may not be 7 at all! (if no other trigger uses X, it should be 7, but if 20 triggers use X for their purposes, no way it will stay 7 after those 5 sec)

if your map will use complicated triggers, you will soon have to learn about local variables...

and one more word of advice: dont call your global variable X, i or s; always give it a nice and descriptive name.

 

[DistantHaze]

Thanks, guys! If I'm understanding the lessons correctly, then using a command like

local integer X //or something more creative than X, as edge[d1] points out
set X = (TriggeringPlayer) //this is just for show, I know it's really something like GetConvertedID...blah.blah...

will generate a unique version of X for each player executing the trigger, even if it's simultaneously?

Set Hero(X) = last created unit, for example, would then also be unique for each player applying this trigger?

I really appreciate all the feedback!

 

[PurplePoot]

You can initialize variables, btw

Such as

local integer x = GetPlayerId(GetTriggeringPlayer())

 

[paskovich]

But you cannot use them as globals! It won't appear on the variable list. You have to put the correct GUI-to-JASS converted lines instead of GUI actions. Like:
local integer n = GetPlayerId(GetTriggeringPlayer())
set udg_Hero[n] = GetLastCreatedUnit()
set udg_Unit[n] = GetSoldUnit()
...
All of them as custom script.