Gibsonm Posted January 16, 2022 Author Share Posted January 16, 2022 (edited) 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 January 16, 2022 by Gibsonm 0 Quote Link to comment Share on other sites More sharing options...
Gibsonm Posted January 16, 2022 Author Share Posted January 16, 2022 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? 0 Quote Link to comment Share on other sites More sharing options...
Members Ssnake Posted January 16, 2022 Members Share Posted January 16, 2022 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. 0 Quote Link to comment Share on other sites More sharing options...
Gibsonm Posted January 17, 2022 Author Share Posted January 17, 2022 (edited) 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 January 17, 2022 by Gibsonm 0 Quote Link to comment Share on other sites More sharing options...
Gibsonm Posted January 17, 2022 Author Share Posted January 17, 2022 (edited) AAR for 2nd run: https://u.pcloud.link/publink/show?code=XZDTYGXZl0EYzC7CpPXRBLISfUvTYyDgBKTX New map of trouble spots: 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 January 17, 2022 by Gibsonm 0 Quote Link to comment Share on other sites More sharing options...
Members Ssnake Posted January 17, 2022 Members Share Posted January 17, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
Gibsonm Posted January 17, 2022 Author Share Posted January 17, 2022 (edited) 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 January 17, 2022 by Gibsonm 0 Quote Link to comment Share on other sites More sharing options...
Gibsonm Posted January 17, 2022 Author Share Posted January 17, 2022 (edited) Run 2 had some non bridge related issues: Spot 1: Disregard - I left a condition out, there were never going to proceed. Spot 2 (admittedly we are near a bridge - they were heading right to left): Edited January 17, 2022 by Gibsonm 0 Quote Link to comment Share on other sites More sharing options...
Members Ssnake Posted January 18, 2022 Members Share Posted January 18, 2022 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... 0 Quote Link to comment Share on other sites More sharing options...
Gibsonm Posted January 18, 2022 Author Share Posted January 18, 2022 (edited) 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... 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 January 18, 2022 by Gibsonm 0 Quote Link to comment Share on other sites More sharing options...
Members Ssnake Posted January 18, 2022 Members Share Posted January 18, 2022 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. 1 Quote Link to comment Share on other sites More sharing options...
Gibsonm Posted January 18, 2022 Author Share Posted January 18, 2022 Iteration 3 underway. Expect feedback in about 5 hours. 0 Quote Link to comment Share on other sites More sharing options...
Members Ssnake Posted January 18, 2022 Members Share Posted January 18, 2022 Well, I'm awake... 0 Quote Link to comment Share on other sites More sharing options...
Gibsonm Posted January 18, 2022 Author Share Posted January 18, 2022 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 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, ...?) 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? 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. 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, ...?) 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). 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. 0 Quote Link to comment Share on other sites More sharing options...
Members Ssnake Posted January 18, 2022 Members Share Posted January 18, 2022 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. 0 Quote Link to comment Share on other sites More sharing options...
Members Ssnake Posted January 18, 2022 Members Share Posted January 18, 2022 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. 0 Quote Link to comment Share on other sites More sharing options...
Members Ssnake Posted January 18, 2022 Members Share Posted January 18, 2022 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). 0 Quote Link to comment Share on other sites More sharing options...
Members Ssnake Posted January 18, 2022 Members Share Posted January 18, 2022 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. 0 Quote Link to comment Share on other sites More sharing options...
Gibsonm Posted January 18, 2022 Author Share Posted January 18, 2022 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). 0 Quote Link to comment Share on other sites More sharing options...
Gibsonm Posted January 18, 2022 Author Share Posted January 18, 2022 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.). 0 Quote Link to comment Share on other sites More sharing options...
Gibsonm Posted January 18, 2022 Author Share Posted January 18, 2022 (edited) 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 January 18, 2022 by Gibsonm 0 Quote Link to comment Share on other sites More sharing options...
Gibsonm Posted January 18, 2022 Author Share Posted January 18, 2022 (edited) 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: 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: Edited January 18, 2022 by Gibsonm 0 Quote Link to comment Share on other sites More sharing options...
Members Ssnake Posted January 18, 2022 Members Share Posted January 18, 2022 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. 0 Quote Link to comment Share on other sites More sharing options...
Members Ssnake Posted January 18, 2022 Members Share Posted January 18, 2022 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. 0 Quote Link to comment Share on other sites More sharing options...
Members Ssnake Posted January 18, 2022 Members Share Posted January 18, 2022 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. 0 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.