Openapoc: Lot's of destroyed tiles in cityscape appears to slow game to a halt in Ultra-Speed

Hostile vehicles such as construction vehicles on a mission also seems to impact

A further example from later in save game
save_SuperHuman 1.zip

Vehicles appear to be getting stuck too

Located the stuck vehicle
It's above the mega-flyer, save attached
save_SuperHuman 1.zip

I'm debugging the stuck vehicle (Construction Vehicle 31).
Its missions at the time of the savegame are:

W 7613175674 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): CLICKED VEHICLE Construction Vehicle 31 at {42.7708,63.5,7.5}
W 7613244067 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): Mission GotoLocation {43,63,2}
W 7613263414 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): Mission RecoverVehicle 
W 7613286861 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): Mission GotoBuilding BUILDING_WAREHOUSE_THREE

However destination (43,63,2) is rewritten to (43,63,7) by adjustTargetToClosestFlying.
After that point, the vehicle oscillates between trying to go to (43, 63, 7) and a random nearby target with each call to setPathTo:

After setPathTo: Vehicle [Construction Vehicle 31] path: (41,63,7) -> (41,63,7) -> (42,63,7) -> (43,63,7)
After setPathTo: Vehicle [Construction Vehicle 31] path: (43,63,7) -> (43,63,7) -> (42,64,6) -> (41,63,5) -> (41,62,4)
After setPathTo: Vehicle [Construction Vehicle 31] path: (41,62,4) -> (41,62,4) -> (41,62,5) -> (41,62,6) -> (42,63,7) -> (43,63,7)
After setPathTo: Vehicle [Construction Vehicle 31] path: (43,63,7) -> (43,63,7) -> (43,62,7) -> (42,61,6)
After setPathTo: Vehicle [Construction Vehicle 31] path: (42,61,6) -> (42,61,6) -> (43,62,7) -> (43,63,7)
After setPathTo: Vehicle [Construction Vehicle 31] path: (43,63,7) -> (43,63,7) -> (44,64,6) -> (45,65,5) -> (45,65,4)
...

Thanks for looking into this @ashenomo <3

If you can find a solution i'd be greatly appreciative

Ideally, we want the vehicle to recognise it's stuck in a loop and generate a new mission to a suitable, clear, end destination as i suspect it's the lack of a check on the random target being a suitable destination that forces the loop

I notice that when vehicles get stuck in these loops they are often in Landing Tube Tiles, or Mega-Flyers Factories

Not sure why the Mega-Flyer Factories in particular cause such issue, unless there is a bad tile type somewhere???

Looks like this is the "side-stepping" logic which is meant to trigger when the destination is occupied by another vehicle. The target is temporarily changed to a nearby empty tile. Once the vehicle gets to that tile, it tries again to go to the original target.

However in this case, somehow the vehicle causing the side-stepping is CV31, i.e. it thinks it's about to collide with itself. code
Additional logs I added showing this:

W 14531114914 void OpenApoc::VehicleMission::setPathTo(OpenApoc::GameState &, OpenApoc::Vehicle &, Vec3<int>, int, bool, bool):  ** setPathTo for [Construction Vehicle 31] to (43,63,2), maxIter:450, cV:Y, giveUp:N, currentPath n:0
W 14531141711 void OpenApoc::VehicleMission::setPathTo(OpenApoc::GameState &, OpenApoc::Vehicle &, Vec3<int>, int, bool, bool):  *** adjustTargetToClosestFlying: [Construction Vehicle 31] (43, 63, 2), piNe: N
W 14531234219 static bool OpenApoc::VehicleMission::adjustTargetToClosestFlying(OpenApoc::GameState &, OpenApoc::Vehicle &, Vec3<int> &, bool, bool, bool &): Target (43,63,7) contains vehicle [Construction Vehicle 31]. This will trigger a target adjustment.

Adding an additional check to ensure vehicles don't try to avoid themselves sounds like a good idea.
That said, I'm not sure why side-stepping doesn't resolve this..

Some more debug notes:

• Vehicle's missions are:

W 417133364405 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): Mission GotoLocation {43,63,2}
W 417133397242 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): Mission RecoverVehicle 
W 417133421554 bool OpenApoc::CityView::handleMouseDown(OpenApoc::Event *): Mission GotoBuilding BUILDING_WAREHOUSE_THREE

• 43,63,2 is unreachable - it's occupied by a MEGAFLYER_TWO building.
• Flyers look for the closest reachable tile by going up. In this case it's 43,63,7.
  
• pickNearest is false for this GotoLocation mission - so it won't be completed until the vehicle reaches the exact spot. Which is impossible.
• Given it's followed by a RecoverVehicle mission, probably a crashed vehicle ended up at 43,63,2 and this transport got assigned to recover it. I'll try an earlier savegame to see how these missions were created.
• Adding the check I mentioned in the previous comment (don't take self into account when looking for vehicles to avoid) prevents the vehicle from going into a loop, but now instead it just gets stuck at 43,63,7.

Looking at this earlier savegame:

Im assuming it's related to destroyed tiles, as it only seems to occur once a few buildings are downed by raids

Cityscape appears to be incredibly slow when placed on ultra-speed
To the point of being unplayable

Please find save attached

SuperHuman_Slow.zip

Blazer Turbo Bike 49 (near the destroyed Hades Block) is trying to get to (86,78,2), which is a destroyed road tile. But similarly to the stuck construction vehicle, I see setPathTo being called in every tick for this vehicle which probably contributes to the slowdown.

Here's a PR for a fix (only manually verified):
https://github.com/OpenApoc/OpenApoc/pull/563