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

Railtypes: define compatible tracktypes for a train #4582

Closed
DorpsGek opened this issue Apr 8, 2011 · 4 comments
Closed

Railtypes: define compatible tracktypes for a train #4582

DorpsGek opened this issue Apr 8, 2011 · 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

DorpsGek commented Apr 8, 2011

EmperorJake opened the ticket and wrote:

I would like the ability to define in a GRF, which tracktypes a locomotive is compatible with. Currently it is only possible to define tracktypes themselves as being compatible with each other or not, so there is no way to code a locomotive to be able to travel on a normally incompatibe tracktype, and also no way to disallow it on a normally compatible tracktype.
This would enable the creation of a GRF containing different, incompatible voltage systems that includes multi system locomotives that can use all voltages. It could also be used for a tracktype set in which tracks are priced based on their weight limit, and trains that are too heavy would not be allowed on a cheap tracktype.
It could also be used for a gauge change train that can switch between standard and narrow gauge on the fly. Or perhaps even a futuristic maglev-rail combination. Or disallowing freight trains on high speed tracks. The list goes on...

I think the best way to implement this would be to add an extra callback that decides which tracktypes are compatible with the locomotive and which aren't, regardless of whether the tracktypes themselves are compatible with each other.

Some more info at this thread: http://www.tt-forums.net/viewtopic.php?f=68&t=53950&p=940426

Thanks
Jake

Reported version: Version?
Operating system: All


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

dandan wrote:

I was just going to file the exact same feature request, following some discussions with Snail, the developer of the French Set.

Instead of a callback, such a property could also be provided as a bitmask referring to the first 32 (or 16) entries of the rail type translation table, just as for cargos.


This comment was imported from FlySpray: https://bugs.openttd.org/task/4582#comment10991

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 5, 2017

andythenorth wrote:

Recurred as an issue in the NotRoadTypes fork also. Sometimes specific vehicles want to be cross-compatible, rather than all vehicles for a given track-type.


This comment was imported from FlySpray: https://bugs.openttd.org/task/4582#comment14495

@DorpsGek
Copy link
Member Author

andythenorth wrote:

Different, but related: #5006


This comment was imported from FlySpray: https://bugs.openttd.org/task/4582#comment14684

@DorpsGek DorpsGek added flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) component: NewGRF This issue is related to NewGRFs enhancement labels Apr 7, 2018
@andythenorth
Copy link
Contributor

andythenorth commented Apr 13, 2018

See Peter's reply on #5006 (comment) - proposed implementation that would solve the issue described here.

Closing this ticket on the basis it should be solved in the railtypes. The problem is real but it's very unlikely that the solution proposed here would be adopted - allowing both railtype and vehicle tracktype callback to resolve compatibility is just asking for trouble. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
component: NewGRF This issue is related to NewGRFs flyspray This issue is imported from FlySpray (https://bugs.openttd.org/)
Projects
None yet
Development

No branches or pull requests

2 participants