Supongo que está relacionado con mosaicos destruidos, ya que solo parece ocurrir una vez que algunos edificios son derribados por incursiones
El paisaje urbano parece ser increíblemente lento cuando se coloca en ultravelocidad
Hasta el punto de ser injugable
Por favor, busque guardar adjunto
Los vehículos hostiles, como los vehículos de construcción en una misión, también parecen afectar
Otro ejemplo de más adelante en la partida guardada
save_SuperHuman 1.zip
Los vehículos también parecen atascarse
Localizó el vehículo atascado
Está encima del megavolante, guárdalo adjunto.
save_SuperHuman 1.zip
Estoy depurando el vehículo atascado (Vehículo de construcción 31).
Sus misiones en el momento de la partida guardada son:
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
Sin embargo, el destino (43,63,2) se reescribe en (43,63,7) por adjustTargetToClosestFlying.
Después de ese punto, el vehículo oscila entre intentar ir a (43, 63, 7) y un objetivo cercano aleatorio con cada llamada a 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)
...
Gracias por investigar esto @ashenomo <3
Si puedes encontrar una solución, te lo agradecería mucho.
Idealmente, queremos que el vehículo reconozca que está atascado en un bucle y genere una nueva misión a un destino final adecuado y claro, ya que sospecho que es la falta de verificación de que el objetivo aleatorio sea un destino adecuado lo que obliga al bucle.
Me doy cuenta de que cuando los vehículos se atascan en estos bucles, a menudo se encuentran en Losetas de tubo de aterrizaje o fábricas de Mega-Flyers.
¿No estoy seguro de por qué las fábricas Mega-Flyer en particular causan tal problema, a menos que haya un tipo de mosaico malo en alguna parte?
Parece que esta es la lógica de "desvío" que debe activarse cuando el destino está ocupado por otro vehículo. El objetivo se cambia temporalmente a una casilla vacía cercana. Una vez que el vehículo llega a esa casilla, vuelve a intentar ir al objetivo original.
Sin embargo, en este caso, de alguna manera el vehículo que causa el desvío es el CV31, es decir, cree que está a punto de chocar contra sí mismo. código
Registros adicionales que agregué mostrando esto:
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.
Agregar una verificación adicional para asegurarse de que los vehículos no intenten evitarse suena como una buena idea.
Dicho esto, no estoy seguro de por qué no resolver esto ...
Algunas notas más de depuración:
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
pickNearest
es falso para esta misión GotoLocation, por lo que no se completará hasta que el vehículo llegue al lugar exacto. Que es imposible.Mirando este juego guardado anterior:
Supongo que está relacionado con mosaicos destruidos, ya que solo parece ocurrir una vez que algunos edificios son derribados por incursiones
El paisaje urbano parece ser increíblemente lento cuando se coloca en ultravelocidad
Hasta el punto de ser injugablePor favor, busque guardar adjunto
Blazer Turbo Bike 49 (cerca del bloque Hades destruido) está tratando de llegar a (86,78,2), que es una loseta de carretera destruida. Pero de manera similar al vehículo de construcción atascado, veo que se llama a setPathTo en cada tick de este vehículo, lo que probablemente contribuya a la desaceleración.
Aquí hay un PR para una solución (solo verificado manualmente):
https://github.com/OpenApoc/OpenApoc/pull/563
Comentario más útil
Aquí hay un PR para una solución (solo verificado manualmente):
https://github.com/OpenApoc/OpenApoc/pull/563