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

NRT uses "backwards" roadtype intercompatibility, at least in NML #8275

Closed
Gadg8eer opened this issue Jul 17, 2020 · 1 comment
Closed

NRT uses "backwards" roadtype intercompatibility, at least in NML #8275

Gadg8eer opened this issue Jul 17, 2020 · 1 comment

Comments

@Gadg8eer
Copy link

@Gadg8eer Gadg8eer commented Jul 17, 2020

So apparently I can fix this myself by adding a dummy ROAD definition. Sorry to bother you all with this!

Version of OpenTTD

20200713-master-g706c47265e

Expected result

This is a tricky one to explain. The expected result, according to the NML specs, is that NRT roadtypes have "outbound compatibility". This is the result I get, and the result that every NRT GRF is programmed to use. However...

Actual result

Railtypes, which have "inbound compatibility", are made compatible in NML as follows...

My TST2 NewGRF
compatible_railtype_list: (insert TST1 railtype made by someone else)

...and in this example, result in trains meant to run on TST1 will also run on TST2.

But roadtypes are compatible in NML as follows...

Other Person's NRT2 NewGRF
powered_roadtype_list: (insert my NRT1 roadtype)

...and road vehicles meant to drive on NRT2 will also drive on NRT1.

Technically, the actual result is EXACTLY what it's said to be, but in practice this means that whichever roadset replaces the ROAD roadtype is the one which defines whether ROAD vehicles can run on roadtypes provided by other GRFs.

I have already tested adding ROAD to "alternative_roadtype_list". All control over whether a ROAD vehicle can travel on any other GRF's roadtypes is in the hands of the NewGRF creator who created the replacement for ROAD.

I would like to propose minimal code changes, that NRT would use "compatible_roadtype_list" to provide inbound compatibility, or that "alternative_roadtype_list" will act as a fallback for other roadtypes even when the roadtypes listed are available.

Steps to reproduce

The simplest way is to use URaTT 0.2 or RaTT 1.0.2 with eGRVTS NRT r204 and WaterWayRoad 0.3.1, then try to get a road vehicle to cross the River Ford roadtype (FORD).

@Gadg8eer Gadg8eer changed the title NRT uses "backwards" roadtype intercompatibility NRT uses "backwards" roadtype intercompatibility in NML Jul 17, 2020
@Gadg8eer Gadg8eer changed the title NRT uses "backwards" roadtype intercompatibility in NML NRT uses "backwards" roadtype intercompatibility, at least in NML Jul 17, 2020
@Gadg8eer
Copy link
Author

@Gadg8eer Gadg8eer commented Jul 17, 2020

So apparently I can fix this myself by adding a dummy ROAD definition. Sorry to bother you all with this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants