oberhümer wrote:If real-looking tracks have too large gaps between them, is that my department?
![Wink :wink:](./images/smilies/icon_wink.gif)
What I'm tempted to do at this time is simplify things even more by not actually coding
any graphics into the main NuTracks GRF. They would instead be provided by separate "adapters" that could be chosen by personal preference, I think Swedish Rails already has an option to do something of the sort.
SwedishRails allows to select the railtype label which its graphics shall be provided for. By default the two default railtypes, RAIL and ELRL are replaced. The other options were basically only provided so that it could work well together with NuTracks and be shown instead of any of the rail and electrified railtypes it provides. These options might meanwhile be outdated a bit, so that it doesn't work properly any longer with new(er) NuTracks due to railtype label changes therein.
For NuTracks I'd not advise to actually become only an empty railtype NewGRF as there's no real point for such set. But it's moderately easy to provide a parameter for each tracktype as to what label it shall replace. But on the other hand NuTracks tracks are unique enough so that this approach makes not much sense either: it provides several rail and several electrified rail types which necessarily need to be distinct.
My personal suggestion for a nice configuration of NuTracks would be (I've always been overwhelmed by its huge amount of tracktypes):
parameter for railtype label scheme:
- default: use of a railtype scheme as also discussed in the context of CETS like
http://dev.openttdcoop.org/issues/2763 or
https://docs.google.com/spreadsheet/ccc ... li=1#gid=9
- legacy: use of the old railtype label scheme
parameters for the amount of railtypes where 'simple' means few and 'advanced' means more detailed distinction:
- rail:
* simple (default) (2 types)
* advanced
- erail:
* simple (default) (2 types)
* advanced
- 3rdrail:
* none
* simple (default) (2 types)
* advanced
- maglev:
* none
* MGLV (default)
- Narrow gauge:+
* none (default)
* simple (2 types: normal + electrified)
* advanced (?)
- other:
* none (default)
* rack
Something like this would give 7 railtypes by default and could end up using all again when all adv. options are used.
Make it easy for yourself: screw backward compatibility to OpenTTD <= 1.2, it's of little gain. People with older versions can use the existing NuTracks after all. Start with the "simple" option only and add that additional parameter only when "done"
![Smile :-)](./images/smilies/icon_smile.gif)
Keeping it GPL you definitely should take a look at the
railtype support of the DutchTrainSet code by FooBar - it's IMHO the prototype implementation for good railtype support on the vehicle side and uses the advanced track classification scheme as discussed for CETS.