New Rail Types

[broodje]

[speed limits]

Here's an article from 1898 giving the tech specs and details of US vs UK high-speed rail. The New York Central's famous "999", which set the world speed record in 1891 with an unofficial top speed of 112 mph/188 kph, is pitted against the GWR's "Worcester."
Top speeds of 93 mph/150 kph are entirely reasonable for this era- if the track, the grades and the curves allow.

http://www.catskillarchive.com/rrextra/stamen.Html

There are 2 discussions going on now between different track types, I really think they should be combined: Both the axle load and the speed limit have a significant influence on the price of a mile of track. Especially the axle load could be a really interesting factor in the early years in my opinion, it could make engine selection so much more interesting; are you going for multiple cheap short light trains, or for heavy long more expensive trains? The speed limit does hardly matter when you look at the different sets, only a few basic (around 3 or 4 'groups' of roughly similar speeds) speed differences are given in the different sets and all these higher speeds are mostly introduced in the later dates of the sets. This, of course, with the exception for 1 or 2 higher speed express engines in each era.

[maquinista]

I have tested the latest version and It works good. The crossings are not loaded, but I remember that this is not implemented at the moment. The high speed depots was not drawn (I will use the default maglev depots, because I am not good drawing sprites) and the crossings are not loaded in the NFO code.

I have a question: Which are the ground sprites are used? It's possible to choose between empty ground sprites or the default railway sprites?

It could be interesting to place only tinny sprites over the default railways. For example, the rack or the electrified 3rd rail could be drawn in this way. This will allow to replace all railway sprites with an action A, maintaining a uniform aspect in all tracks. For example, You could load CS tracks and a GRF with electrified 3rd rail. The authors of these sets don't need to modify their sets to have compatibility with the other set.

Also, other sets like Transrapid tracks would work better with empty ground sprites.

This option (use empty ground/default tracks) could be switched with a new flag in property 10.

[peter1138]

I seem to have reverted too much on OpenTTD's wiki at some point. I fixed that yesterday, so the Action 3/2/1 stuff is again documented at http://wiki.openttd.org/Peter1138/Railtypes. Crossings are supported.

I have a rail types version of narrow gauge rails (made in 2008, heh) that is only missing the required tunnel graphics.

[NekoMaster]

Gah! Why can't I still find a build with new rail types? Is this official builds (stables, testing, nightlies) or is it a patch right now?

[Zephyris]

Try r19056 of trunk...

[FooBar]

I have everything working here, except that the maglev station is displayed incorrectly, see FS #3605.
EDIT: fixed in r19064. Thanks for the quick fix! /EDIT

Apart from that, compliments to you petern! Very good job on this great new feature!



While we're talking about stations, I have one suggestion regarding those...

How about adding a new 'cargo type' to provide graphics for the default station. Default rail types have their own different station graphics in the base graphics set, so why not allow track types to provide their default station graphics as well?
These graphics should not be mandatory. Property 12 should define if one of the stations from the base graphics is used, or that new sprites are provided (e.g. by setting property 12 to FF).

[NekoMaster]

I have everything working here, except that the maglev station is displayed incorrectly, see FS #3605.
EDIT: fixed in r19064. Thanks for the quick fix! /EDIT

Apart from that, compliments to you petern! Very good job on this great new feature!



While we're talking about stations, I have one suggestion regarding those...

How about adding a new 'cargo type' to provide graphics for the default station. Default rail types have their own different station graphics in the base graphics set, so why not allow track types to provide their default station graphics as well?
These graphics should not be mandatory. Property 12 should define if one of the stations from the base graphics is used, or that new sprites are provided (e.g. by setting property 12 to FF).

Well, Im not a grf coder nor a openttd dev. But one thing I know is that to do that would require to draw up a few sprites for each cargo type unless you simplify graphics (like People for Passengers, Bags for Mail and Valuables, Boxes\Crates\Containers for Goods and Food, Animals for Livestock, Barrels for Liquid cargos, and maybe bins or mineral loaders for mineral cargos like ores, coal, etc)

I wont say its a hard thing to do, its jsut that making at least enough sprites to please the masses might be a little time consuming

[Yexo]

How about adding a new 'cargo type' to provide graphics for the default station. Default rail types have their own different station graphics in the base graphics set, so why not allow track types to provide their default station graphics as well?
These graphics should not be mandatory. Property 12 should define if one of the stations from the base graphics is used, or that new sprites are provided (e.g. by setting property 12 to FF).

Well, Im not a grf coder nor a openttd dev. But one thing I know is that to do that would require to draw up a few sprites for each cargo type unless you simplify graphics (like People for Passengers, Bags for Mail and Valuables, Boxes\Crates\Containers for Goods and Food, Animals for Livestock, Barrels for Liquid cargos, and maybe bins or mineral loaders for mineral cargos like ores, coal, etc)

"Cargo type" is used here as an nfo "Cargo id", not as a type of cargo that you can transport.

[Zephyris]

NekoMaster, I think you have misunderstood. The "cargotype" FooBar is referring to is a technical detail of how the new rail grf is coded, it has absolutely nothing to do with cargos or cargo graphics!

*edit* Yexo beat me to it

You have to love the crazy jargon grf coding uses!

[NekoMaster]

I just tried the most recent nightly on the openttd page and I still dont get new rail types, even when adding sets for the rail type (metro tracks and 2cc set, Narrow Gauge and Serbian, High Speed Rails and Spanish Set) They just replace the old railtypes. Is there a advanced option I must mess with either in the game or in the config?

Edit : openttd r19061

[Yexo]

No, you have to wait for someone to release a newgrf that supports this new features. 'Old' newgrfs that previously replaced a railtype will still replace the same railtype.

[NekoMaster]

No, you have to wait for someone to release a newgrf that supports this new features. 'Old' newgrfs that previously replaced a railtype will still replace the same railtype.

Then how are others getting it to work? is it my imagenation? Someone had a train running on A rail with 3rd Rail along with regular around, and regular electrified rail along with the others like mag lev and normal rail

[planetmaker]

No, you have to wait for someone to release a newgrf that supports this new features. 'Old' newgrfs that previously replaced a railtype will still replace the same railtype.

Then how are others getting it to work? is it my imagenation? Someone had a train running on A rail with 3rd Rail along with regular around, and regular electrified rail along with the others like mag lev and normal rail

They know how to write newgrfs and more so, they DO write them. And they toy around with their private versions. Possibly testing stuff for newgrfs-to-come.

[Zephyris]

ie. There are now two ways to code a rail replacement in OpenTTD:
1. A simple graphics replacement (up till now all grfs had to use this)
2. A proper replacement (only just in trunk, AFAIK no released grfs yet use this)

[FooBar]

(only just in trunk, AFAIK no released grfs yet use this)

Check the flyspray link I posted earlier. Although not released, my TransRapid Track Set is available in the 'Railtypes' flavour for testing purposes. Note that it is glitchy as I just started mending the graphics.

[stevenh]

petern,

Slight documentation issue (or bug)... the level crossing lights sprites are actually TRACKX, TRACKY, NX, NY, EX, EY, WX, WY, SX, SY... as opposed to West before East as the wiki says.

And also, how do I stop them flashing I've used the Level Crossing Red/Maroon on the lights.. works fine, but they don't stop.
I thought there'd be 'static' lights, but you've only specified 10 sprites?

[planetmaker]

I thought there'd be 'static' lights, but you've only specified 10 sprites?

Flashing is a matter of the colour chosen. It flashes, if you use a colour index from the flash cycle. It's static, if you use a colour index which is not part of the animation palettes.

E.g. see http://dev.openttdcoop.org/documents/13 or http://wiki.ttdpatch.net/tiki-index.php ... oordinates
So I'd assume that two of the x and two of the y direction graphics should relate to the barred sprite which should use the animated palette, the other two shouldn't...
If it doesn't help, you can define two different sets of graphics for the level crossing and draw one or the other, deciding which to draw by using a varaction2 with var 42.

When it works, maybe document it in the wiki, which is what (http://wiki.openttd.org/Peter1138/Railtypes or http://wiki.ttdpatch.net/tiki-index.php?page=Action3).

Butt then I guess you know most or all of this.

[stevenh]

So I'd assume that two of the x and two of the y direction graphics should relate to the barred sprite which should use the animated palette, the other two shouldn't...

That's what I would've expected too... and you just made me re-read the doco again... but it still makes sense to me that there is an issue. The doc only specifies the 'flashing' lights. It needs to be duplicated for non-active sprites, or code-driven to stop the colour-cycle on them.

Unless... the 4 sprites are North-On, North-Off, W-On,W-Off, E-On,E-Off and S-On,S-Off..... as they shouldn't really change position based on activity.
And therefore that table makes little sense as 'X' and 'Y' only really apply to the track sprite.

edit: this is not the case... it is infact 4 lights per tile for both directions... no method that i'm aware of to turn them off

[planetmaker]

I just had a chat with petern.

The four sprites for each direction are the signals on the road sides as shown in the attached image. You need the varaction2 in order to differentiate between open and closed state of the level crossing.

I guess the NewGRF wiki needs some adjustment in this respect.

[Zephyris]

It would be nice to be able to randomise rail sprites on a tile-by-tile basis to add variety to the tracks, would it be possible to add a varaction2 variable for position in the tile loop (or similar) to allow this?