Destroyed targets that are not destroyed

[theavonlady 2]

(_this select 1) is probably a null object.

"Error type bool" often occurs when an object doesn't exist (scalar bool array... blah blah)

Well............................. now what?

EDIT: Why is it null?

EDIT: From Drukov's Event Handler's documentation:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

"engine" (to vehicles only) :

_this select 0 : who's in charge of the vehicle;

_this select 1 : boolean, true if engine is on, false otherwise.

[redface 1]

If you put empty vehicles instead of WEST/EAST tanks on the map, and then moveincargo some troops, the engine (and lights!) are switched on by default.

It's a bug, but maybe it could come in handy here for you.

[theavonlady 2]

If you put empty vehicles instead of WEST/EAST tanks on the map, and then moveincargo some troops, the engine (and lights!) are switched on by default.

That would really involve a lot of hard work, redoing several mission.

Quote[/b] ]It's a bug, but maybe it could come in handy here for you.

What's a bug? The null condition?

Bleh! Enough with the non-working EH.

But I think I've found a super simple solution.

All of these units have two last waypoints: first a SEEK AND DESTROY and then a HOLD waypoint.

Take my sample mission above and change the HOLD wapoint to a SEEK AND DESTROY one. Ta-da!

Now, if that really works, are there any negative implications in mission play when changing a last waypoint from HOLD to SEEK & DESTROY?

If not, life couldn't be simpler.

EDIT: Just tested this out on the mission. Changing vehicle's last waypoints from HOLD to SEEK AND DESTROY seems to do the job with no adverse effects.

But I would suggest that BIS change vehicle behavior at a HOLD waypoint to keep the engines humming. It's not as if BIS is a signatore to the Kyoto Agreement.

[crashdome 3]

Re: null object

My fault again, I wasn't paying attention...

The "Error type bool" is frequent with undefined (null) variables in IF...THEN... statements but if the (_this select 1) is actually a boolean variable... well.... then there-in lies your problem!!

You can't equate a boolean to an integer in OFP. IF (true == 1)... is not a valid condition. You should have just used:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">IF (_this select 1) THEN...

[theavonlady 2]

You should have just used:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">IF (_this select 1) THEN...

Since I'm checking for engine being off, shouldn't it be:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">IF NOT(_this select 1) THEN...

EDIT: fooey! With or without NOT, it doesn't work!

[hardrock 1]

we had that already, avon

if .. then must be lowercase

Edit: Didn't it work with addEventHandler?

[theavonlady 2]

we had that already, avon

if .. then must be lowercase

Edit: Didn't it work with addEventHandler?

Nothing works! Try for yourself:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">version=11;

class Mission

{

randomSeed=12114947;

class Intel

{

};

class Groups

{

items=2;

class Item0

{

side="WEST";

class Vehicles

{

items=1;

class Item0

{

position[]={9206.400391,1.793269,3217.430176};

azimut=50.000000;

special="FLY";

id=0;

side="WEST";

vehicle="A10";

player="PLAYER COMMANDER";

leader=1;

skill=1.000000;

};

};

class Waypoints

{

items=1;

class Item0

{

position[]={11546.703125,8.380176,4560.518066};

type="HOLD";

description="Target BMP";

class Effects

{

};

showWP="NEVER";

};

};

};

class Item1

{

side="EAST";

class Vehicles

{

items=1;

class Item0

{

position[]={11546.702148,8.380189,4560.517578};

id=1;

side="EAST";

vehicle="BMP";

leader=1;

skill=0.600000;

text="bmp1";

init="this addEventHandler [""ENGINE"",{if not(_this select 1) then {(_this select 0) action [""ENGINE ON""]}}]";

};

};

};

};

class Sensors

{

items=1;

class Item0

{

position[]={9847.040039,29.834999,3674.069824};

a=0.000000;

b=0.000000;

timeoutMin=10.000000;

timeoutMid=10.000000;

timeoutMax=10.000000;

type="END1";

age="UNKNOWN";

expCond="not(canmove bmp1)";

expActiv="hint ""Mission completed""; forceEnd";

class Effects

{

};

};

};

};

class Intro

{

randomSeed=13170179;

class Intel

{

};

};

class OutroWin

{

randomSeed=4969987;

class Intel

{

};

};

class OutroLoose

{

randomSeed=10701315;

class Intel

{

};

};

[sanctuary 19]

A very simple workaround solution, to prevent the vehicle to stop its engine (and so to turn to WHITE in the radar) would be to not allow the vehicle to stop.

Instead of making the final waypoint of that vehicle a HOLD or a SEEK and DESTROY one , make it a MOVE waypoint.

Then add another MOVE waypoint , not very far to it (so the vehicle will stay in the area you need) and finally make a CYCLE waypoint next to the previous MOVE one.

This way the vehicle will make , until destroyed, some small movements forever and will never turn off the engines.

2 more waypoints, yes, but WHITE in the radar , no

[theavonlady 2]

A very simple workaround solution, to prevent the vehicle to stop its engine (and so to turn to WHITE in the radar) would be to not allow the vehicle to stop.

Instead of making the final waypoint of that vehicle a HOLD or a SEEK and DESTROY one , make it a MOVE waypoint.

Then add another MOVE waypoint , not very far to it (so the vehicle will stay in the area you need) and finally make a CYCLE waypoint next to the previous MOVE one.

This way the vehicle will make , until destroyed, some small movements forever and will never turn off the engines.

2 more waypoints, yes, but WHITE in the radar , no

Thanks. I had a misunderstanding about how CYCLE works. For the record:

Cycle:

This waypoint does not count as a waypoint, but it tells the unit it is issued to to repeat the waypoint the cycle waypoint is closest to. Use this to create patrols.

- Basic Waypoint Tutorial, by Jmaster33

My question to you is why do I need to added a MOVE waypoint? If the last waypoint is a SEEK&DESTROY, wouldn't adding a CYCLE wp next to it accomplish what I want, too?

EDIT: Tested this out. Final conclusion.

Placing a CYCLE waypoint next to the last MOVE, SEEK&DESTROY, etc. waypoint keeps the target active in the opposing side's target HUD.

I'm still curious as to why the "engine" Event Handler doesn't work. If anyone can get it working, post your finds here.

Thank you all for your help and efforts.

[sanctuary 19]

The extra MOVE waypoint was there to create a "patrol" pattern.

With only one MOVE waypoint and a CYCLE one, there is no patrol (move from a waypoint to another repeatedly) possible.

The patrol behaviour i suggested there was to force the vehicle to always move (even if only 2/3 m), forcing its engine ON to do so.

But i was not aware that adding a single CYCLE waypoint after a waypoint was enough to force the vehicle engine ON without having the vehicle to move.

Good finding, i will remember it for some situations.

[jakerod 254]

Im not scripter but couldn't you just use the domove command and have it set so that it will find a spot like 1 m infront of the tank and then it will move there and then have it go back 1m thus always keeping the engine on.

Once again don't know if that will work or not, not a scripter. also you may have already found the problem or a solution just suggesting this one.