Openapoc: Muchas fichas destruidas en el paisaje urbano parecen detener el juego en Ultra-Speed

Creado en 11 oct. 2018  ·  10Comentarios  ·  Fuente: OpenApoc/OpenApoc

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

SuperHuman_Slow.zip

!BUG! HIGH PRIORITY !BUG! low priority Help Wanted

Comentario más útil

Aquí hay un PR para una solución (solo verificado manualmente):
https://github.com/OpenApoc/OpenApoc/pull/563

Todos 10 comentarios

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
image

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:

  • Las misiones del vehículo son:
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 es inalcanzable - está ocupado por un edificio MEGAFLYER_TWO.
  • Los voladores buscan la ficha más cercana al alcance subiendo. En este caso es 43,63,7.
    Screen Shot 2019-04-26 at 0 18 30
  • 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.
  • Dado que le sigue una misión RecoverVehicle, probablemente un vehículo accidentado terminó en 43,63,2 y este transporte fue asignado para recuperarlo. Probaré una partida guardada anterior para ver cómo se crearon estas misiones.
  • Agregar el cheque que mencioné en el comentario anterior (no se tome en cuenta al buscar vehículos para evitar) evita que el vehículo entre en un bucle, pero ahora, en cambio, simplemente se atasca en 43,63,7.

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 injugable

Por favor, busque guardar adjunto

SuperHuman_Slow.zip

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

¿Fue útil esta página
0 / 5 - 0 calificaciones

Temas relacionados

Quickmind01 picture Quickmind01  ·  3Comentarios

Quickmind01 picture Quickmind01  ·  3Comentarios

FilmBoy84 picture FilmBoy84  ·  3Comentarios

makus82 picture makus82  ·  3Comentarios

FilmBoy84 picture FilmBoy84  ·  3Comentarios