A 'this' bug or am I missing something

[louiscar]

Firstly sorry if this isn't appropriate for the advanced section, I am trying to get an understanding of whether this is a bug or a 'feature'.

The problem happens on a simple script that was designed as a generic event handler for a UAZ. The purpose (although it could be anything) was in this case to make the driver of a UAZ get out of the vehicle if the gunner was shot, he'd then eventually get back in but as a gunner.

In init for the UAZ I put this:

gunner this addEventHandler ["killed",{this exec "uaz.sqs"}]

UAZ.SQS reads thus:



_driver = driver _this
_grp = group _this

_driver setcombatmode "RED"

~0.5

_grp leaveVehicle _this

_driver action ["GETOUT",_this]

_driver assignasgunner _this

exit

.. and that works fine, however, when this was inserted in the mission it didn't work, the driver failed to react.

BTW if anyone wonders why addressing the group in the script was necessary, I found this to be necessary only when a uaz was created complete with crew. It wasn't necessary if an empty uaz was created and two guys were moved  into it. Otherwise what happened was the driver would simply get back in as a driver even after temporarily getting in as gunner. But this is beside the point.


Upon investigation what DID make it work was to name the UAZ and use the name to pass to the script (note that it was quite happy to deal with 'gunner this'). Not very elegant for a generic script, I didn't want to add to the plethora of names in a big mission.
So ...

gunner this addEventHandler ["killed",{uaz1 exec "uaz.sqs"}]

worked in the mission.

Anyway I started to try to find out why the original didn't work and although I didn't find all instances (I virtually had to delete everything off the map) I did find out some of the things that stopped it from working and in some cases an error was generated. I stress only SOME.

1) Putting a single trigger on the map with anything other than 'this' as a condition.

or

2) putting anything into the player's initialisation field.

That's as far as I got but I am assuming that anything in an init field would probably do the same and god knows what else.

The error when it chose to come up would complain about a variable type on the line:

_driver assignasgunner _this, but as I say this didn't always occur but the driver still failed to act.

Any ideas out of interest why this happens? Is it a bug or is there a logical reason for why it doesn't work with the above conditons?

[h-]

In the case of the 'full' uaz the driver will not get in as gunner because the dead gunner is still assigned as gunner to the vehicle, and that's why the group has to be unassigned from it.. Weird though, smells like a bug..

As for the error message and the things making it not to work, all I can say that unbelievable  ..
I can confirm this, if I put a trigger on the map with condition !(alive (driver uaz)) the script will spew an error:
"Error in expression <_driver = driver _this>
  Error position: <driver _this>
  Error driver: Type Bool, expected Object"

And if I write something like this addMagazine "Handgrenade" in player's init field the script runs but the driver will not budge, it just sits in the vehicle...
There's something very fishy going on..

EDIT:
This has to be a bug..

Upon testing what exactly does _this contain in the script:
- When using the trigger condition mentioned above, _this contains a string "FALSE"
- When using the player's init field thing _this contains, you never guessed, the player..

How is it possible that those can replace this in the uaz's init field... 

EDIT2:
Ok, solved your problem.
BIS have apparently screwed up something in the 'global space' (no they haven't... )
You need to adjust your init field thing a bit on the uaz, you need to name the gunner (I'm using gunny in this example)

Code: [Select]

gunny=(gunner this); gunny addEventHandler ["killed",{(vehicle gunny) exec "uaz.sqs"}]Now the vehicle is identified by a name, like when you named it manually but this time it's generic. This bypasses the odd problem.

EDIT3:
Hmmmm, now to think of it it isn't a bug at all, makes perfect sense really 
this is a global pointer so obviously it will point to what it has been used to point to the last time.

This same thing exists in OFP as well...

[Spooner]

@louiscar:
You can put code blocks in code tags to make it stand out, rather than changing its colour. Just select the code block and press the button with # on it, which is just above where you are typing.

I know that h- answered this in a round-about way, but to clarify, all you needed was to use _this (the parameters passed to the event handler), not this (a global variable with undefined contents), in the UAZ init:

Code: (WRONG! See posts below for correction) [Select]

(gunner this) addEventHandler ["killed",{_this exec "uaz.sqs"}]


[h-]

Spooner, using _this will render the script useless because it no longer refers to the vehicle but to the gunner, and the whole point of this hasle was that the eventhandler is 'in' the gunner and the vehicle is the one passed into the script..

I would have offered that advice myself but I tested this and for some reason the vehicle command doesn't return the gunner's vehicle in the script, just the gunner itself, so you can't refer to the vehicle in any other way.. 
If it would return the vehicle then _this could be used and the script modified to comply it..

[Spooner]

Oops, you are quite right: Your code works and my "correction" doesn't! Still, to avoid the need to change the script or assign the gunner to a global variable (Which was my reason for posting my "correction"), the init should be:

Code: (UAZ init) [Select]

(gunner this) addEventHandler ["killed",{(vehicle (_this select 0)) exec "uaz.sqs"}]

Although this is a trivial change to what -h suggested above, it makes it much easier to add the script to many vehicles without needing to change the init line.

One other issue that needs mentioning is that should the gunner get out of the vehicle for some reason, then the killed handler may well raise an error. Probably won't be an issue, since soldiers don't get usually get out of vehicles, but something that might cause errors in certain situations (something to think about for the future, not worry about now).

[h-]

Doh... 
Now why didn't I think of that.. 

Although, the global variable thingy in this case is not really an issue, the gunny would each time be the gunner of the vehicle in question. But your code is way better..

[Spooner]

Actually, if the global variable gunny was set in more than one UAZ init, then its value, at the time the killed handlers were fired, would be the gunner on the last UAZ to be created, which would not necessarily be the the gunner that actually just died. You'd have to use a different global variable in each init to avoid that problem, which could easily lead to errors if the code wasn't edited properly after being pasted into the init.

[louiscar]

Thanks for the all the input h- and Spooner.

This is interesting:
I understood that using _this would cause a 'local variable used in global space' error.

I'm curious why your version works then because although you are referencing it as the first element of an array it's still a local variable?

(gunner this) addEventHandler ["killed",{(vehicle (_this select 0)) exec "uaz.sqs"}]

I think I prefer this version for obvious reasons and it works well, just curious about the _this.

Thanks for your help.

[h-]

_this works because it's 'in' the eventHandler which is in it's own local scope (in global space).

Just like _x works with forEach even if you use it in global space.
It's the few things that the engine allows to be used like that..

[louiscar]

_this works because it's 'in' the eventHandler which is in it's own local scope (in global space).

Understood, thanks for the logic of this one. I'm going to have to remember this for later.