-
-
Notifications
You must be signed in to change notification settings - Fork 957
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
Request: Persistent storage for vehicles #6908
Comments
https://dev.openttdcoop.org/projects/xussrset/repository/entry/src/code-templates-mu.pnml - example of the direction selection code |
If someone wants to implement this, some notes:
To mitigate this, write access to persistent storage should be restricted to a single callback, probably a new one. The execution order and times need to be clearly defined, especially in relation to train user-data (callback 36 property 25, var 42). It also needs to be specified when persistent storage is copied or reset:
Though when reading the original requirement in the top post, the suggested storage is not as pesistent as it is for industries. It rather reads like resetting storage when rearranging/refitting/servicing vehicles. So vehicles could not use this "persistent" storage to track run-distance over their lifetime etc. |
IMHO, this should work similar to the random bits, i.e.
|
Assuming that this actually is a performance issue (do we know that?), then I am +1 to Eddi's suggestion. If there's no evidence that this is a performance issue, then I'm going to close it within 2019. |
This is a performance issue. |
point i forgot in the above list:
|
Is there are any profiling data or more detail for this? Helps diagnose the underlying issue. Similar to #4934 or https://www.tt-forums.net/viewtopic.php?f=29&t=58021 |
I don't know how feasible it would be to implement like this, but if the the cache could be implemented as a call of another callback, which takes a list of dependent input values as argument list, and this callback is only allowed to use the the arguments passed. The client is then able to cache the result of that callback reliably. That would perhaps require a NewGRF version bump? |
My current idea about this looks like this:
none of this should require a NewGRF version bump |
|
Persistent storage should be changed only at the point where a consist is altered? And unlike other variables, it should be saved in the savegame, I think. Property 25 is utterly static currently. We already have persistent storage so it makes sense to use that. |
Currently it would be enough if it is recalculated in depot when attaching a vehicle to consist (value should be recalculated for every vehicle in consist after a new vehicle is attached) Currently I can't check the value in var 25 (userbits) in other callbacks, like vehicle graphics, sound_effects, ect. |
This issue has been automatically marked as stale because it has not had any activity in the last two months. |
https://newgrf-specs.tt-wiki.net/wiki/Storages reports, that only Industries support persistent storage yet
It would be nice to have them for vehicles too. Currently xUSSR set makes a huge calculation to choose the right graphics for every engine. These calculations could be done once in can_attach_wagon or start_stop CBs, and them the final value would be easily used when graphics is chosen.
Please provide persistent storage for vehicles
The text was updated successfully, but these errors were encountered: