Jump to content

4.268 Routes for vehicles - getting them to stick to the roads.


Gibsonm

Recommended Posts

4 hours ago, Abraxas said:

Therefore you should always take the right-hand one in the direction of travel when using the bridges. This also applies when delaying!

 

Hi,

 

Yes I've driven in Europe (albeit initially in a Scimitar and later in Taxis / Hire Cars). :)

 

The Soviets are travelling South, so they are indeed on the right / Correct for Europe side (refer the last two screenshots above) my concern is they still appear to miss/drive off the bridge (I recommend you watch the videos if possible).

 

Thanks very much for the map, if it weren't for all your hard work I would have given up on it already and stuck with an older, less detailed product. Part of my aim for this is to settle an internal concern that I have that extra detail results in maps that the AI has issues with. Part of me loves the detail, part of me thinks detail = clutter = troubles for the AI.

 

Edited by Gibsonm
Link to comment
Share on other sites

5 hours ago, Ssnake said:

I'm also in the "clean up" camp but to be perfectly honest, I really can't say with certainty if this makes a difference other than looking cleaner to the human eye.

 

Tonight when I get home It document the last two spots (4 and 5) for completeness.

 

Then perhaps I should make a second version with the March routes left alone (I'll initially only do these 7 trouble spots - no doubt the AI will then take different routes :) ) and see what happens?

 

Link to comment
Share on other sites

  • Members
31 minutes ago, Gibsonm said:

Part of my aim for this is to settle an internal concern that I have that extra detail results in maps that the AI has issues with. Part of me loves the detail, part of me thinks detail = clutter = troubles for the AI.

That concern isn't unfounded. But it's probably solvable, if we can at least address the most frequently observed issues. And if we can't solve it in version 4, then maybe we need different approaches to pathfinding in version 5. Either way, we can learn from it, and I'm determined to make high-detail maps work. Otherwise the whole new terrain engine effort would have to be chalked off as a complete waste.

Link to comment
Share on other sites

Almost finished the testing (earlier post just needs link to video - currently uploading approx 10 hours to go).

 

Forward work plan:

 

1. Bring the start / end waypoints further away from the bridge - just so that anything doing this 360 Degree "Crazy Ivan" doesn't get fouled up. I still have no idea as to why they are doing this.

 

2. At Points 1, 2 and 3 I'll redo the routes but not clean them up (retain the dogleg to the "wrong side of the bridge") and see if they stay on the right/correct side.

 

3.  At Points 4, 5, 6 and 7 I'll replace the March route with a Scout route "locked" to the road.

 

I'll then run it again and see how we go.

 

Edited by Gibsonm
Link to comment
Share on other sites

AAR for 2nd run: https://u.pcloud.link/publink/show?code=XZDTYGXZl0EYzC7CpPXRBLISfUvTYyDgBKTX

 

New map of trouble spots:

 

1369263153_2ndrunthrough.thumb.jpg.d4e5919424c8fe3db4bec6f598237d71.jpg

 

Yet to check but "2", "4", "5" "6" and "7" look similar.

 

"8" is incorrect - its off the map and the road stopped.

 

Remaining video still uploading (3+ hours to go). Will include that link and start to look at these points in the morning.

 

I am concerned that a fresh run has generated new issues on a route that was OK previously (site 3). Unsure if "1" is on a route used last time.

 

Edited by Gibsonm
Link to comment
Share on other sites

6 hours ago, Ssnake said:

Bug 9802 was just fixed, which covers the problem that waypoints in or in the vicinity of highway bridge #5 can sometimes not be reached by wheeled vehicles. It's a start, I guess.

 

Prior to addressing that, in terms of completeness I've added the longish video that covers points 4 and 5 in the first run. I've also added the AAR for the 2nd run to the respective posts above.

 

Turning now to Bug 9802, what are the implications?

 

a. Wait for Ver 4.xxx which includes the resolution to 9802 before returning to this map/scenario?

 

b. Replace that type of bridge with a different one (if 9802 is specifically related to one type of bridge)?

 

c. Something else?

 

I'll pause until I receive an update / advice.

 

Edited by Gibsonm
Link to comment
Share on other sites

  • Members
3 hours ago, Gibsonm said:

Turning now to Bug 9802, what are the implications?

When you have a road with this specific bridge, you'll notice how the route jumps to the middle of the four-lane bridge (where no lane is...). I think it's a good idea to place a waypoint just before the bridge, one after, and use neither navmesh nor "stick to road" plotting, but simply connect the waypoints with a straight March route.

 

Maybe it's sufficient to delete those errant vertices in the middle - but whenever you update the route they'll come back and need to be slain again.

 

Of course, these workarounds will become moot in a few months from now, but until then... :o

Link to comment
Share on other sites

3 hours ago, Ssnake said:

When you have a road with this specific bridge, you'll notice how the route jumps to the middle of the four-lane bridge (where no lane is...). I think it's a good idea to place a waypoint just before the bridge, one after, and use neither navmesh nor "stick to road" plotting, but simply connect the waypoints with a straight March route.

 

Maybe it's sufficient to delete those errant vertices in the middle - but whenever you update the route they'll come back and need to be slain again.

 

Of course, these workarounds will become moot in a few months from now, but until then... :o

 

OK I'll work up Ver 3 with this direct (no "stick to road", no pathfinding, no navmesh) option.

 

I'm hoping that "in a few months" when it becomes moot, I don't need to revisit those bridges and put things back again?

 

Edited by Gibsonm
Link to comment
Share on other sites

  • Members

Driving in a straight line should always work.

 

The development goal is to make "Shift+Click routes" reliable enbough that this level of fine tuning simply won't be needed in the future. I cannot foresee a deliberate change that would break this recommended workaround. I just want to see such need for micromanagement be made obsolete. 

Link to comment
Share on other sites

1 hour ago, Ssnake said:

Well, I'm awake...

 

Iteration 3 - Fresh off the press.

 

4 units stopped along A7 autobahn, 10 made it all the way. Not all units followed the same route (some joined the A7 further down its route).

 

Link to AAR file: https://u.pcloud.link/publink/show?code=XZV5hGXZiJ6arVS1jmHoBT95HtbaUhj1augV

 

701745726_Challengesrun3.thumb.png.3de79ebc0c148787a2f63a3a7bd51f40.png

 

Location 1: 2 x BRDM (014 and 016) arrive at waypoint at almost same time, then a M/cylce arrives. 016 moves off the road to the right. 014 remains on road, the M/cycle moves onto the other carriageway.. When delay expires, 014 proceeds but 016 fails to regain the road and the M/cycle does a lap of the bridge before proceeding. (waypoint too close to bridge, need to limit to one unit at a waypoint at a time, ...?)

 

1527747856_1Map.png.6edba741a8e28f5ef5e079217b8589b2.png

 

1218806254_13Dworld.thumb.png.05a2afc5c206abb22b2af1a89ceb76f4.png

 

 

Location 2: Similar to "1".

 

Note: As the terrain was generating I did notice (fleetingly) what looked like the road under the bridge which was then covered by the green. Unsure if the road stops either side of the bridge and is then joined to the bridge or if the road dips down and is covered by the bridge and the terrain/vegetation?

 

371992102_2Map.thumb.png.6a82be291df69a1024b29d89d7e9abb8.png

 

1997334402_23Dworld.thumb.png.bbb28ebdb0b07dce11959f62ed218680.png

 

Location 3: Similar to "1" and "2" but this time a M/Cycle so the chances of returning to the road are even less likely.

 

1377759070_3Map.thumb.png.cd0fb5b28c4e32eac5810ce127779593.png

 

593218603_43Dworld.thumb.png.3ee774304e980de42f0f2b35620a1e05.png

 

Location 4: Similar to "1", "2" and "3". Two BRDM (011 and 015) arrive at waypoint at almost same time. 011 moves off the road to the right. 015 remains on road. When delay expires, both proceed but 011 fails to regain the road (waypoint too close to bridge, need to limit to one unit at a waypoint at a time, ...?)

 

741626501_4Map.thumb.png.345e5c4c730ebc57a6ff04cdec28e8b6.png

 

1902184408_43Dworld.thumb.png.abbd9bc3f2d9d45482c9e947b3dc8864.png

 

Location 5: Perhaps a pathing issue at the waypoint (I've now removed the surplus micro waypoints/nodes). The first two units (a M/C and a BRDM) went through the ballet and kept on going. BRDM 3 went into the farmyard and got back out. BRDM 4 went into the farmyard and could not get out (kept bouncing around inside the walls).

 

1727422037_5Map.thumb.jpg.b43175ae2297e1ff29ad6de5456a0a62.jpg

 

1969819828_53Dworld.thumb.png.6046813f511792497e82f95b984f8ab6.png

 

Things to look at:

 

Now that the "delay" waypoint (required because we need to use March+embark if and retreat back if) is so close the bridge, do I need some sort of prelim waypoint(s) where traffic can build up so that only one unit at a time is at the near to the bridge waypoint, to avoid this displacement?

 

Or perhaps the simpler option is to just reduce the time of the delay (currently wait 2 mins to check conditions, then wait 1 min before proceeding - basically a 3 minute pause). I could try reducing that to one minute.

 

Link to comment
Share on other sites

  • Members
41 minutes ago, Gibsonm said:

need to limit to one unit at a waypoint at a time, ...?

At least, when you have the waypoint on a road with steep embankment and forest left and right, and if the vehicles arriving don't have pivot steer, using the same waypoint is not ideal since the units will be "fighting for the waypoint" by bumping into each other. Okay, maybe they shouldn't do that, fair point. But right now they do, which is unproblematic in an open field - but with all these extra factors in place, my recommendation would be to avoid it if possible. Be it that 014 absconds once that 016 has reached the previous waypoint, or a follow if delay be reduced by a few seconds.

Link to comment
Share on other sites

  • Members
23 minutes ago, Gibsonm said:

Location 2: Similar to "1".

 

Note: ... Unsure if the road stops either side of the bridge and is then joined to the bridge or if the road dips down and is covered by the bridge and the terrain/vegetation?

More likely, for reasons unknown the unit was diverted from the road, slipped down the embankment (should probably have resulted in a rollover, but that's another topic), then tried to recover by following the old directions, and got stuck on the embankment on the other side of the underpass.

But at the end of the day, my guess is as good as yours. We need to investigate this location with a unit test to see if there's something wrong with the bridge (doesn't look like it), or if, say, your frame rate dipped below 10 fps at some point (which is the lower limit of AI pathfinding; less than 10 fps, and it's no longer guaranteed to work). Or something else caused a deviation, and the attempt to recover from the deviation then caused an overcorrection that resulted in going down the embankment.

Once that a unit slides down the embankment, it's too stupid to realize that it can't get up there again.

 

So, maybe they shouldn't slide off the road, maybe they should realize that embankments are not suitable for driving (although some are...), but if you disabled pathfinding for that road per my recommendation (because, faulty bridge #5), improving AI pathfinding wouldn't help at all. You see why working on this is a bitch.

Link to comment
Share on other sites

  • Members
35 minutes ago, Gibsonm said:

Location 5: Perhaps a pathing issue at the waypoint ... BRDM 4 went into the farmyard and could not get out (kept bouncing around inside the walls).

Yeah, if the unit is not on a navmesh route, the walls are "invisible" to the obstacle avoidance so it can happen that a vehicle ends in a "local minimum" where it knows that it's not in the right place, but can't find a way out.

 

Since this is a sharp turn, you probably should end the route some 50m before the turn, then create a route with 5...10km/h absolute speed setting for the turn, and afterwards continue with a regular march/scout route. You should use Shift+Click only up to the turn, but a navmesh route for the turn so that if the unit overshoots into a walled compound it has a chance to find its way back to the road.

Link to comment
Share on other sites

1 hour ago, Ssnake said:

At least, when you have the waypoint on a road with steep embankment and forest left and right, and if the vehicles arriving don't have pivot steer, using the same waypoint is not ideal since the units will be "fighting for the waypoint" by bumping into each other. Okay, maybe they shouldn't do that, fair point. But right now they do, which is unproblematic in an open field - but with all these extra factors in place, my recommendation would be to avoid it if possible. Be it that 014 absconds once that 016 has reached the previous waypoint, or a follow if delay be reduced by a few seconds.

 

Understood but wont this become more of an issue as more and more maps try to use raised roads, embankments, etc.?

 

I'll try and adjust the timings to limit the congestion (iteration 4 I guess).

Link to comment
Share on other sites

1 hour ago, Ssnake said:

More likely, for reasons unknown the unit was diverted from the road, slipped down the embankment (should probably have resulted in a rollover, but that's another topic), then tried to recover by following the old directions, and got stuck on the embankment on the other side of the underpass.

But at the end of the day, my guess is as good as yours. We need to investigate this location with a unit test to see if there's something wrong with the bridge (doesn't look like it), or if, say, your frame rate dipped below 10 fps at some point (which is the lower limit of AI pathfinding; less than 10 fps, and it's no longer guaranteed to work). Or something else caused a deviation, and the attempt to recover from the deviation then caused an overcorrection that resulted in going down the embankment.

Once that a unit slides down the embankment, it's too stupid to realize that it can't get up there again.

 

So, maybe they shouldn't slide off the road, maybe they should realize that embankments are not suitable for driving (although some are...), but if you disabled pathfinding for that road per my recommendation (because, faulty bridge #5), improving AI pathfinding wouldn't help at all. You see why working on this is a bitch.

 

Ah OK, how do we do this test?

 

I don't sit in front of the machine for the entire 4+ hours per run, but I'm pretty confident the frame rate remained above 10 FPS (after all no shooting, no smoke, very low unit density, etc.).

Link to comment
Share on other sites

1 hour ago, Ssnake said:

Generally, for locations 1...4 I guess keeping a bit more distance to the bridge might help. Assigning "Stay" orders to the waypoint may also help (if the next route has embark conditions anyway, assigning a tactic to "NOT MOVE" won't hurt).

 

This seems a little contrary to the earlier advice to place the waypoint "I think it's a good idea to place a waypoint just before the bridge" earlier.

 

The embark if is only there because I can't use Scout.

 

The idea is they march across the bridge.

 

If not fired on they continue on.

 

If they are fired on (either direct or indirect) they withdraw to the side they came from.

 

Then after X mins they embark again.

 

Unfortunately that means they get to the bridge, and effectively execute the Embark if regardless of whether they are fired at or not, because the Retreat back if hasn't been evaluated yet.

 

Edited by Gibsonm
Link to comment
Share on other sites

8 hours ago, Ssnake said:

Yeah, if the unit is not on a navmesh route, the walls are "invisible" to the obstacle avoidance so it can happen that a vehicle ends in a "local minimum" where it knows that it's not in the right place, but can't find a way out.

 

Since this is a sharp turn, you probably should end the route some 50m before the turn, then create a route with 5...10km/h absolute speed setting for the turn, and afterwards continue with a regular march/scout route. You should use Shift+Click only up to the turn, but a navmesh route for the turn so that if the unit overshoots into a walled compound it has a chance to find its way back to the road.

 

But its not a sharp turn, the planned route is as per the purple line:

 

396297821_5Map-route.thumb.jpg.6e68b255aa0b7a7c5c40ef0f2f11fb5f.jpg

 

The issue I think was that there is a little spiral around the "237" which the first couple of units could cope with. the last BRDM though went through a farm gate and was trapped (the AAR was on FF, but the test was run in normal time):

 

Link to video: https://u.pcloud.link/publink/show?code=XZ2wgGXZNAaH5x3iACmt4zBA5VhLDplGzDf7

 

I've now removed those, but I think I'll also move the "237" slightly North so the waypoint is at the bend, instead of the Y junction. The route pre and post "237" are Scout, slow speed, column formation:

 

96644341_5NewRoute.thumb.png.e7ebee46881c6d19d8ede30e01f2ec81.png

 

 

Edited by Gibsonm
Link to comment
Share on other sites

  • Members
1 hour ago, Gibsonm said:

Understood but wont this become more of an issue as more and more maps try to use raised roads, embankments, etc.?

Probably, which is why I filed bug reports No. 10270 and 10268, also 10262 (which may have been a duplicate of 9802). Ideally we can reduce the number of cases where units slide fown embankments to begin with, and once that it has happened despite all our efforts, maybe switch to more graceful recovery methods.

Link to comment
Share on other sites

  • Members
1 hour ago, Gibsonm said:

Ah OK, how do we do this test?

I don't sit in front of the machine for the entire 4+ hours per run

Simple: We can't.

It's a plausible, but untestable theory for practical reasons.

 

That's why we're always asking for a "minimal repeat case" that involves just the location, the unit, and the route and ideally shows the same behavior in under a minute of runtime. If that can be done, we can run the scenario in the debogger, see which behavior routine results in aberrant behavior, then hopefully fix it. And then we go and test a gazillion other such test scenarios automatically to see if the recent change breaks anything. If it doesn't, we mark the Bugzilla entry as fixed, and it goes into the next beta version. Where humans will play with it, and file new reports. Once that nobody in Quality Assurance is seriously unhappy, we declare it as the next release version.

 

The magic of software development! If you close your eyes, you can sniff a trace amount of pixie dust in the air.

Link to comment
Share on other sites

  • Members
1 hour ago, Gibsonm said:

This seems a little contrary to the earlier advice to place the waypoint "I think it's a good idea to place a waypoint just before the bridge" earlier.

Yeah, but I didn't fully understand all the details back then.

1 hour ago, Gibsonm said:

Unfortunately that means they get to the bridge, and effectively execute the Embark if regardless of whether they are fired at or not, because the Retreat back if hasn't been evaluated yet.

For that purpose, add a "delay before checking" (top right corner of the embark, if... dialog). So they wait a few seconds to see if they're being fired upon. If so, the retreat condition kicks in, otherwise they proceed.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...