Transport Tycoon Forums

Hi,

I'm looking for a way to simulate turnaround behaviour for trains. The main idea is that it's very unrealistic that trains are reversed like they are currently.

Before you think it's too much work to do it - I'd have time

Solution 1:

Two-ended trains are allowed to drive into the opposite direction in stations. However, their waggons should not be reversed, like it's currently the case.

One-ended trains reverse like it's currently done, but there's a penalty. If you spend the effort to buy two engines, you should have an advantage IMO.

Solution 2:

Two-ended trains: Like solution 1.

One-ended trains can drive backwards, but not with more than 30 mph. This is a form of shunting (German: "Rangieren"). Someone is standing at the non-locomotive-end and communicating to the train driver. A shunting train can not take any passengers (for safety reasons). It has to shunt out of the station and try to somehow return to it, but in reverse order. This is usually done with a depot.

Solution 3:

This is crazy, but the result would be fun to look at.

Two-ended trains: Like solution 1.

One-ended trains can decouple their locomotives. If a train shall reverse in a through station, the locomotive can decouple and drive to the other end. Alternatively, another locomotive might pick up the waggons and pull them into the reverse direction. This is very realistic and typically done in dead-end stations. It requires to have a locomotive waiting in the depot.

Edit: Just found this thread where there was an attempt to enable shunting.

All in all:

Solution 1 looks very easy to do. Solution 2 would be more complicated. Solution 3 would require to allow waggons being shared by different locomotives; I guess this would be very hard to do.

Please share your thoughts, or ask me in IRC ( nick "_johannes" )

If you have time to do it, nobody is going to tell you no!

I'd go for option 1, as it's very straightforward and fits the "not absolutely realistic" meta of this game. As penalty, I'd choose to force the train to wait an extra time, and also the track require the extremes being accessible, as the loco would use if it had to situate on the other extreme, and also require the path to not be blocked by other trains when the turnaround is on course. Can be a bit more confusing as why does it require more tracks if the loco doesn't move, but overall I think it's the best choice.

I really like solution 2, but I'd get rid of the no loading provisions (of course player could set orders to unload and leave empty). I'd have it apply to any time a train reverses. You could also add an order to "reverse to" so a train could be directed to reverse out of a depot into the station ready to pull forward to proceed to next destination. I'd have any train currently executing a "go to" order in reverse automatically choose to go into an depot it may come across adjacent to its path to turn around (would not apply to train executing "reverse to" order).

After thinking a while about it, I'd like to implement (3), making (2) optional.

I've made a plan on how to implement turnaround by putting a locomotive on the other train's end (which I will call "shunting"). Can some developpers please check it and tell me if there are any problems?

Many thanks.

---

Plan:

There is a new order type "shunting". Trains that use this order type only consist of a locomotive and have no other orders in their order list.

Locomotives with the "shunting" order type always do one of the following:

• if they are assigned to the end of a locomotive-less train, they target this end
• otherwise, they target the next train depot for maintenance.

There is a competitioning algorithm for how shunting trains get assigned to locomotive-less trains.

• First, all shunting locomotives that are close enough (this must be specified yet) are being considered
• one of the trains with the shortest distance (using YAPF) is selected.

Now how does changing locomotives work?

1. A train (one engine + at least one waggon) enters a station.
2. If the train can not advance in the current direction (e.g. in case of a headless station), or if a turnaround would cost much less than keeping driving into the same direction, the locomotive decouples:
   1. First, the train is split into two trains: old locomotive and the rest. For security reasons, both trains are being forced to stop.
   2. A non-visible signal is being placed between the train and the rest. It's a one way signal forbidding to reach the rest coming from the train's direction (see appended picture).
   3. Next, while the train gets a shunting order, the rest keeps its order. cargo can already leave and enter the train now.
   4. On the non-locomotive-end of the train, a competitioning algorithm for shunting trains is being started. Once any shunting train wins, it targets to the YAPF-node where the rest stands. Due to the virtual one-way signal this is only reachable via the none-locomotive-end of the rest (see appended picture). Once the shunting locomotive reaches this end, it gets connected to the rest.
   5. The newly built train exits
   6. The virtual signal is being removed

i'm very sceptical about this

[OpenTTD]Johannes wrote:If the train can not advance in the current direction (e.g. in case of a headless station), or if a turnaround would cost much less than keeping driving into the same direction, the locomotive decouples

ok, first problem. what is "the locomotive"? what about trains with more than one locomotive? or with powered wagons?

First, the train is split into two trains: old locomotive and the rest. For security reasons, both trains are being forced to stop

second problem: what about NewGRF features which query the front engine, or position in consist, etc.?

A non-visible signal is being placed between the train and the rest. It's a one way signal forbidding to reach the rest coming from the train's direction (see appended picture).

third problem: "signals" only can appear at very specific points on the tile, a train has many more positions to choose from, so "between engine and wagons" is not really an option.

On the non-locomotive-end of the train, a competitioning algorithm for shunting trains is being started. Once any shunting train wins, it targets to the YAPF-node where the rest stands. Due to the virtual one-way signal this is only reachable via the none-locomotive-end of the rest (see appended picture). Once the shunting locomotive reaches this end, it gets connected to the rest.

this is the biggest problem. there is too much AI mumbo jumbo involved, which means for any situation more complex than one train you're constantly battling this opaque algorithm which never does what you want. it's like autoseparation. on speed.

The virtual signal is being removed

ok, "last" problem, but what happens to the signal if the shunting process is interrupted by anything? e.g. sending trains to depot, rebuilding tracks, UFOs, ...?

If possible, it would be a good idea to implement passing loops at stations so that locomotives can run around their train or alternatively, a new DVT carriage could be implemented to stop the need for running round to take place. This, of course, would only work for passenger or mail diesels and electrics.

there have been steam engines with push-pull support.

The easy way is to build a rail-system similar to this: An other one is to use a Rail Set with push-and-pull trains. I know only the SBB Set (swiss trains), or use an another if there are more Rail Sets with push-and-pull.

You beat me to it. Push and pull literally accomplishes everything you are looking for graphically.

BRTrains will also feature plenty of push and pull trains, im just trying to tweak the code so that it always shows red lights on the last carriage and white on the front if its a DMU/EMU

Thanks for replying!

Eddi wrote:ok, first problem. what is "the locomotive"? what about trains with more than one locomotive? or with powered wagons?

If there are only locomotives at the head of the train, they all count as one locomotive for the algorithm. Other special cases like powered wagons could be excluded as long as we're not sure how to handle them.

Eddi wrote:

First, the train is split into two trains: old locomotive and the rest. For security reasons, both trains are being forced to stop

second problem: what about NewGRF features which query the front engine, or position in consist, etc.?

One would need to check all of the NewGRF features. If there are any, one would need to forbid the turnaround for savegames having these features. Or just change the way how "querying the front engine" works. This is a difficult problem...

Eddi wrote:

A non-visible signal is being placed between the train and the rest. It's a one way signal forbidding to reach the rest coming from the train's direction (see appended picture).

third problem: "signals" only can appear at very specific points on the tile, a train has many more positions to choose from, so "between engine and wagons" is not really an option.

Good point. In this case, the signal would be placed at some part of the station where the rest of the train (the wagons) stand. That way, the signal can not be removed in any way (since there are still wagons on the tile). The only intent of the signal is to let locomotives approach from the correct side. So i'd just let the train head for the tile where the virtual signal stands. This should work.

Eddi wrote:

On the non-locomotive-end of the train, a competitioning algorithm for shunting trains is being started. Once any shunting train wins, it targets to the YAPF-node where the rest stands. Due to the virtual one-way signal this is only reachable via the none-locomotive-end of the rest (see appended picture). Once the shunting locomotive reaches this end, it gets connected to the rest.

this is the biggest problem. there is too much AI mumbo jumbo involved, which means for any situation more complex than one train you're constantly battling this opaque algorithm which never does what you want. it's like autoseparation. on speed.

I don't know why it should not be doing what I want.
For the overhead, IIRC, YAPF is being called for every train at approximately every railroad switch, so if you have 500 trains, it may be called 50 times a second. The competitioning algorithm would be called only in a few locations, and I guess it would not cause more than 10 YAPF calls (one could even abort if after ten locomotives none is suited).

Eddi wrote:ok, "last" problem, but what happens to the signal if the shunting process is interrupted by anything? e.g. sending trains to depot, rebuilding tracks, UFOs, ...?

If you send the locomotive that's currently heading for the train to depot, I guess it should just keep the shunting order (plus the information to which train it is heading), like normal trains keep their orders when being sent to depot. Not sure how anything else could harm... As long as the information "a locomotive is needed here" is being stored, changing track layout won't destroy this information. If you delete a shunting train, the competitioning algorithm for its target tile must run again.

This is a nice idea. I was wondering earlier if this could bring some extra fun. However, I would not go that far (shunting etc. ) but make it more simply:

1) Minimal, basic rule - penalize train turning around. This could be like (maybe configurable?):
- disallow turning around (train just stops and has to be manually reversed maybe?)
- penalize turning around by some extra time

2) Additional rules (this might be a little tricky):
- create a definition of a two-way train
- two-way trains are not penalized by turning around, they actually don't turn around, they can just go in reverse
- give a visual impression of not-turning around but actually reversing e.g. arrange wagons in reverse order and notify GRF about the fact

As of NewGRF compatibility, trains not flagged as two-way would be simply treated as non-two-way. The hardest will be to not turn around but reverse a two-way train. Hard but doable IMO.

I think this would be a great improvement and one I've thought about for ages.

I realise you can turn off reversing but is this accurate? Do some trains have no reverse gear? I always thought they just changed gear and pushed instead of pulled but maybe there should be a speed penalty for this as drivers wouldn't be able to see the signals before telecoms.

If you could get pushing trains and make double ended engines the requirement (with carriages keeping their order) I think it would be much more in depth as currently the train just magically turn around in stations and it does look a little bit hokey.

almost all engines are capable of going in both directions at the same speed, except for some steam engines with a separate tender, which usually have severely limited speed if pushing the tender. that's why steam engines relied on turntables a lot.

also some high-speed train sets have a speed limit if they only have a light steering wagon in the front instead of a heavy engine

[+] Spoiler

Wikipedia says this about reversing at terminus stations
- There are several ways in which this can be accomplished:

1. arranging for the service to be provided by a multiple-unit or push-pull train, both of which are capable of operating in either direction; the driver simply walks to the other end of the train and takes control from the other cab; this is increasingly the normal method in Europe;
2. by detaching the locomotive which brought the train into the station and then either
2.1. using another track to "run it around" to the other end of the train, to which it then re-attaches;
2.2. attaching a second locomotive to the outbound end of the train; or
3. by the use of a "wye", a roughly triangular arrangement of track and switches (points) where a train can reverse direction and back into the terminal.

I have ideas how to realise 2. and 1., but I think 2.1. and 3. are useless(unless you're making scenario with real stations), because it's easier and profitable to build Ro-Ro, and also they would take a lot of time with current scale and proportions

Hattyfatner wrote:I realise you can turn off reversing but is this accurate? Do some trains have no reverse gear? I always thought they just changed gear and pushed instead of pulled but maybe there should be a speed penalty for this as drivers wouldn't be able to see the signals before telecoms.

I have been thinking about this too but probably it's too hard to implement. The pathfinder doesn't take into account speed limits currently. Adding this would mean changing a lot in already hard and complex code.