Openapoc: Viele zerstörte Kacheln im Stadtbild scheinen das Spiel in Ultra-Speed ​​zu verlangsamen

Feindliche Fahrzeuge wie Baufahrzeuge auf einer Mission scheinen auch Auswirkungen zu haben

Ein weiteres Beispiel von später im Savegame
save_SuperHuman 1.zip

Fahrzeuge scheinen auch stecken zu bleiben

Das festgefahrene Fahrzeug gefunden
Es steht über dem Mega-Flyer, speichern Sie es im Anhang
save_SuperHuman 1.zip

Ich debugge das festgefahrene Fahrzeug (Baufahrzeug 31).
Seine Missionen zum Zeitpunkt des Savegames sind:

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

Das Ziel (43,63,2) wird jedoch durch adjustTargetToClosestFlying in (43,63,7) umgeschrieben.
Danach oszilliert das Fahrzeug bei jedem Aufruf von setPathTo zwischen dem Versuch, zu (43, 63, 7) und einem zufälligen Ziel in der Nähe zu gelangen:

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)
...

Danke, dass du dir das

Wenn du eine Lösung findest, wäre ich sehr dankbar

Idealerweise möchten wir, dass das Fahrzeug erkennt, dass es in einer Schleife steckt, und eine neue Mission zu einem geeigneten, klaren Endziel generiert, da ich vermute, dass die fehlende Überprüfung des zufälligen Ziels als geeignetes Ziel die Schleife erzwingt

Ich stelle fest, dass Fahrzeuge, die in diesen Schleifen stecken bleiben, sich oft in Landing Tube Tiles oder Mega-Flyers Factories befinden

Ich bin mir nicht sicher, warum insbesondere die Mega-Flyer-Fabriken ein solches Problem verursachen, es sei denn, es gibt irgendwo einen schlechten Kacheltyp???

Sieht so aus, als ob dies die "Ausweichlogik" ist, die ausgelöst werden soll, wenn das Ziel von einem anderen Fahrzeug besetzt wird. Das Ziel wird vorübergehend in ein leeres Feld in der Nähe geändert. Sobald das Fahrzeug dieses Plättchen erreicht, versucht es erneut, zum ursprünglichen Ziel zu fahren.

Aber in diesem Fall ist CV31 das Fahrzeug, das das Ausweichen verursacht, dh es denkt, dass es mit sich selbst kollidieren würde. Code
Zusätzliche Protokolle, die ich hinzugefügt habe, die dies zeigen:

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.

Es klingt nach einer guten Idee, eine zusätzliche Prüfung hinzuzufügen, um sicherzustellen, dass Fahrzeuge nicht versuchen, sich selbst auszuweichen.
Das heißt, ich bin mir nicht sicher, warum das Ausweichen das nicht löst.

Einige weitere Debug-Hinweise:

• Die Missionen des Fahrzeugs sind:

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 ist nicht erreichbar - es wird von einem MEGAFLYER_TWO-Gebäude belegt.
• Flyer suchen nach der am nächsten erreichbaren Kachel, indem sie nach oben gehen. In diesem Fall sind es 43,63,7.
  
• pickNearest ist für diese GotoLocation-Mission falsch - sie wird also nicht abgeschlossen, bis das Fahrzeug genau die Stelle erreicht hat. Was unmöglich ist.
• Da darauf eine RecoverVehicle-Mission folgt, landete wahrscheinlich ein abgestürztes Fahrzeug bei 43,63,2 und dieser Transport wurde beauftragt, es zu bergen. Ich werde ein früheres Savegame ausprobieren, um zu sehen, wie diese Missionen erstellt wurden.
• Das Hinzufügen des Checks, den ich im vorherigen Kommentar erwähnt habe (berücksichtigen Sie nicht, wenn Sie nach Fahrzeugen suchen, die es zu vermeiden gilt), verhindert, dass das Fahrzeug in eine Schleife gerät, aber jetzt bleibt es bei 43,63,7 hängen.

Betrachten Sie dieses frühere Savegame:

Ich gehe davon aus, dass es mit zerstörten Kacheln zusammenhängt, da es nur aufzutreten scheint, wenn einige Gebäude durch Überfälle zerstört wurden

Cityscape scheint unglaublich langsam zu sein, wenn es auf Ultra-Speed ​​gestellt wird
Bis zur Unspielbarkeit

Speichern finden Sie im Anhang

SuperHuman_Slow.zip

Blazer Turbo Bike 49 (in der Nähe des zerstörten Hades Blocks) versucht zu (86,78,2) zu gelangen, einem zerstörten Straßenteil. Aber ähnlich wie bei dem festgefahrenen Baufahrzeug sehe ich, dass setPathTo bei diesem Fahrzeug bei jedem Tick aufgerufen wird, was wahrscheinlich zur Verlangsamung beiträgt.

Hier ist ein PR für einen Fix (nur manuell überprüft):
https://github.com/OpenApoc/OpenApoc/pull/563