Ground Vehicle doMove issue

[zapat 55]

Now I've been having this issue for a very long time now, but it is starting to annoy me again.

When I give a doMove order to a ground vehicle (the position is pre-checked and flatEmpty) like 70% of the time nothing happens.

My workaround is ( I move them via FSM) is a loop that checks every 4 seconds if the car moved already. If not, give order again.

After like the 3rd-4th order the drivers get their lazy ass and begin their journey (yea, into the woods, but thats another story). Sometimes they stop during their trip, ad the whole things starts from the beginning.

What may cause this behaviour? Why do they start eventually? Why do they need the same doMove orders 3,4,5,... times? Is it a path finding issue?

Has any of you guys found a solution to this? Or is mine working so I should be satisfied? Isn't the engine recalculating path every time I give a doMove order?

( I prefer doMoves over waypoints, I create them dynamically, and I found handling WPS a pain in the ass.)

Thanks for reading

[twirly 11]

Just did a little test and the vehicle (wveh1) always moves to it's destination on the first "doMove".... no more required.

(driver wveh1) doMove getmarkerpos "mkr_moveto";

The vehicle moves to the marker....no worries.

EDIT: What island is that on?

Edited October 4, 2012 by twirly

[Tom_48_97 523]

Can you put your FSM (at least, the part where DoMove is called)?

Isn't the engine recalculating path every time I give a doMove order?

I think yes since every new "DoMove" is a new instruction, including the pathfinding

[twirly 11]

What doesn't work now and used to work is this.....

_driver = driver wveh2;
_driver doMove getmarkerpos "mkr_moveto";
waituntil {unitready _driver};

hint "I'm here";

I get the hint as soon as he gets the command... that's not correct! So maybe something is screwy with the doMove command.

[Tom_48_97 523]

You may change your condition for a waitUntil {_driver distance getmarkerpos "mkr_moveto" < 10} for example. Have you tried move instead of DoMove?

[twirly 11]

You may change your condition for a waitUntil {_driver distance getmarkerpos "mkr_moveto" < 10} for example. Have you tried move instead of DoMove?

Yep that will work... and it does. But I'm pretty sure what I wrote used to work. I've used it lots of times before and got the results I wanted.

[zapat 55]

twirly: it's on Chernarus

I use the following simple line:

units _grp doMove _wp;

_wp is a position that exists and is always on a good spot, I've checked that.

Anyhow, it sometimes works, sometimes not for the first time. But if nobody has seen such... I may create a repro mission for that.

And yes twirly, I've found the same recently about unitready. But I use a simple distancecheck as well, since unitready has always been a bit unreliable for me.

---------- Post added at 04:12 PM ---------- Previous post was at 02:47 PM ----------

Ok, guys, I know this is a good question, and there is something I am not aware!

Here are my findings:

-when the vehicle doesn't react it is not a miracle.

the driver's expectedDestination is: [[0,0,0], donotplan, false]

the driver's currentCommand is: move

So the driver didn't get the target position as destination only the move order!

-After giving the exact same (without touching any variable) "units _grp doMove _wp;" orders for several times, the expected destination is filled correctly: [ [5500,8850,0], vehicleplanned,false]

and of course vehicle starts, since the driver now has a valid destination.

The problem is: once the doMove is issued, and the destination is not filled, it won't be. Unless another doMove is issued.

So how does this really work? Why to wait like 5-10 seconds (until a doMove finally fills expectedDestination)?

What causes the lag? I would bet it is route planning lag (maybe not enough calculating power) What should I do to avoid destination not filling correctly?

Edited October 5, 2012 by zapat

[twirly 11]

I put together this little test and found that the vehicle will always move unless I give it a path into an area surrounded by forest.... or somewhere with no access, which is how you would expect it to work I guess.

It does take a few seconds for the path calculation depending on where the point is... and then the vehicle will either move or it won't.

But every time I give the destination as somewhere with some kind of access... it seems to work just fine.

Also found this command that I never knew about....

moveToCompleted.

Works just fine with the moveTo command.

EDIT: I should have added that in the test mission the vehicle moves to wherever you place the red circular marker.

[pcc 14]

I'm experiencing this problem too in warfare.  It uses move command but still the same symptoms described in this thread.

At first I thought it was caused by fast travel, but AI driver still get stuck with it disabled.