[OTTD] Dutch Tracks Development (0.1.0-Alpha1 released)

[Transportman]

Almost If you have only one kind of DC, use "D" and not "d". Using "E" for universal would be alright, just be aware that it would mean that vehicles from other GRFs that make no distinction between AC/DC are automatically universal engines. If that's okay, you're good.

Should you decide to use my example about the axle weights for the HSL track, you'd define all axle weights for the SA*A type, but only some for SB*A.

-- Michael Lutz

Thanks for this extensive explanation.

I am aware that using E for universal will make those vehicles lose the distinction between AC/DC, but I don't want to make the choice for players which tracks they use in that case. That is also the reason I use the ELRL label for the universal YARD rail, instead of using it for the Classical lines.

I have looked at the axle weights for the HSL and Betuweroute, HSL is C2 (20 ton) and Betuweroute is E5 (25 ton), but since all tracks around the Betuweroute only have D*, it is limited to 22,5 ton. Almost all DC electrified tracks are D* (some exceptions), the majority of the unelectrified tracks is also C2 (also some exceptions). So I don't think I will implement it in this set, because then we can get the situation that a train set loads a high speed AC engine with high axle load, and then it goes onto the SA*A which has a max speed of 120 km/h (which will make that engine almost completely useless). If I do implement it at some point, it will be with a parameter to switch it on/off.

It is a bit early for an April Fools joke, but I just pushed the basic-code to the repo, containing the track labels (at least, if I didn't copypaste things wrong). It is not playable yet, I haven't set the compatible and powered railtype lists yet, the properties are not set and other stuff, but the labels are in there.

[Snail]

Nice explanation!

Only one thing though...

The speed letter can also be used for eye-candy stuff, e.g. the rack rail in the French NG set, as it doesn't change vehicle behaviour.

Actually it does; it limits non-rackrail trains' max speed to 10 km/h (they need to go slow because of the rackrail's presence), and it boosts the rackrail engines' adhesion coefficient, therefore raising their TE. So, it can be seen as a very low-max-speed track with that extra feature.

[Transportman]

I have looked at the axle weights for the HSL and Betuweroute, HSL is C2 (20 ton) and Betuweroute is E5 (25 ton), but since all tracks around the Betuweroute only have D*, it is limited to 22,5 ton. Almost all DC electrified tracks are D* (some exceptions), the majority of the unelectrified tracks is also C2 (also some exceptions). So I don't think I will implement it in this set, because then we can get the situation that a train set loads a high speed AC engine with high axle load, and then it goes onto the SA*A which has a max speed of 120 km/h (which will make that engine almost completely useless). If I do implement it at some point, it will be with a parameter to switch it on/off.

I'm having second thoughts, I will include the axle weight in the labels, but set all axle weights as compatible and powered for now (and in the alternative railtype list as fallbacks). This way I can always include the parameter to switch things on/off at a later moment and have the labels correct. Metro will get a SAA3 label, while regulations in the Netherlands give a max of 12t, while A is 16t. Since A is the lowest in the scheme, I just take that one.

The new list will be:
Yard rail (Low speed Universal): ELRL (fallback for SAEE)
Unelectrified* (Medium speed NO Cat): RAIL (fallback for SADN)
Classical lines* (Medium speed DC): SADD
Betuwetoute (Medium Speed AC): SAEA
HSL* (High Speed AC): SBCA
Metro*: SAA3
Futuristic high speed line (No speed limit Universal): SBEE (changed to SBEE because it has speed grade B, while A is part of the Yard rail alternative_railtype_list)

Question about the railtype_list properties I have to provide, how does that go when I have multiple lists I want to include? Say I have a part that I always want and a part dependent on the parameter settings, can I then set the part I always want separately and then in an If statement the rest of the list? Or do I have to provide the complete list in the If statement?

I just provided the entire list in the if statement, that will always work

[Transportman]

I pushed some code to the devzone that includes some track properties. The following properties are included:
-Introduction date (I tried to take construction year in the Netherlands where possible, but for 1500V DC that currently has the situation that it is introduced around 1908 for the first electrified tracks were in that year, but 1500V DC was introduced in ~1922)
-Construction+maintenance costs (don't know if the values are good gameplaywise, tracks are between 2-4x more expensive than the vanilla OpenTTD tracks, 2x for unelectrified compared to unelectrified, 4x for Futuristic compared to MagLev)

Also, I am looking for people who would like to draw graphics. The default OpenTTD tracks are nice, but some more variation is needed. I think to keep the Unelectrified and 1500V DC as the default OpenTTD tracks for now, and have different graphics for Metro, Betuweroute, HSL, Yard and Futuristic. If you want to provide graphics, take a look the Devzone, there are templates and some notes on them. When you think that graphics from another set would fit in this set, just drop a message and I will look at it. In both cases the graphics need to be GPL v2.

Thanks in advance.

[jor[D]1]

Use the metro tracks, with yellow third rail, they are amterdam inspired.

For HLS you would need some rails which is built on concrete, instead of ballast.
For betuwe route you would need ligt gray ballast, with the curved fencing.

Idea? Is it possible to connect caternary poles to the track sprites. Make them part of the fencing or something. Then at the wires via an other GRF?

[FooBar]

I would drop the intro year entirely, and just have the vehicle set introduce the tracks whenever the first vehicle is available.

For the costs I recommend to stick to the default TTD costs for those track types that resemble the TTD track types the closest (e.g. 1k5 DC will get the cost of TTD electrified rail). For increased difficulty, you can include a parameter setting. I'm saying this because the train set is also balanced against the TTD costs. If you now make the tracks more expensive, there will be an unbalance between the trains and the tracks.

For the graphics:
- Indeed I'd use the metro track for the metro tracks
- You can use the Dutch Catenary for the 1k5 DC tracks.
- HSL and Betuweroute indeed need drawing for both the tracks and the catenary. HSL track will be very easy to draw. Betuweroute probably needs some recolouring of the default ballast and you're there.

Is it possible to connect caternary poles to the track sprites. Make them part of the fencing or something. Then at the wires via an other GRF?

What would be the advantage of that?
But regardless, there's only one type of fence for all railtypes (which isn't drawn everywhere). Poles on the track sprites will lead to heavy glitching. However it is possible to define custom catenary for each track type.

[Transportman]

Use the metro tracks, with yellow third rail, they are amterdam inspired.

I was thinking along that line also.

Idea? Is it possible to connect caternary poles to the track sprites. Make them part of the fencing or something. Then at the wires via an other GRF?

Not sure if I follow you, but you are saying to include the catenary poles in this set and let some other GRF provide the wires? It is possible if I understand the NML specs, but no, I will not do that, simply because then the poles have to be aligned to the wires, so then you can just as well provide the wires (although that means an additional 28 sprites).

I would drop the intro year entirely, and just have the vehicle set introduce the tracks whenever the first vehicle is available.

You're right, will fix that partially. I will keep an introduction year (year 2050 or something like that) in it, but that is needed to introduce the tracks when an unmodified train set is loaded.

For the costs I recommend to stick to the default TTD costs for those track types that resemble the TTD track types the closest (e.g. 1k5 DC will get the cost of TTD electrified rail). For increased difficulty, you can include a parameter setting. I'm saying this because the train set is also balanced against the TTD costs. If you now make the tracks more expensive, there will be an unbalance between the trains and the tracks.

Ok. And what about the other tracks (HSL and so on)? Higher or equal costs as the default tracks?

For the graphics:
- Indeed I'd use the metro track for the metro tracks
- You can use the Dutch Catenary for the 1k5 DC tracks.
- HSL and Betuweroute indeed need drawing for both the tracks and the catenary. HSL track will be very easy to draw. Betuweroute probably needs some recolouring of the default ballast and you're there.

-Haven't you drawn them? Sure I will include them (I do need to figure out which lights I will add at level crossings)
-But what happens when a player also has the Dutch Catenary GRF loaded? Then the 1k5 DC tracks and Yard rails actually become the same, leaving no distinction. But if I have the source, I can look at it, since it is GPL v3 the inclusion into this set shouldn't be a problem.
-You make it sound so easy. Maybe I give it a spin this weekend or after that (and I know my laptop is clean, had a nasty virus or two, so that takes priority this weekend), but if someone else wants to do it, that person would make me very happy.

What would be the advantage of that?
But regardless, there's only one type of fence for all railtypes (which isn't drawn everywhere). Poles on the track sprites will lead to heavy glitching. However it is possible to define custom catenary for each track type.

You can provide different fences for each track type according to the spec. See here

Also something I want a suggestion on, how to not let the Betuweroute-track end up as a slow AC track while all AC trains also can take the fast HSL-tracks. What is the best way to make a difference and give the Betuweroute-track an advantage?

[jor[D]1]

The best way is by making HSL more expensive.

For instance: A Traxx doing F140 can go 140km/h. It has no use to lay expensive HSL tracks for just this one loco.

Betuwe route should be a lot cheaper 25kV than HSL.
BTW. I like the betuwe route fencing and caternary, they so different.

Is it possible to connect caternary poles to the track sprites. Make them part of the fencing or something. Then at the wires via an other GRF?

What would be the advantage of that?
But regardless, there's only one type of fence for all railtypes (which isn't drawn everywhere). Poles on the track sprites will lead to heavy glitching. However it is possible to define custom catenary for each track type.

Nu tracks uses different fences. Didn't know different cateanry was possible per railtype, that would be really cool. But, some were in this topic it was said multiple caternary types aren't possible.

[Purno]

Use the metro tracks, with yellow third rail, they are amterdam inspired.

I was thinking along that line also.

Agreed! Didn't draw those sprites for nothing!

-But what happens when a player also has the Dutch Catenary GRF loaded? Then the 1k5 DC tracks and Yard rails actually become the same, leaving no distinction. But if I have the source, I can look at it, since it is GPL v3 the inclusion into this set shouldn't be a problem.

One GRF can recognize if another GRF is loaded, right? How about displaying a warning if both sets are loaded?

You can provide different fences for each track type according to the spec. See here

Oh wow, epic. Because normal railways are barely fenced off, but metro tracks are always fenced off. Shiny.

[FooBar]

Ah, I wasn't aware of the fences.

I'd make the betuweroute twice as expensive as 1500DC and the HSL eight times as expensive as 1500DC. Then you still have the balance with the default costs, as these are not default rails there is no problem to make these more expensive.

Metro probably as expensive as 1500DC. In real life it depends a bit on the amount of tunnels and viaducts. These make metro systems expensive. Regular level track is somewhat cheaper than regular rail track.

The track advantage of the betuweroute will come from the train set. Dual-current trains will have more power when running on 25k AC than when running on 1k5 DC. So if you need the power but not the speed (for a cargo train) you can build the slightly more expensive betuweroute. If you need both the power and the speed (a high speed passenger train), you need to build the massively expensive HSL.

[jor[D]1]

Like your idea, but in many sets you can also alter the price your self via a parameter. See Nutracks for instance.

[FooBar]

Those would just be the defaults. A parameter on top of that is not a bad idea.

[Transportman]

The best way is by making HSL more expensive.

For instance: A Traxx doing F140 can go 140km/h. It has no use to lay expensive HSL tracks for just this one loco.

Betuwe route should be a lot cheaper 25kV than HSL.
BTW. I like the betuwe route fencing and caternary, they so different.

I was thinking that also, but is not currently in the code. I need to find the values for the cost properties that match the OpenTTD values, and from there I can find reasonable costs for the other tracks.

Is it possible to connect caternary poles to the track sprites. Make them part of the fencing or something. Then at the wires via an other GRF?

What would be the advantage of that?
But regardless, there's only one type of fence for all railtypes (which isn't drawn everywhere). Poles on the track sprites will lead to heavy glitching. However it is possible to define custom catenary for each track type.

Nu tracks uses different fences. Didn't know different cateanry was possible per railtype, that would be really cool. But, some were in this topic it was said multiple caternary types aren't possible.

According to the spec it is possible. For fences I have seen the sprite order on the NFO-spec, but for the catenary and the wires I haven't seen such an order. And since there are 36 sprites necessary (8 pylons and 28 wires) it is a bit hard to just go guessing which order it should be.

Use the metro tracks, with yellow third rail, they are amterdam inspired.

I was thinking along that line also.

Agreed! Didn't draw those sprites for nothing!

Are we talking about the same sprites? I am talking about the ones in NuTracks, which list FooBar as drawer.

-But what happens when a player also has the Dutch Catenary GRF loaded? Then the 1k5 DC tracks and Yard rails actually become the same, leaving no distinction. But if I have the source, I can look at it, since it is GPL v3 the inclusion into this set shouldn't be a problem.

One GRF can recognize if another GRF is loaded, right? How about displaying a warning if both sets are loaded?

That is possible.

I'd make the betuweroute twice as expensive as 1500DC and the HSL eight times as expensive as 1500DC. Then you still have the balance with the default costs, as these are not default rails there is no problem to make these more expensive.

Metro probably as expensive as 1500DC. In real life it depends a bit on the amount of tunnels and viaducts. These make metro systems expensive. Regular level track is somewhat cheaper than regular rail track.

The track advantage of the betuweroute will come from the train set. Dual-current trains will have more power when running on 25k AC than when running on 1k5 DC. So if you need the power but not the speed (for a cargo train) you can build the slightly more expensive betuweroute. If you need both the power and the speed (a high speed passenger train), you need to build the massively expensive HSL.

Ok, those sound like reasonable numbers. Maybe I make HSL a bit cheaper than 8x 1500 DC, and the Futuristic a bit above 8x. But then you indeed have a good advantage to use the Betuweroute above the HSL.

Like your idea, but in many sets you can also alter the price your self via a parameter. See Nutracks for instance.

As with all of these things, I do intend to provide a parameter, but I'm not sure how I would do that for this one right away, so I will come back at that.

[FooBar]

the catenary follows the same order as in openttd.grf or the opengfx extra grf.

I didn't draw the metro tracks. That really is Purno. I just did some minor improvements on some pieces when (re)coding the metro track set. I had nothing to do with the inclusion of the sprites in nutracks, I wasn't even informed about it.

[Michi_cc]

I was thinking that also, but is not currently in the code. I need to find the values for the cost properties that match the OpenTTD values, and from there I can find reasonable costs for the other tracks.

Default cost factors are 8,12,16,24 (RAIL,ELRL,MONO,MGLV) for both construction and maintenance. I'd recommend using the default cost factors as the initial basis. Higher or lower costs could then be optionally achieved by changing the matching base cost.

-- Michael Lutz

[Transportman]

the catenary follows the same order as in openttd.grf or the opengfx extra grf.

Thanks, found the order. Also found the offsets that OpenGFX uses, so that makes things a little bit easier. It goes well as long as the wires stay the same. When those change, I am going to be busy for a while to match the offsets and stuff, but using the sprite aligner that should go relatively fast.

I didn't draw the metro tracks. That really is Purno. I just did some minor improvements on some pieces when (re)coding the metro track set. I had nothing to do with the inclusion of the sprites in nutracks, I wasn't even informed about it.

I made a note on it so that I can properly credit when I include them.

I was thinking that also, but is not currently in the code. I need to find the values for the cost properties that match the OpenTTD values, and from there I can find reasonable costs for the other tracks.

Default cost factors are 8,12,16,24 (RAIL,ELRL,MONO,MGLV) for both construction and maintenance. I'd recommend using the default cost factors as the initial basis. Higher or lower costs could then be optionally achieved by changing the matching base cost.

-- Michael Lutz

Thanks. I think FooBar's suggestion of HSL 8x 1500 DC will become a bit expensive in that case, would be around 80~100, so I think I have to tune that down a lot to be more around 30~40.

[Eddi]

i see no real problem with making HSL ridiculously expensive

[Purno]

i see no real problem with making HSL ridiculously expensive

I do. It makes sense the HSL is more expensive, but not "ridiculously" please

[jor[D]1]

How much realism do we want? HSL was a big flop in the netherlands and became 542356236 times as expensive as planned. (Same for betuwe route).

With several years of delay it finally operates now.

[Purno]

Obviously we're better Transport Tycoons than our national government.