Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
Road vehicle pathing cache does not always pick up changes in road network #7670
Version of OpenTTD
Custom one based on 20190722, https://github.com/SamuXarick/OpenTTD/tree/SamuPatchPackRebase
YAPF should have a lower average ms than NPF
YAPF has a higher average ms time than NPF
Steps to reproduce
Load savegame and open framerate window, then switch to NPF and notice the difference.
YAPF: ~135 ms
This system has windows 7, 4GB RAM, Celeron E1400, 2 cores @ 2.00 GHz
First off, do not submit issues relating to custom versions of OTTD, they are unsupported, especially when they contain a savegame bump and the provided save cannot be loaded in unmodified OTTD
Second, while 35ms vs 135ms is a big change, "YAPF is slower than NPF" is not an issue in itself - YAPF is designed to be "better" than NPF, but that does not necessarily mean "faster".
I'll give you... let's say a day to submit an actual reproducing savegame that I can actually load in master.
Here are my tests for Wentbourne savegame. The test was ran in 20190723-master-g2e686ad5d5-windows-win32 using an Intel(R) Core(TM)2 Duo CPU T5800 @ 2.00GHz and 3 GB of RAM. Times are in milliseconds per tick (mspt).
Edit: added link to save game
The problem is the combination of line 1381 and 1398 in roadveh_cmd.cpp. At 1381 it calls the pathfinder, and at 1398 the vehicle finds itself blocked, so there's no update to the vehicle position on the current tick.
The issue is also happening with NPF, not just YAPF. NPF is just less cpu intensive about it, but still noticeable.