Different Tracktypes

[Sonicus]

I know this was posted several times ago, but I want to start a completely new attempt on this.


What I want to do (short):

Implement different (rail)tracks, mainly electrified tracks, but also add a "slower" and a "faster" type of tracks.

What I´ve done so far:

I started to familiarise with the OpenTTD-Code (bad comments though ), added a new track-type 3 (electrified) and implemented a very basic "speedlimit" to every kind of track. Electrified engines are only capable of running on electrified tracks, diesel and steam, as expected, run on both. This is basicaly working, except graphics.


What I want to do (long ):

I still need to learn more about coding for OpenTTD, mainly I´m not familiarized how to make a diff, how to make a patch for Sourceforge. Maybe someone can give me a short introduction, or give a link to a tutorial?

What i´ve come along:
I need to make tracks available although no trains exist for these. Generaly, i just want to split engines to two types:
standard (0) and electrified (3) of the standard-type.

I planned to implement the following:
low speed tracks (just very early in the game, maybe 90-100km/h)
standard tracks (up to 140?)
fast tracks (up to 210)
high speed tracks (up to unlimited)
I don´t know if I should implement electrified for each type, or leave electrified for low speed, and make it mandatory for high speed? That would result in 5 new types including the existing one (1x LS, 2x STD, 2x FST, 1x HS)

Next, I will need to implement new graphics for the different railtracks. How can I simply add new sprites? Any hint for this?

Most important for me:
Will my work on this be wasted if the new map_array gets introduced?

Why do I want this?
For me most of the fun is creating a growing network, and then, year by year, have to tweak and improve it. Next, faster and better trains don´t cost much more in purchase, but think about the costs of a highspeedtrack which are not considered. Highspeedtracks are more than just tracks that go straight.


now, i hope somebody read it, although discussed in the past, i am willing to start coding, please give comments

[chairface]

There's already patches for electrified rails. I don't know if any are openttd compatible yet, nor how long til they're in a main release, but it's already out there. Likely be more productive to hook up with someone already working on something like that.

[peter1138]

Sonicus, Celestar (one of the developers) is already working on electric rails and, I understand, it is almost ready to use. That's not to say your work is wasted though Speed limits for different rail types (a la Simutrans) could be a nice feature, as long as construction costs for normal "unlimited" rail is more rather more expensive.

You'd be well advised to coordinate with the developers. They can generally be found on Freenode IRC in #openttd.

[Bjarni]

I moved this since it appears to fit better in the development forum. You should join the IRC channel as peter1138 said so we can avoid double work and wasted work

[mkxx]

WASTE_OF_WORK_WHEN_NEW_MAP_ARRAY: I think that this work will be more more easier to do when new map_array will be introduced. Your work wouldn't be wasted but you'll have to rewrite some of your functions which are currently acessing the map array.

ELECTRIFIED_RAILS: "They" are true. Why to do something, what does anyone other. (awww, I hate english language and english language hates me ;))

SPEEDLIMITS: Making patch for different railway speedlimits sounds very,very good for me. I suggest you to use 8high bits in map2-bits-8..12 (system of bits toggling is the same as map5-bits-0..5) (for ex. map2-bit8-true means that speedlimit is active for track in X direction (map5-bit0))
(hope that this is understanble for other people ;))
- why to use so many bits for basic speedlimit? simple answer: different tracks can have different speedlimits - for ex. slow-speed electrified rail crosses full-speed normal rail (you understand now?)
- when new_map_array will be introducted, you'll not be limited with the size of current_map_array.

PATCHING: If you are using Micro€oft Window€ system, you should use TortoiseSVN - which also manages versions of openttd. And - create patch
On Linux - you'll need programs svn, diff (I hope I'm right).

[Sonicus]

@waste:

I think it´s worth the work, I just start coding. Even though I have to redo some work, I just can learn by coding.

@electrified:

I did not recognize somebody is already working on it. I`ll stop thinking about this then.

@speedlimits:

Is there any place I can have an overview to the used bits in the map? How many Bits in map2 can I use? 8 Bits?

If I need 5 Bits just for directions I just could code two different speedlimits (standard + 1), Bit set or not, for more types I need 2 Bits for each (or any idea how to do?)

Another idea:
I think it´s not necessary to differ between all possible combinations, on a junction, for example, with a merging track, the higher speedlimit is used. I will need to differ for two diagonal tracks not connected, though.

Code: Select all

-----   -----   -----
|/  |   |/  |   |_|_|
|  /|   |\  |   | | |
-----   -----   -----
=> store for each track-part (upper/lower or horz/vert)

-----
| | |
| |\|   ...
-----
=> just higher value

maybe just differ the not-connected tracks, as soon as there is a junction involved (more than 2 Bits of track) everything .. ?

[edit]

I just came along this:

Code: Select all

enum  	RailTileSubtypes { RAIL_SUBTYPE_DEPOT = 0x00, RAIL_SUBTYPE_WAYPOINT = 0x04, RAIL_SUBTYPE_MASK = 0x3C }
 	These subtypes are used in the map5 byte when the main rail type is RAIL_TYPE_DEPOT_WAYPOINT. 

could this be used to store the speedlimit-type, when no Depot is involved? If i read correctly 4 Bits are used here to distinguish between just two states at the moment ..

[Bjarni]

a new map array should contain space used for speed limits. Adding it to the current one is really tricky, if it is even possible. Placing different types of signals in one tile is currently impossible due to lack of mem assigned to each tile. Try to make one presignal and one normal signal in the same tile.... you can't

[gkirilov]

The idea sounds great but there is always one BUT .
Now imagine you build a HUGE network with trains from 1920 to 1950 .. then the new rail type comes out. And then you have to change ALL the tracks. They are relatively easy to change now. But if you have a REALLY big newtwork it becomes a bit of an unpleasant job to do (just imagine 2kx2k map).A button which "replaces all railways to a certain type" would be more than appropriate here. This can be possible only after all trains are in depots - also a good idea for a button to have - "send all trains to depots".

I am not even going to start on how you have to replace every single train. This is just crazy.
I think these are the issues that you first have to work on before introducing other great features.

[Sonicus]

My idea with this is not to make new tracktypes and new trains. You wont have to update the trains, as they are usual trains running on rail.

The speedlimit should be stored elsewhere in the map, as said I try map2 at the moment. I think I could insert a function to upgrade all tracks from one type to another..

[Julz]

it would be nice to know how much of an engine's power a train was using at any one time. - A little percentage bar somewhere on the train-window, for instance.

E.g. A train accelerating out of a station: 100%

A train decelerating into a station: 0%

A train travelling with a medium load at full speed: 80%

A train travelling very slowly uphill: 100%

A train going over a wooden bridge: 10%

A high-speed train going over low-speed tracks: 60%

etc.


This would help when choosing engine power in the current game - and would REALLY help if there are lots of different rail types.

[Bjarni]

Julz: yeah, that would be interesting and it actually gave me an idea. Low cost tracks are known as low speed tracks, not because they can't handle high speed, but because they can't handle the force applied to the tracks at high speed (ok, as a result of that, they save money on doing other stuff that prevents high speed, like poor road crossings). Since the force is the factor that there is a max force on each axle, so one engine accelerating with a freighttrain can't always apply 100% power while a DMU got low force on each axle, but it pulls on way more axles (specially if it is a long DMU) so it is allowed a higher total force. This is one of the reasons why real railroads sometimes pick two 3300 HP engines instead of one 6600 HP one

Note: don't read this as it is ok to go 160 on a max 120 track if you accelerates slowly. It is not meant like that, but I do know of a place where EMUs are allowed a higher max speed because they even out the force applied to the tracks and got lower weight on each axle

[Sonicus]

Maybe i just could alter the UpdateTrainSpeed, too.
Depending on the max speed for the track and some parameters from the train do a new calc for the speed that is possible. For example, add an extra "max weight per axles" next to speed, so heavy locos can´t reach full speed.

I will think of this as soon as i´ve done "basics"

[Bjarni]

Maybe i just could alter the UpdateTrainSpeed, too.
Depending on the max speed for the track and some parameters from the train do a new calc for the speed that is possible. For example, add an extra "max weight per axles" next to speed, so heavy locos can´t reach full speed.

I will think of this as soon as i´ve done "basics"

I'm a little scared that you do a lot of work and that it will end up as being useless because it fights against other patches and stuff. Please show up in the IRC channel

[mkxx]

@MY_LAST_POST: I am sorry, there was a mistake, i wrote that you can use for speedlimits 8bits in map2 (bits 8..12) -> I meaned 6bits in map2 (one for each direction) (bits 8..13 :)).
I think that storing one bit for each track (6tracks on tile) is the most clearest way, how to implement it. Storing extra arrays with bitmasks of non-crossing track layouts for the tile sounds little bit crazy.

@WHERE_TO_FIND_INFO_ABOUT_MAP:
Look into directory "docs" in the source code dir (try svn.openttd.org -> /trunk/docs/ -> landscape.html, landscape_grid.html if you can't find it)

@uPDATEtRAINsPEED: I was thinking about speed limits one time before (cause of pic on my avatar (My dream is to implement yellow signals and trains slowing down in yellow-signal-blocks)).
The most clearest way is to make new function like
int DetermineMaxSpeedLimit(Vehicle *v) {...} which returns max. available speed for train on current tile (bridge speedlimit,yellow signal block speed limit,low-speed track speed limit).
If you look into tunnelbridge.c for speedlimits on bridges - There is very "pretty" hackish way to use speed limit for train.

[Sonicus]

I would have shown up in IRC, but i have to quit now till evening..

I faced some problems, like speedlimit on road-rail-crossings does not work. I don´t know yet if i´ll continue right now as there is the new map_array coming up. I´ll just stop thinking of a "real" solution for the old ottd and face the upcoming map_array:

I read in description of this new array and noticed no bits are left for something like track-speed.
We could make them tracktypes, but only 4 bit = 16 types are available, thinking of 6 types (LS, STD, HS, VHS, STD + HS with/without electrified, LS always without, VHS always with)

Code: Select all

      elec.     |
    | w/o |  w  | limit (km/h)
--------------------
LS  |  X  |     | 80
STD |  X  |  X  | 140
HS  |  X  |  X  | 210
VHS |     |  X  | unl.

leaves 10 types for things like monorail, maglev, tram, etc. .. In this case compatible railtypes should be made flexible enough to allow trains to run on different tracks. Problems with different speedlimits on different parts would not exist, as there are two track_infos in the structure.

I`ll show up on IRC in the next days, i hope we can find a way to combine this with electrified railtracks

[Ghost]

Maybe this is not the right topic for this message, however, I'd like to propose the following idea. When trains approach stations they slow down not instantly but during some time. However, when they approach a red signal they seem to stop instantly. What about realistic slow down at semaphors? E.g., when a train approaches a red semaphor at high speed it slowes down but goes further until the next red semaphor... Something like that.

[Sonicus]

This early slowing down could be implemented the way mkxx wanted, by adding "real" presignals, which turn yellow if the next signal is red.
Maybe it should be reconsidered adding this type of signal? Was it already discussed in this forum? (i´ll start searching for the topic)

[mkxx]

@UN/REALISTIC_SLOWING_DOWN (Ghost):
"when a train approaches a red semaphor at high speed it slowes down but goes further until the next red semaphor"
That's impossible. Red signal means STOP. Maybe we should implement something like this:
$n := minimal distance which train needs to slow down from actual speed to 0.
Every "TrainTick" we look for red signal in $n distance train. If present, we start to slow down.
We are slowing down - still we look (every "TrainTick") for red signal in $n distance (Note that $n changes every time - it depends on actual_speed) - if red had changed to green, we start to accelerate.
-> it would need more CPU usage, I think, because train needs to know the next way on every_next_tick. (on every tick we use some NPF(?) func to determine next tiles in $n distance)

@YELLOW_SIGNALS (Sonicus):
Yellow signals do not resolve the problem, what Ghost described. They only tell - the train can enter into block with maximal speed $speed.
The system what I've described above (realistic_slowing_down) should work here too. If not, the train slows down in big steps (270->80->0). First step - whe it enters yellow signal, next step when it enters green signal.
But I'm afraid - yellow signals can't work with your track_speedlimits :o) (cause the need MORE bits in map array (4bits in map2 ;)) ))

@ROAD_CROSSINGS_SPEED_LIMITS (Sonicus): look into landscape_grid.html and landscape.html files (in source_code_dir/docs) -> You can't apply this to road-rail crossings, cause there are no free bits in map_array for that. I'm afraid that the same for bridges and tunnels (if you like non-hackish ways) :)

[lucaspiller]

Maybe this is not the right topic for this message, however, I'd like to propose the following idea. When trains approach stations they slow down not instantly but during some time. However, when they approach a red signal they seem to stop instantly. What about realistic slow down at semaphors? E.g., when a train approaches a red semaphor at high speed it slowes down but goes further until the next red semaphor... Something like that.

Turn on realistic acceleration, build a long platform, and voila!

[thepizzaking]

I'd like to see something like what they have in simutrans, where first you build the train track, and then there's an option to electrify the rails instead of having a whole new track type for them.