SC2Mapster

So I have this trigger which fires when any unit gains a behaviour and then sets some variable[owner of triggering unit]. The size of the array is set to 4 as their are only four players on the map. This bugged, because, as I found out, sometimes "owner of triggering unit" is 16. Now, 0-15 are the only possible player numbers and "no player" is -1. Who is player 16?

edit: OK, apparently while "no player" is -1 the "owner of no unit" is player 16. This confuses me even more as the event triggers when any unit gains a behaviour and the triggering unit is no unit o.O

@Elmaex: Go

@Elmaex: Go

also the game itself is player 16. killing units with triggers as example

Make your player-based arrays have a size of at least 16 and you won't exceed array bounds when it comes to players. I'm sure there's a more efficient way to deal with it for those of you who obsess over code efficiency, but most maps will work just fine with size-16 arrays storing player numbers.

16 is a default return value if certain functions can not return the proper player, for example when trying to get the owner of a non existing unit. The proper way of dealing with this is checking if the unit is valid before calling the function, and if not perform different actions.

As an example, if your trigger reacts to a behavior, you should check if the triggering unit is != null (The best way of doing this is by using the UnitIsAlive() function), and only if it exists set your variable.

@BasharTeg: Go

Yeah, that was solving the problem but the variable was a record with a bunch of things in it, so I wanted to avoid it. Also I was curious ;)

@Mille25: Go

Thanks a ton!

edit: Does this mean that a trigger does not run through in one step but instead all events are first collected and then the actions performed one after the other? That way my unit might have been detected to gain a behavior and then been removed before the action could be performed?

@Elmaex: Go

As Millie said, you basically have to restrict handling variables that reference players to functions that can be qualified beforehand with a conditional check. i.e.:

If
   Unit_var is alive == True
Then
   Send message to Player_var(Owner of Unit_var): You blowed up that thar unit!
   Kill Unit_var

Alternatively, you could run a conditional check this way:

If
   Owner of (triggering unit) >= 1
   Owner of (triggering unit) <= 4
Then
   Send message to Player_var(Owner of (triggering unit)): You blowed up that thar unit!
   Kill (triggering unit)

A bit circuitous, maybe, but there you go.