Transport Tycoon Forums

If real-looking tracks have too large gaps between them, is that my department? 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.
I wouldn't be messing around with loads of extra parameters, and there only would need to be a single boilerplate for tracks, depots, fences and possibly signals that everyone could use to add their personal graphics.

Edit: Release of the "new" unintrusive catenary GRF.

Thanks for the praise oberhümer, haha. There's even more of the original dirt now to distinguish the very low speed...
I think the idea of just having some base tracks that can be changed is a great idea, especially if other infrastructure is included.

I toned down the red/ brown one level for everyone. I won't be doing anything much different as in real life most rails are a shade of brown due to the high iron content, except the head of the rail, which in most cases is cleaned each day..

http://www.railpictures.net/viewphoto.p ... 00&nseq=81

First three speeds knocked over, just the last two which should be easier...

having a problem with the new grf. it keeps telling me theres a sprite messing. wondered if anybody else has this problem

oberhümer wrote:If real-looking tracks have too large gaps between them, is that my department? 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"
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.

planetmaker wrote: 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

I'm not sure if the railtype scheme as discussed in those links is entirely up to date, the wiki shows the current state of things (and is also the way it is implemented in the Dutch Train Set).

The following code does not allow steam/diesel "low speed" trains (ID: RAIL) to run on medium speed electrified tracks (SCAE, position 26) and some others specified afterwards. Might the list be too long? There's no mention of a limit in the NML or NFO specs, but... Besides that, no trains at all are purchasable on electrified very low speed track (ID: SAAE) even though the same compatibility list is included.

oberhümer wrote:Besides that, no trains at all are purchasable on electrified very low speed track (ID: SAAE) even though the same compatibility list is included.

You also need to include "SAAE" in the powered_railtype_list of "ELRL" and there I don't see it in the list. Now your code says that "ELRL" trains are not powered on "SAAE", so then OpenTTD thinks that it doesn't make sense to allow buying the "ELRL" train in a "SAAE" depot.

Thanks, that and more fixed. However, I've found an OpenTTD or NML bug now - if I have more than 16 track type definitions included in the code, there's always an "Attempt to use invalid ID" error, even if most of the definitions are skipped and some are sharing IDs (so no reason at all to count double). Code with full bug documentation in the attachment.

I'll try to reproduce it with a simpler code (just 15 tracks in the code, but let 14 and 15 depend on a parameter setting).

A note on your code: why do you use introduction dates for all tracks? Now tracks can become available without a train for it. It is better to use introduces_railtype_list, the moment a train then becomes available, the track becomes available and all other tracks that are in that list also become available. So if an electric train becomes available, ELRL is introduced, and by putting all other electric tracks for the different speeds in the introduces_railtype_list those also become available at that moment, instead of depending on introduction date.

[EDIT1]Tested, and there is a bug in your code, somewhere your code does result in more then 16 track definitions. In the attached archive is a simple NewGRF+code that introduces 12 tracks with the parameter set to off, 13 with the parameter set to on. Together with the 4 default tracks, setting the parameter to on will result in 17 track definitions, triggering the error upon starting a game, but when set to off no error occurs.[/EDIT1]

[EDIT2]I looked through your code, couldn't find where it went wrong yet, but another comment on it. You have a number of pieces like this: And then later things like: You can also use param_force_3rd_rail in the second statement and remove the first in which you define param[20]. So the result would then become: This does exactly the same and I think it will increase readability of your code, or is there a specific reason why you do it the way you do it?[/EDIT2]

All done now, just have found one copy and paste alignment to fix but after that will forward it on and then I've done my part I do have a working version using 1.1.2 though...

Current status: All code finished except for that one bug. One graphics set (the old graphics from 1.1.2, with narrow gauge taken from the Japan Set tracks) also coded. Planning on three more: 1. the narrow tracks by coalroads_artist, 2. OpenGFX style from the Japan Set, 3. OpenGFX style from the Japan Set (narrow).
Changing to automatic introduction of associated track types will be easy. About the second bit, I'll just give all parameters names.

The bug now: Even when I write the code as , it makes a difference whether the include is commented out or not.

Good news about the graphics, but have you thought of narrow gauge tracks? They're now in too.

oberhümer wrote:The bug now: Even when I write the code as

Code: Select all

if (0 == 1) {
#include track_type_X_code.pnml
}

, it makes a difference whether the include is commented out or not.

The if-statement is only checked by OpenTTD, so the final grf-file will contain the code you include through track_type_X_code.pnml, even if the if-statement can never be true.

something that kinda disturbs me: the "narrow" trackbase under straight tracks vs. the "broad" trackbase under crossings...

Transportman wrote:

oberhümer wrote:The bug now: Even when I write the code as

Code: Select all

if (0 == 1) {
#include track_type_X_code.pnml
}

, it makes a difference whether the include is commented out or not.

The if-statement is only checked by OpenTTD, so the final grf-file will contain the code you include through track_type_X_code.pnml, even if the if-statement can never be true.

The whole point is that if everything inside the statement is skipped, what actually is there or not there shouldn't make a difference in-game - but it does!

IIRC the content of an if-statement is loaded, but are only considered when it evaluates to that section. So the spriteviewer contains the sprites that should be loaded according to the code in the if-statement, but the label is not loaded, since the if-statement does not evaluate to that part of the code. But I'm not 100% sure about it, a dev should confirm it (or correct me).

I could do some narrow gauge tracks but probably only three versions - wooden/dirt, wooden/ballast and concrete. Just can't commit to another 5 different tracks.. I would then be able to play an Australian scenario

coalroads artist wrote:All done now

Very very nice tracks... very much like them!
As most of my time is spent in arctic can I/or we see arctic shot too?

Thank You!

Thanks! Sure.

Also very nice!

Eddi wrote:something that kinda disturbs me: the "narrow" trackbase under straight tracks vs. the "broad" trackbase under crossings...

The only thing that catch my eyes at first too - any planning to correct this ?
At least, good graphics, it'll match pikka's finescale track - nice small thing !!