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

vehicle has power (variable 4A, r20165) #3957

Closed
DorpsGek opened this issue Jul 17, 2010 · 5 comments
Closed

vehicle has power (variable 4A, r20165) #3957

DorpsGek opened this issue Jul 17, 2010 · 5 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay

Comments

@DorpsGek
Copy link
Member

planetmaker opened the ticket and wrote:

r20165 introduced vehicle var 4A which returns the previously unaccessible current railtype, but it also returns a "vehicle is powered" bit.

The latter is a not-exact duplication of bit 6 of vehicle mod variable FE and thus introduces an inconsistency. I propose to remove this power-information bit from variable 4A again and refer newgrf authors to the existing bit in variable FE in order to keep code maintenance work lower. Attached two patches, on which makes the two definitions consistent, the other alternatively removes this bit from variable 4A.

Attachments

Reported version: trunk
Operating system: All


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

michi_cc wrote:

The point of the flags in var 4A is to give some information even if the actual rail type has no entry in the translation table.

This allows for example to lift a pantograph on electric railways. It shouldn't depend on powered-wagon state or anything else to not limit these things just to powered wagons.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3957#comment8350

@DorpsGek
Copy link
Member Author

planetmaker wrote:

I don't understand.

I don't dispute the check for the railtype at all, that's a great addition!

This is only about the duplication of the 'has_power' bit - which both bits, this one in var 4A and the one in var FE use to describe their use. To me that implies that it is
a) either an engine or powered wagon
and
b) is on a railtype which provides power to that type.

Correct me if I'm wrong, I seem to lack some insight here: the difference is, that using var 4A a vehicle which intrinsically cannot have power can also yield the result 'has_power' under the condition that it is its primary or a compatible railtype which it is designed for. As such the 'has_power' check of this wagon will be wrong, if the actually powered vehicles define different railtype preferences. Where or how do I need this check or what would be the appropriate name, if seemingly not 'has_power'? Or alternatively: where does the FE variable 'has_power' check return true when it should not?


This comment was imported from FlySpray: https://bugs.openttd.org/task/3957#comment8352

@DorpsGek
Copy link
Member Author

frosch wrote:

Var FE does not work for articulated vehicles, as they are not engines. (Accessing the front vehicle does not help for multiple engines.)
For var 4A the Grf needs to know itself, whether the vehicle is a engine or powered wagon.

So:

  1. You want to modify running costs if a vehicle is powered -> Articulated parts do not need to control this. -> Use var FE.
  2. You want to show sprites depending of poweredness -> You need it for all vehicles, not only the front parts. -> Use var 4A.

This comment was imported from FlySpray: https://bugs.openttd.org/task/3957#comment8353

@DorpsGek
Copy link
Member Author

planetmaker wrote:

following up IRC discussions and clearifications here, this task can be closed.


This comment was imported from FlySpray: https://bugs.openttd.org/task/3957#comment8384

@DorpsGek
Copy link
Member Author

frosch closed the ticket.

Reason for closing: Requested by user

two variables for two things


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

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay
Projects
None yet
Development

No branches or pull requests

1 participant