New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Road vehicle pathing cache does not always pick up changes in road network #7670
Comments
[18:52] looks like the company affected is that of Terron |
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 |
Looks like YAPF is better than NPF on vanilla? So this may be an issue with your patch pack. If thats a typo then you should provide the .sav as well to see if others can reproduce. |
from irc: https://webster.openttdcoop.org/index.php?channel=openttd&date=1564185600#1564261315 The problem seems to be very specific to unconnected roads that I assume were connected at first. AI detected road vehicles crash there, and so it removed the roads, probably attempting to build a bridge over it. I really doubt my custom build has any influence in that, with like 99.9% certainty. It's a build that reworks AI GUI windows and AI max ops. It doesn't touch anything related to YAPF or NPF nor any commands. of that nature. |
new savegame, reproduced the scenario. |
a better savegame, based on the previous one, but only requiring 2 vehicles to trigger the issue, with a giant road network. |
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. Line 1381 in 460f73c
Line 1398 in 460f73c
The issue is also happening with NPF, not just YAPF. NPF is just less cpu intensive about it, but still noticeable. |
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
Fixing this (at least as suggested in #7822) requires bumping the savegame version, will that prevent it from being fixed in 1.10 now that it has branched? |
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
… the road pathfinder when a vehicle is blocked by another
Looking at the attached savegame (road vehicle ticks.zip), all the pf settings have totally incorrect values. See also: JGRennison/OpenTTD-patches@bb36369 |
Version of OpenTTD
Custom one based on 20190722, https://github.com/SamuXarick/OpenTTD/tree/SamuPatchPackRebase
Expected result
YAPF should have a lower average ms than NPF
Actual result
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.
road vehicle ticks.zip
YAPF: ~135 ms
NPF: ~35 ms
This system has windows 7, 4GB RAM, Celeron E1400, 2 cores @ 2.00 GHz
The text was updated successfully, but these errors were encountered: