Realistic turnaround
Moderator: OpenTTD Developers
-
- Engineer
- Posts: 18
- Joined: 04 Feb 2012 10:28
Realistic turnaround
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" )
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" )
Re: Realistic turnaround
If you have time to do it, nobody is going to tell you no!
Do you like drones, quadcopters & flying toys? Check out Drone Strike Force!
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | GarryG's Auz Sets
Base Music Sets: OpenMSX | Scott Joplin Anthology | Traditional Winter Holiday Music | Modern Motion Music
Other Projects: 2CC Trams | Modern Waypoints | Sprite Sandbox & NewGRF Releases | Ideabox | Town Names | Isle of Sodor Scenario | Random Sprite Repository
Misc Topics: My Screenshots | Forgotten NewGRFs | Unfinished Graphics Sets | Stats Shack | GarryG's Auz Sets
- nicfer
- Director
- Posts: 529
- Joined: 03 May 2005 20:50
- Location: Somewhere in a country called Argentina
Re: Realistic turnaround
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.
Sorry for my english I am argentinian
TTO don't crashes in Windows XP; XP crashes TTO
Formerly known as UnderBuilder.
MyMiniCity
TTO don't crashes in Windows XP; XP crashes TTO
Formerly known as UnderBuilder.
MyMiniCity
Re: Realistic turnaround
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).
-
- Engineer
- Posts: 18
- Joined: 04 Feb 2012 10:28
Re: Realistic turnaround
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:
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.
- 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.
- A train (one engine + at least one waggon) enters a station.
- 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:
- First, the train is split into two trains: old locomotive and the rest. For security reasons, both trains are being forced to stop.
- 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).
- Next, while the train gets a shunting order, the rest keeps its order. cargo can already leave and enter the train now.
- 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.
- The newly built train exits
- The virtual signal is being removed
- Attachments
-
- trains.png (11.44 KiB) Viewed 5977 times
Re: Realistic turnaround
i'm very sceptical about this
ok, first problem. what is "the locomotive"? what about trains with more than one locomotive? or with powered wagons?[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
second problem: what about NewGRF features which query the front engine, or position in consist, etc.?First, the train is split into two trains: old locomotive and the rest. For security reasons, both trains are being forced to stop
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.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).
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.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.
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, ...?The virtual signal is being removed
Re: Realistic turnaround
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.
Re: Realistic turnaround
there have been steam engines with push-pull support.
Re: Realistic turnaround
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.Re: Realistic turnaround
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
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
-
- Engineer
- Posts: 18
- Joined: 04 Feb 2012 10:28
Re: Realistic turnaround
Thanks for replying!
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).
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:ok, first problem. what is "the locomotive"? what about trains with more than one locomotive? or with powered wagons?
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:second problem: what about NewGRF features which query the front engine, or position in consist, etc.?First, the train is split into two trains: old locomotive and the rest. For security reasons, both trains are being forced to stop
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: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.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).
I don't know why it should not be doing what I want.Eddi wrote: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.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.
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).
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.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, ...?
Re: Realistic turnaround
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.
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.
don't worry, be happy and checkout my patches
-
- Engineer
- Posts: 35
- Joined: 18 Jun 2016 20:45
Re: Realistic turnaround
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.
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.
Re: Realistic turnaround
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
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
Re: Realistic turnaround
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
Sorry for my "great" English
Re: Realistic turnaround
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.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.
don't worry, be happy and checkout my patches
Who is online
Users browsing this forum: No registered users and 21 guests