Openapoc: Beaucoup de tuiles détruites dans le paysage urbain semblent ralentir le jeu dans Ultra-Speed

Les véhicules hostiles tels que les véhicules de construction en mission semblent également avoir un impact

Un autre exemple de plus tard dans la sauvegarde
save_SuperHuman 1.zip

Les véhicules semblent également être bloqués

Localisé le véhicule coincé
C'est au-dessus du méga-flyer, sauf attaché
save_SuperHuman 1.zip

Je débogue le véhicule bloqué (Véhicule de construction 31).
Ses missions au moment de la sauvegarde sont :

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

Cependant, la destination (43,63,2) est réécrite en (43,63,7) par AdjustTargetToClosestFlying.
Après ce point, le véhicule oscille entre essayer d'aller à (43, 63, 7) et une cible proche aléatoire à chaque appel à 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)
...

Merci d'avoir étudié ce

Si vous pouvez trouver une solution je serais très reconnaissant

Idéalement, nous voulons que le véhicule reconnaisse qu'il est coincé dans une boucle et génère une nouvelle mission vers une destination finale appropriée et claire, car je soupçonne que c'est l'absence de vérification sur la cible aléatoire étant une destination appropriée qui force la boucle

Je remarque que lorsque les véhicules sont bloqués dans ces boucles, ils sont souvent dans des tuiles de tubes d'atterrissage ou des usines de méga-flyers.

Vous ne savez pas pourquoi les usines Mega-Flyer en particulier causent un tel problème, à moins qu'il n'y ait un mauvais type de tuile quelque part ???

On dirait que c'est la logique de « pas de côté » qui est censée se déclencher lorsque la destination est occupée par un autre véhicule. La cible est temporairement changée en une tuile vide à proximité. Une fois que le véhicule atteint cette tuile, il essaie à nouveau d'aller vers la cible d'origine.

Cependant, dans ce cas, le véhicule provoquant le pas de côté est le CV31, c'est-à-dire qu'il pense qu'il est sur le point de se heurter à lui-même. code
Journaux supplémentaires que j'ai ajoutés montrant ceci :

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.

L'ajout d'un contrôle supplémentaire pour s'assurer que les véhicules n'essaient pas de s'éviter semble une bonne idée.
Cela dit, je ne sais pas pourquoi le fait de contourner ne résout pas ce problème.

Quelques notes de débogage supplémentaires :

• Les missions du véhicule sont :

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 est inaccessible - il est occupé par un immeuble MEGAFLYER_TWO.
• Les flyers recherchent la tuile accessible la plus proche en montant. Dans ce cas, c'est 43,63,7.
  
• pickNearest est faux pour cette mission GotoLocation - elle ne sera donc pas terminée tant que le véhicule n'aura pas atteint l'endroit exact. Ce qui est impossible.
• Étant donné qu'il est suivi d'une mission RecoverVehicle, un véhicule accidenté s'est probablement retrouvé à 43,63,2 et ce transport a été chargé de le récupérer. Je vais essayer une sauvegarde précédente pour voir comment ces missions ont été créées.
• L'ajout de la vérification que j'ai mentionnée dans le commentaire précédent (ne pas tenir compte de soi lors de la recherche de véhicules à éviter) empêche le véhicule d'entrer dans une boucle, mais à la place, il reste bloqué à 43,63,7.

En regardant cette sauvegarde précédente :

Je suppose que c'est lié aux tuiles détruites, car cela ne semble se produire qu'une fois que quelques bâtiments sont abattus par des raids

Cityscape semble être incroyablement lent lorsqu'il est placé sur ultra-vitesse
Au point d'être injouable

Veuillez trouver la sauvegarde ci-jointe

SuperHuman_Slow.zip

Blazer Turbo Bike 49 (près du bloc Hades détruit) essaie d'atteindre (86,78,2), qui est une tuile de route détruite. Mais de la même manière que pour le véhicule de construction bloqué, je vois que setPathTo est appelé à chaque tick pour ce véhicule, ce qui contribue probablement au ralentissement.

Voici un PR pour un correctif (uniquement vérifié manuellement) :
https://github.com/OpenApoc/OpenApoc/pull/563