Openapoc: Muitos ladrilhos destruídos na paisagem urbana parecem retardar o jogo até uma parada em Ultra-Speed

Veículos hostis, como veículos de construção em uma missão, também parecem impactar

Um outro exemplo posterior em salvar o jogo
save_SuperHuman 1.zip

Os veículos também parecem estar presos

Localizou o veículo preso
Está acima do megafolheto, salve em anexo
save_SuperHuman 1.zip

Estou depurando o veículo preso (Veículo de construção 31).
Suas missões na hora do savegame são:

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

No entanto, o destino (43,63,2) é reescrito para (43,63,7) por ajustarTargetToClosestFlying.
Depois desse ponto, o veículo oscila entre tentar ir para (43, 63, 7) e um alvo próximo aleatório com cada chamada para 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)
...

Obrigado por olhar para este @ashenomo <3

Se você puder encontrar uma solução eu ficaria muito grato

Idealmente, queremos que o veículo reconheça que está preso em um loop e gere uma nova missão para um destino final adequado e claro, pois suspeito que seja a falta de uma verificação se o alvo aleatório é um destino adequado que força o loop

Percebo que, quando os veículos ficam presos nesses loops, eles costumam estar em Ladrilhos de Tubo de Aterrissagem ou Fábricas de Mega-Flyers

Não sei por que as fábricas Mega-Flyer em particular causam tal problema, a menos que haja um tipo de telha ruim em algum lugar ??

Parece que essa é a lógica "evasiva" que deve ser acionada quando o destino é ocupado por outro veículo. O alvo é temporariamente alterado para um ladrilho vazio próximo. Uma vez que o veículo chega a esse ladrilho, ele tenta novamente ir para o alvo original.

No entanto, neste caso, de alguma forma, o veículo que está causando o desvio é o CV31, ou seja, ele pensa que está prestes a colidir com ele mesmo. código
Registros adicionais que adicionei mostrando isso:

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.

Adicionar uma verificação adicional para garantir que os veículos não tentem evitar a si próprios parece uma boa ideia.
Dito isso, não tenho certeza de por que a evasão não resolve isso.

Mais algumas notas de depuração:

• As missões do veículo são:

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á inacessível - está ocupado por um edifício MEGAFLYER_TWO.
• Os panfletos procuram o ladrilho mais próximo acessível subindo. Nesse caso, é 43,63,7.
  
• pickNearest é falso para esta missão GotoLocation - portanto, não será concluída até que o veículo alcance o local exato. O que é impossível.
• Dado que é seguido por uma missão RecoverVehicle, provavelmente um veículo acidentado terminou em 43,63,2 e este transporte foi designado para recuperá-lo. Vou tentar um savegame anterior para ver como essas missões foram criadas.
• Adicionar a marca que mencionei no comentário anterior (não se leve em consideração ao procurar veículos a serem evitados) evita que o veículo entre em um loop, mas agora ele apenas fica preso em 43,63,7.

Olhando para este savegame anterior:

Suponho que esteja relacionado a telhas destruídas, já que só parece ocorrer quando alguns edifícios são derrubados por ataques

A paisagem urbana parece ser incrivelmente lenta quando colocada em ultra-velocidade
A ponto de ser impossível de jogar

Por favor encontre salvar em anexo

SuperHuman_Slow.zip

Blazer Turbo Bike 49 (perto do Bloco Hades destruído) está tentando chegar a (86,78,2), que é um ladrilho de estrada destruído. Mas, da mesma forma que o veículo de construção preso, vejo setPathTo sendo chamado a cada tick para este veículo, o que provavelmente contribui para a desaceleração.

Aqui está um PR para uma correção (verificado apenas manualmente):
https://github.com/OpenApoc/OpenApoc/pull/563