Openapoc: Множество разрушенных плиток в городском пейзаже, кажется, замедляют игру до остановки в Ultra-Speed

Враждебные машины, такие как строительные машины, выполняющие задание, также, кажется, влияют на

Еще один пример из более позднего сохранения.
save_SuperHuman 1.zip

Транспортные средства тоже, кажется, застревают

Обнаружен застрявший автомобиль
Это над мега-флаером, с сохранением
save_SuperHuman 1.zip

Я отлаживаю застрявшую машину (Строительная машина 31).
Его миссии на момент сохранения:

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

Однако пункт назначения (43,63,2) переписывается в (43,63,7) с помощью adjustTargetToClosestFlying.
После этого транспортное средство колеблется между попытками перейти к (43, 63, 7) и случайной ближайшей целью с каждым вызовом 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)
...

Спасибо, что заглянули в

Если вы можете найти решение, я буду очень признателен

В идеале мы хотим, чтобы транспортное средство распознало, что оно застряло в петле, и сгенерировало новую миссию в подходящую, четкую конечную точку назначения, поскольку я подозреваю, что отсутствие проверки случайной цели, являющейся подходящим пунктом назначения, заставляет цикл

Я замечаю, что, когда машины застревают в этих петлях, они часто оказываются на клетках посадочной трубы или на фабриках мегафлаеров.

Не уверен, почему именно фабрики Mega-Flyer вызывают такую ​​проблему, если где-то нет плохого типа плитки ???

Похоже, это логика «ухода в сторону», которая должна срабатывать, когда пункт назначения занят другим транспортным средством. Цель временно меняется на ближайшую пустую плитку. Как только машина доберется до этой плитки, она снова попытается перейти к исходной цели.

Однако в этом случае каким-то образом автомобиль, вызывающий уклон, - это CV31, то есть он думает, что вот-вот столкнется с самим собой. код
Дополнительные журналы, которые я добавил, показывают это:

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.

Хорошая идея - добавить дополнительную проверку, чтобы убедиться, что автомобили не пытаются избежать самотек.
Тем не менее, я не уверен, почему обходной путь не решает эту проблему ...

Еще несколько примечаний по отладке:

• Миссии машины:

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 недоступен - он занят зданием MEGAFLYER_TWO.
• Листовки ищут ближайшую доступную плитку, поднимаясь вверх. В данном случае это 43,63,7.
  
• pickNearest неверно для этой миссии GotoLocation - поэтому она не будет завершена, пока машина не достигнет точного места. Что невозможно.
• Учитывая, что за ним следует миссия RecoverVehicle, вероятно, разбитый автомобиль оказался на отметке 43,63,2, и этому транспорту было поручено его восстановить. Я попробую более раннее сохранение, чтобы увидеть, как создавались эти миссии.
• Добавление проверки, о которой я упоминал в предыдущем комментарии (не принимайте во внимание себя при поиске транспортных средств, которых следует избегать), предотвращает зацикливание транспортного средства, но теперь вместо этого он просто застревает на 43,63,7.

Глядя на это более раннее сохранение:

Я предполагаю, что это связано с разрушенными плитками, так как кажется, что это происходит только после того, как несколько зданий разрушены рейдами.

Городской пейзаж кажется невероятно медленным в сверхскоростном режиме.
До невозможности играть

Сохранение прилагается

SuperHuman_Slow.zip

Blazer Turbo Bike 49 (около разрушенного блока Аида) пытается добраться до (86,78,2), который представляет собой разрушенную дорожную плитку. Но, как и в случае с застрявшей строительной машиной, я вижу, что setPathTo вызывается в каждом тике для этого транспортного средства, что, вероятно, способствует замедлению.

Вот PR для исправления (только проверено вручную):
https://github.com/OpenApoc/OpenApoc/pull/563