[OpenTTD] NuTracks - Dev Thread

[FLHerne]

- Removed the metro tracks

Does that include the third-rail tracks at various speeds? Hopefully not...

[oberhümer]

No, they're conceptually closer to the core tracks, so they're definitely staying.

Edit: Junction glitches fixed.

[FLHerne]

No, they're conceptually closer to the core tracks, so they're definitely staying.

That's good

[Fenris]

Edit: Junction glitches fixed.

So fast? Many thanks!

[oberhümer]

Well, it only took two minutes...

[Fenris]

Well, it only took two minutes...

And it took me about 1 year to report...

[NekoMaster]

So, by removing the metro tracks, does that mean above ground and faux underground 3rd rail will be removed? I've never gotten the metro track set to work with anything, even the 2cc set (which hasnt been updated in ages)

Also, will this set include graphics and a parameter to select between narrow, standard, and broad gauge rails? I know the setting is there but I dont think it does anything right now.

[coalroads artist]

Things are going well with drawing. Finished all views today for low speed track and now the rest will be easy. Will be interesting to see how that new catenary supports will look with the tracks

Nekomaster: I don't know about oberhümer's interest in different gauges but I was doing some narrow gauge tracks earlier, not the ones currently being worked on as they are for standard gauge use. They are standard gauge, just a finer scale that's all. I think just trying to have a standard gauge set is a goal for now...

[coalroads artist]

Also a small change to very low speed with dirt. The very low speed can be seen at the station and the siding.

[Eddi]

imho the tracks look too red (rusty), maybe you should try to use a more grey/metal colour?

[oberhümer]

So, by removing the metro tracks, does that mean above ground and faux underground 3rd rail will be removed?

Any set that provides regular third-rail-running trains will continue to work with only NuTracks, the Metro Track Set will only be necessary for true metros. The "faux underground" tracks will indeed be removed, and reimplemented in the Metro Track Set if necessary.

I've never gotten the metro track set to work with anything, even the 2cc set (which hasnt been updated in ages)

I've tested the newest NuTracks in combination with the Metro Track Set 2.1.0 (bananas version) and the newest or rather least old 2cc set nightly (r756), and everything works perfectly.

Also, will this set include graphics and a parameter to select between narrow, standard, and broad gauge rails?

Especially narrow gauge is a long-term goal, yes, but not right now. Still would be nice to also have some graphics for non-standard gauges (hint...).

The rails also look a little too brown to me, but it looks like a simple select-all+fill job that could be done anytime, so no need to worry about that.
ed: Almost forgot to praise the new very low speed tracks - well, here you go

[Ogre]

Edit: Junction glitches fixed.

So fast? Many thanks!

Well, parts of the glitch are still present.

NuTracks_Track_Glitch.png

(78.43 KiB) Downloaded 7 times

It seems that there are two pixels missing on both the brighter and the darker grey lines of the rails. Note that these pixels are missing on all railtypes, but they are less apparent on other railtypes than very slow tracks with its brown dirt. While this is a rather small issue, is this fixable, too?

Edit: Simple diagonal (in other words, horizontal) tracks are not affected, they must be built as a switch to "cut out" these pixels.

[FLHerne]

Another query: Will the current (non-'finescale') track graphics still be available? I'm not (personally) a particular fan of the small ones - to me, it makes the gap between tracks look rather too large relative to the tracks themselves...

Those do look rather nice, though.

[oberhümer]

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.

[coalroads artist]

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...

[jonnie47]

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

[planetmaker]

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.

[Transportman]

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).

[oberhümer]

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...

Code: Select all

  compatible_railtype_list: ["RAIL", "RLOW", "RMED", "RHIG", "SAAN", "SABN", "SACN", "SBAN", "SBBN", "SBCN", "SCAN", "SCBN", "SCCN", "SDAN", "ELRL", "3RDC", "ELOW", "CLOW", "EMED", "CMED", "EHIG", "HSTR", "SBAE", "SBBE", "SBCE", "SCAE", "SCBE", "SCCE", "SDAE", "SEAE", "3RDR", "3LOW", "3MED", "SAA3", "SAB3", "SAC3", "SBA3", "SBB3", "SBC3", "SCA3", "SCB3", "SCC3", "SAAZ", "SABZ", "SACZ", "SBAZ", "SBBZ", "SBCZ", "SCAZ", "SCBZ", "SCCZ"];

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

[Transportman]

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.