Skip to content
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

Jump to bottom

Autoreplace resets vehicle variable F2 #3159

Closed
DorpsGek opened this issue Aug 30, 2009 · 4 comments
Closed

Autoreplace resets vehicle variable F2 #3159

DorpsGek opened this issue Aug 30, 2009 · 4 comments
Labels
component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)

Comments

@DorpsGek
Copy link
Member

dandan opened the ticket and wrote:

I wasn't sure whether to make this a bug report or a feature request, so I went for bug report to attract more attention ;-)

Autoreplace should IMO preserve the value of vehicle variable F2, so that cargo subtypes can be preserved just as the refitted cargo is.

While there is no way to make sure that the new vehicle will interpret variable F2 in the same way as the old (or even use it at all), resetting the value to 0 will usually produce undesired results when cargo subtypes are used.

Specifically, the next version of the Japanese train set will have a bunch of commuter trains that can be refitted to different colours (for different lines). I would like to have that choice of colour preserved by autoreplace.

Reported version: trunk
Operating system: All

This issue was imported from FlySpray: https://bugs.openttd.org/task/3159
@DorpsGek
Copy link
Member Author

DorpsGek commented Sep 2, 2009

Rubidium wrote:

Autoreplacing is going to another vehicle type; don't know how often plainly copying the F2 variable will be the correct choice. I reckon that in lots of the cases it's wrong; not allowed yet or the wrong sub type or just plainly wrong.

Might you be talking about autorenew? Replacing vehicles with the same type, i.e. autorenew?

This comment was imported from FlySpray: https://bugs.openttd.org/task/3159#comment6575

@DorpsGek
Copy link
Member Author

DorpsGek commented Sep 2, 2009

frosch wrote:

As written in the other task the value of var F2 can change the meaning itself over time.
The "correct" solution from the user point of view would likely be choosing a subcargo which results in the same text (wrt. language-invariant ID). Or falling back to 0 when none matches.
For RV, ships and aircraft the behaviour should be fine then.

Trains are more tricky as there are often subcargos of wagons which depend on the engine. So you can only decide for the subcargo after attaching. But current code refits new wagons before attaching.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3159#comment6576

@DorpsGek
Copy link
Member Author

DorpsGek commented Sep 2, 2009

dandan wrote:

My point was that keeping the current value would still be better in many cases than always reverting to 0, even though the results would be somewhat unpredictable. But I agree that searching for the cargo subtype resulting in the same text would be the ideal solution, I just didn't think of that.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3159#comment6579

@DorpsGek
Copy link
Member Author

Rubidium closed the ticket.

Reason for closing: Fixed

In r18499

This comment was imported from FlySpray: https://bugs.openttd.org/task/3159

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) component: NewGRF This issue is related to NewGRFs bug labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@DorpsGek