LaserTarget self-destructing after 9.2 sec? it

[ManDay 0]

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

pos_tar =[ pos_tar select 0,pos_tar select 1,2 ];

emp_tar = createVehicle[ "LaserTargetW",pos_tar,[],0,"NONE" ];

_int_i = 0;

while{ format[ "%1",emp_tar ] != format[ "%1",objNull ] }do

{

hint format[ "%1",emp_tar ];

sleep 0.1;

_int_i = _int_i + 1

};

hint format[ "Deleted after %1 seconds.",0.1*_int_i ];

A spawned LaserTarget will turn into ObjNull after 9.2 Seconds. This issue evokes some serious problems. If you locked on onto a spawned LaserTarget you will certainly loose the lock after 9.2 Seconds because even spawning another one will not keep the lock.

So what is the issue there? How does the LaserMarker work then - how does the LaserMarker retain the target "alive". And why does it disappear when beeing spawned?

[maddogx 13]

I'm guessing the laser target is usually "kept alive" by the laser designator and automatically destroys itself after 9,2 seconds to make sure it doesn't stay permanently due to lag or something, once the designator has disengaged.

You could rewrite your script to recreate the LaserTarget at its old position when it is destroyed.

[ManDay 0]

I'm guessing the laser target is usually "kept alive" by the laser designator and automatically destroys itself after 9,2 seconds to make sure it doesn't stay permanently due to lag or something, once the designator has disengaged.

You could rewrite your script to recreate the LaserTarget at its old position when it is destroyed.

Well, "kept alive" is a pretty diffuse expression. There must be some reason in the .bin files why it's getting destroyed. The reason you stated may be right but the way it works is still unclear.

As I said recreating the target will not keep the lock on it because the newly created substituion is not getting locked on when you locked on the old one.

[maddogx 13]

I'm guessing the laser target is usually "kept alive" by the laser designator and automatically destroys itself after 9,2 seconds to make sure it doesn't stay permanently due to lag or something, once the designator has disengaged.

You could rewrite your script to recreate the LaserTarget at its old position when it is destroyed.

Well, "kept alive" is a pretty diffuse expression. There must be some reason in the .bin files why it's getting destroyed. The reason you stated may be right but the way it works is still unclear.

As I said recreating the target will not keep the lock on it because the newly created substituion is not getting locked on when you locked on the old one.

It doesn't necessarily have to be in the bin files. Laser target behaviour might be hardcoded, as it is quite unique.

Apart from that, why are you always wanting to create such things with createVehicle? First missiles, now laser targets... I mean is this absolutely necessary for the mission you are making? You must have realized by now that those objects behave differently when created with createVehicle.

You might want to try using them the way they were intended.

[Maddmatt 1]

There are some invisible target addons that should include a laser target which you can even place in the editor and it wont disappear.

Give these a try.

[ColonelSandersLite 0]

If you want to go addon free, try having a friendly soldier designate the target, and use setcaptive on him so that the enemy doesn't attack him.

[UNN 0]

You could always setpos it above ground in a loop. Looks like Laser Targets are subject to gravity.... Damn you Newton!

[ManDay 0]

You could always setpos it above ground in a loop. Looks like Laser Targets are subject to gravity.... Damn you Newton!

No, it is not. I displayed the position in the loop and its kept 2 meters above surface.

Yes, I wanna go addon free.

No, I dont want/cannot use a soldier to target it since it should be just a target "somewhere" not on an enemy tank.

No - this has no special purpose - I am just curious

[UNN 0]

Quote[/b] ]No, it is not. I displayed the position in the loop and its kept 2 meters above surface.

Well not sure what scripts you are using, but this script works fine:

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

_Pos=GetPos _Object;

_Pos Set [2,5];

_T="LaserTargetW" CreateVehicle [0,0,0];

WaitUntil

       {

       Player SideChat Format ["Obj %1 %2",_T,Time];

       _T SetPos _Pos;

       False

       };

This way you can keep the Laser Target going indefinetly.

[ManDay 0]

Well not sure what scripts you are using [...]

The one I posted in the first post!? Just replace the parameter in the format[] with position emp_tar.

I'll try yours anyway. I imploringly hope it works. Would be great. Thanks a lot for your effort

[UNN 0]

Quote[/b] ]The one I posted in the first post!?

Sorry I missed that bit.

But looks like the delay of 0.1 seconds in the loop, is enough to let the object drop.

You should realy write your condition like this:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">while {!(IsNull emp_tar)} do

{

hint format[ "%1",emp_tar ];

sleep 0.001;

_int_i = _int_i + 1

};

BTW I thought the While loop was no longer restricted to 10,000 cycles? Recently, I tried it as part of an init.sqf script, it still had the same limit.

[5133p39 16]

BTW I thought the While loop was no longer restricted to 10,000 cycles? Recently, I tried it as part of an init.sqf script, it still had the same limit.

Well, in my ArmA v1.08 there is no limit for number of the while loop interations.

Either you are using some older version of ArmA where the limit existed, or your script is flawed.

[UNN 0]

Quote[/b] ]or your script is flawed.

I doubt the script is flawed. Probably just my observation at that point in time. Hence the use of a ?

[5133p39 16]

Quote[/b] ]or your script is flawed.

I doubt the script is flawed. Probably just my observation at that point in time. Hence the use of a ? :)

i see, sorry. Anyway, the important thing is the limit is really gone :)