Oil pumps

[h-]

@Mandoble && bardosy
Guys, you are going way too complicated routes here 

Use the fired eventHandler:

Code: [Select]

this addEventHandler ["fired",{(nearestObject [_this select 0,_this select 4]) execVM "detonated.sqf"}]
detonated.sqf

Code: [Select]

waitUntil {isNull _this};
sleep 1;
hint "bob's yer unca, insert code here";The hint is there so that you can test this..

[bardosy]

@-h

I don't understand this code, but I want.
1. Who needs this eventHandler? I guess to the player, aren't he?
2. How do you know, the player fired by a satchel? What will happen, if he fired with a pistol?
3. You gave 2 parametersd to detonated.sqf, but check only one or both in waitUntil {isNull _this};
4. This waitUntil check the detonation?

[h-]

Urp, I'm quite bad at explaining things, but I'll try..

1.
Yes, the player.

2.
Of course the code was just an example, indeed you need a check to see whether it was satchel that was 'fired'..
If you did not have such an check you could have awful lot of detonate.sqf scripts running after a firefight..

There's two ways to do that.
First, just to remind that the fired eventHandler 'releases' an array of variables into it's scope which can then be used either 'within' the eventHandler or in the script it executes.
The variables are: [unit, weapon, muzzle, firing mode, ammo]

Letting the eventHandler execute the script only when a certain weapon is used. In this case the weapon is Put

Code: [Select]

this addEventHandler ["fired",{if (_this select 1 == "Put") then {(nearestObject [_this select 0,_this select 4]) execVM "detonated.sqf"}}]
But if the player has access to mines, putting a mine would also execute the script as it is 'fired' by the Put weapon.
Letting the EventHandler execute the script only when a certain ammo is used, in this case the ammo is PipeBomb

Code: [Select]

this addEventHandler ["fired",{if (_this select 4 == "PipeBomb") then {(nearestObject [_this select 0,_this select 4]) execVM "detonated.sqf"}}]
3.
Look at the code more carefully.

In this particular case the usage of the command nearestObject returns the nearest object to the player, of PipeBomb type.
The two parameters there are from the array the eventHandler creates, _this select 0 is the unit and _this select 4 is the ammo used. The ammo used is named the same as the object class so it can be used to detect the satchel.

When I use (nearestObject [_this select 0,_this select 4]) what is passed to the script is pipebomb object which is then referred to in the script with _this.
So, actually when the nearestObject search has returned the object, the script is executed and basicly would look something like this if done 'manually'

Code: [Select]

pipebombobject execVM "detonated.sqf"
4.
Yes.
waitUntil is a boolean check, it's basicly the same as @ in sqs but it allows much more complex checks, you can have like pages of code in it.. And afaik it doesn't loop as fast as the @ check..
What it does it waits until a condition becomes true before it let's the script go any further.

So in this case the waitUntil waits until the pipebomb object becomes null before letting the script run any further.
And of course the object becomes null when it disappears, which happens when the satchel is detonated.

[bardosy]

Thanks h-, it was a nice and clear explain!