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:

• Currently NewGRF vehicles use a functional programming approach, where multiple properties are evaluated via independent callbacks. In most cases it does not matter in which order and when the callback are called, which allows caching.
• Persistent storage are an imperative programming approach. Callbacks that can write persistent storage are prone to break stuff, if they are called in different order or cases, or with different caching. So they dead-lock OpenTTD into never changing any behaviour with them.

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).
All other callbacks should likely be called after these two.

It also needs to be specified when persistent storage is copied or reset:

• Vehicle cloning
• Vehicle autoreplace
• Train rearrangement
• ...

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.

• there are "triggers" (bitmask, property) when the recalculation callback should be run (e.g. on empty vehicle, on servicing, on railtype change, regular-interval ...)
• could use the same way to store as the random bits, or even share the space
• could be run at the same time as the random trigger callback

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:

• we also got the userbits, so this could be an alternate method to access those

This is a performance issue.

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:

• Add a callback to set the value of prop 25 (userbits, currently 8 bits, could be extended to 15?)
• Add a property to set the flags when that callback should be called (same meaning as random trigger flags)
• Add additional variables to complement var 42 (OR over all vehicles in the consist), e.g.
  • AND over all vehicles
  • this vehicle only

none of this should require a NewGRF version bump

• we also got the userbits, so this could be an alternate method to access those
  then we need some way to specify, when we can change them

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.
If you believe the issue is still relevant, please test on the latest nightly and report back.
It will be closed if no further activity occurs within 7 days.
Thank you for your contributions.