using land.findPathOnRoad for path: some (not all) units don't move after getting move task

[cfrag]

I'm finding that I have a lot of issues with groups that I'm giving the task to follow a path on roads: they simply stand around and do nothing. Clicking on them in F10 Map reveals that seemingly all is well, but their speed is zero (task == "on march", speed == 0). This happens to some groups after giving them some more complex paths to navigate in Syria (Cyprus) and Persia, no problems of this kind in Caucasus. The path I hand them is the output from land.findPathOnRoad(), and I don't know why some groups simply stop (no destination flags, no dashed path marker in F10, task is "on march", speed is zero), while other happily navigate the path that was calculated for them (destination marker, dashed line, "on march", speed is 26mph). 

 

Is there perhaps a limit on the number of path points that I can hand off to the AI? I'm completely stumped what is causing this issue, or how I could diagnose what is amiss, and how I could get them to move again.

 

Has anyone seen a similar issue and if so, how did you resolve it?

 

Thank you for any pointers,

-ch

[toutenglisse]

44 minutes ago, cfrag said:

...

Has anyone seen a similar issue and if so, how did you resolve it?...

 

I've had a "similar" issue , and the root for me was a start point on road and a destination point on road that were unlinked. Sometimes obviously (example : 1 of the 2 points settled on a portion of isolated road) and sometimes obscurantly (2 points linked by road on map, but still unlinked, maybe a tiny little gap somewhere ? I don't know).

 

What I did to avoid static convoy is to run a routine to check a flag 2 seconds after tasking route to convoy. The flag is set true at the end of the route function if the function ran flawlessly (points linked). If function failed (points unlinked that make either land.findPathOnRoads or mist.goRoute failing) the flag stays false and the check routine run again a route task. It does it up to 5 times in a row, and after 5 tries if still false it's because the start point is too isolated to find a valid destination.
In this case I give option to find a new start point (new convoy).

[cfrag]

Thank you, @toutenglisse - that sound very interesting. How did you check that the points are linked (i.e. the routine ran flawlessly)? Can I check the path data that is returned by findPathOnRoad(), or did you come up with some other checks (e.g. the vehicle has actually started moving)? AFAIK, findPathOnRoads() always returns successfully, so I'd love to get a hint on how to proceed. I now have a regular check to see if the group is stopped (speed == 0) for longer than two minutes and then issue direct approach orders - but that approach seems very clumsy to me.

[Grimes]

It should be possible for findPathOnRoads to fail if no valid path is found. The same pathfinding is used in the editor if you place two on road waypoints. If you are spawning stuff randomly and giving random destinations it is easy enough to create a mark point at those coordinates and then load into the editor and manually check if such a path is possible. A valid result would be the points "snap" to the actual path and not being a straight line. For reference you see this a bunch where one way roads exist like on Marianas.

 

I'm honestly not sure if the AI can be overwhelmed with waypoints in their task. However depending on where it is at using all of the points returned via findPathOnRoads can be a bit excessive. Would have to double check but again it might be the exact same returns that the mission editor uses to "draw" the shape of the path. Which I'm not sure if any of you have noticed but it saves that to the miz file and especially long routes can contain several thousand points. This short 5km trek in the mountains has 393 points. Checking the distance between each point likely yields values as low as 5 meters. 

 

 

The AI should do just fine with a start point and destination. Though there would be nothing wrong with sub-dividing the points up, like if there were 500 points you use the points a 1, 100, 200, 300, 400, and 500 to define a route. 

 

 

[cfrag]

Thanks, @Grimes! I've implemented a campaign-style mission where you have to capture 'spawn points'. When owned, troops spawn there under AI control and they then proceed to the next non-owned spawn point on the map. When your side captures a spawn point, all troops that are currently under way to the now captured point will re-route automatically to the next un-owned spawn location. So yes, I need road routes from arbitrary locations. I've programmed this currently in a way that when the road route (in length) is much longer than direct, the AI will go direct off-road. Therefore I know that I always get back a road route from findPathOnRoad(), and that length is > 0. It's just that somehow the units don't move with some of these paths. It may be something silly, like having to switch to 'Off Road' for only a single segment. I do not check if all points returned from findPathOnRoad() are themselves on a road, so maybe that is all that's missing (i.e. selectively switching from on-road to off-road). 

 

I'm now testing a 'stop check' that when a group isn't moving (all unit's speed == 0) after some time it will be issued orders to halt, and then (10 seconds later) is ordered to move directly to the target location. I'm hoping that this will resolve the issue, but that's a work-around. I'll try and analyze the issue further to get a better understanding of what is happening. Next step would be to pre-process the vectors returned by findPathOnRoad if they are all on roads, and change the waypoint orders to 'off road' if the are not.

 

-ch

[toutenglisse]

7 hours ago, cfrag said:

... How did you check that the points are linked...

 

By testing zones where I saw issues with onroad moving groups.

 

I attached a little test track where you can see the function testing destinations in a zone where there are several isolated portions of road. 2 times destination is unvalid (a neutral watchtower is used to see the destination) and function is ran again, and third time destination is valid and group is moving. It just lasts a few seconds.

 

In this example unlinked roads are obvious. But I've found other roads that are linked on map, but still had issue (very rare). I've just tried with 1 place I remembered, but now it seems OK (it's the place in the picture from PG map. when dynamic group was placed on the left of yellow circle it would fail to find a linked destination, and when placed on the right it would be OK).

And the issue was only there for dynamic stuff. With group placed and asked to move on road with mission editor it was ok.

test-unlinked-roads.trk

[cfrag]

Initial tests indicate (I'm still trying to get to the bottom of this) that DCS becomes knocked off it's perch when multiple groups receive new road-based paths in a short time period, with 'On Road' settings. I noticed that all vehicles stop dead in their tracks when all groups receive new move orders almost at once (some 30 groups within 60 seconds) with 'On Road' is passed as action.

Now, if I use the path handed to me via findPathOnRoad, but set the action to "Off Road", there are fewer issues, or rather, it takes more groups to produce the same result. Generally, though, it seems that DCS doesn't like it if there are many (complex) paths being assigned to units, and having groups additionally follow the road (on road) swamps the AI in a way that it delays, forgets tasking groups or even crashes. 

 

So, one possible fault (at least at first blush) seems to be that many and complex paths as well as "On Road" orders can block the a group's processing for minutes before they starts moving again - if at all. When there are many groups that are simultaneously being issued on-road orders, DCS will freeze or crash.

 

After some more testing: there are definitely issues when issuing many orders: tasking 80 groups to move some 5 km directly (i.e. without following roads) spread over 30 seconds almost always produces a crash or freeze - in Syria and Persia. Caucasus seems to behave more benign, which may point to a memory issue. 

 

Oh - and thank you so much, @toutenglisse, I'll check it out asap! 

 

-ch

Edited July 22, 2021 by cfrag

[cfrag]

To follow up on my own posts: further experimentation now seems to implicate GUI issues (interactions when clicking on units in the F-10 map) to instabilities. I now ran a scenario (took some 100 minutes) with up to 102 managed groups (up to two ground units per group), and the scenario ran fine in Persia. It was able to re-path 78 groups at one time, but with no interaction on the f10 map (except looking at it). Groups had direct, non-road orders.