Signals and Switches
Moderator: Transport Empire Moderators
Signals and Switches
Scenario:
Imagine a high speed train (300km/hr) which approaches a set of signals which indicate that its to switch to another line away from the main line. The vehicle knows (through signage) it needs to slow down to say 50km/hr due to the geometry of the switch. We will then need to ensure there is enough space for the train to slow down.
• Should this be automatic? (As in the signals be placed at such a distance to make the above scenario possible, but then what should the speed be to then depend on where the signal is to be placed?)
• Should a warning appear in the construction phase. (Warning – max speed for trains to slow down at switch is 100km/hr)
• Should the track default to a speed limit which would allow all trains to safely switch but also affect the main line because we can’t be certain what they might do?
• Should the trains automatically know that they are heading to a switch and then slow down accordingly?
These have perhaps already been discussed but...
Do individual tracks have speed limits (based on geometry, track quality, etc), or do the vehicles automatically known how fast they should be going.
Can we modify this limit for our own meddling? (Could cause accidents, would this be too annoying, fiddly? Advanced feature to tweak our networks, with the default being a tad on the conservative side)
Should the signalling be the indicator to change to a different line?
What exactly do we want signalling to be? Will it be more than just train in next block, STOP!
Of course you say, so what else?
TT Solutions: Approach switch at 300km/hr and make a 45 degree turn automagically slowing down the instace the direction change is made.
Automagically stop in an instace at a red signal.
Imagine a high speed train (300km/hr) which approaches a set of signals which indicate that its to switch to another line away from the main line. The vehicle knows (through signage) it needs to slow down to say 50km/hr due to the geometry of the switch. We will then need to ensure there is enough space for the train to slow down.
• Should this be automatic? (As in the signals be placed at such a distance to make the above scenario possible, but then what should the speed be to then depend on where the signal is to be placed?)
• Should a warning appear in the construction phase. (Warning – max speed for trains to slow down at switch is 100km/hr)
• Should the track default to a speed limit which would allow all trains to safely switch but also affect the main line because we can’t be certain what they might do?
• Should the trains automatically know that they are heading to a switch and then slow down accordingly?
These have perhaps already been discussed but...
Do individual tracks have speed limits (based on geometry, track quality, etc), or do the vehicles automatically known how fast they should be going.
Can we modify this limit for our own meddling? (Could cause accidents, would this be too annoying, fiddly? Advanced feature to tweak our networks, with the default being a tad on the conservative side)
Should the signalling be the indicator to change to a different line?
What exactly do we want signalling to be? Will it be more than just train in next block, STOP!
Of course you say, so what else?
TT Solutions: Approach switch at 300km/hr and make a 45 degree turn automagically slowing down the instace the direction change is made.
Automagically stop in an instace at a red signal.
- uzurpator
- Transport Empire Moderator
- Posts: 2178
- Joined: 10 Jan 2003 12:21
- Location: Katowice, Poland
Trains traveling at 300km/h don't have signals to obey. They are computer controlled.
So - ofc it is to be automated. Each train will have a "lookahead" equal to its braking distance.
So - ofc it is to be automated. Each train will have a "lookahead" equal to its braking distance.
All art and vehicle stats I authored for TT and derivatives are as of now PUBLIC DOMAIN! Use as you see fit
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
Just say NO to the TT fan-art sprite licensing madness. Public domain your art as well.
That's not correct. uzurpator. They do have signals to obey but those signals are projected on a screen in the cabine. Instead of signals you have beacons along the track that transmit radio signals which are translated to a "signal setting".
We did discuss track qualities in the DD, there should be different qualities due to weight of the rail and type of sleepers. We never actually thought about High Speed Trains and signals though and I must say I'm thrilled with what you write. Signals need a thoroughly different approach though, indifferent of the train speed. If we want to make a realistic use of signals we have to use pre-warning signal functionality. In the real world a signal can show 3 colours: green, orange and red. These 3 colours all have a very distinct meaning:
We did discuss track qualities in the DD, there should be different qualities due to weight of the rail and type of sleepers. We never actually thought about High Speed Trains and signals though and I must say I'm thrilled with what you write. Signals need a thoroughly different approach though, indifferent of the train speed. If we want to make a realistic use of signals we have to use pre-warning signal functionality. In the real world a signal can show 3 colours: green, orange and red. These 3 colours all have a very distinct meaning:
- RED: this signal block is occupied by another train, don't enter the block
ORANGE: the signal block after this signal block is occupied; expect the next signal to be red and start slowing down
GREEN: the signal block after this signal block is free; expect a green signal and proceed at the allowed speed
I think slowing down in TE should be very much automatic.
I don't agree with all the sleep types, so I think we should base maximum speed on curviture alone. Makes sense, right?
Too fiddly to alter max speed yourself.
What Hyr says it all well and good, except if TTD is anything to go by, people put lots and lots of signals down in order to maximise the trains on a route, so waiting for an orange signal may be too late!
Instead, I propose a system whereby a train knows how long it takes to slow down, it looks a little further ahead than this and if it finds an occupied block, it slows down. Some sort of fancy speed system needs to then let it cruise along, perhaps checking how far away the train is in front, if the same distance, it cruises at the same speed, if it's getting away, the train will speed up.
Or just match the speed of the vehicle infront, but hopefully this won't clash with signals.
With signalling, my big idea is a Give Way signal. For example, if you have a main line and a side route joins onto it, rather than let a train on the side route move onto the main line and force another train to slow down, it will instead slow down as it approaches the Give Way signal and if the way is blocked, stop, if the way is clear, speed up and go on as before. If you can drive, think of how you handle a roundabout, you slow to check if it's clear and you'll be at a speed so you're prepared to handle with either situation.
I don't agree with all the sleep types, so I think we should base maximum speed on curviture alone. Makes sense, right?
Too fiddly to alter max speed yourself.
What Hyr says it all well and good, except if TTD is anything to go by, people put lots and lots of signals down in order to maximise the trains on a route, so waiting for an orange signal may be too late!
Instead, I propose a system whereby a train knows how long it takes to slow down, it looks a little further ahead than this and if it finds an occupied block, it slows down. Some sort of fancy speed system needs to then let it cruise along, perhaps checking how far away the train is in front, if the same distance, it cruises at the same speed, if it's getting away, the train will speed up.
Or just match the speed of the vehicle infront, but hopefully this won't clash with signals.
With signalling, my big idea is a Give Way signal. For example, if you have a main line and a side route joins onto it, rather than let a train on the side route move onto the main line and force another train to slow down, it will instead slow down as it approaches the Give Way signal and if the way is blocked, stop, if the way is clear, speed up and go on as before. If you can drive, think of how you handle a roundabout, you slow to check if it's clear and you'll be at a speed so you're prepared to handle with either situation.
Can't we have signals plan a few tiles/signals ahead (like LoMo does) so trains can reserve a switch so another train can get in front of it and causing it to slow down. This could make some kind of priority signals.
Presignals are also very usefull in big networks, #openttdcoop for example couldnt even exist without presignals because of the huge amount of stations and big junctions and for the load balancing, which could be done by the pathfinder too.
Presignals are also very usefull in big networks, #openttdcoop for example couldnt even exist without presignals because of the huge amount of stations and big junctions and for the load balancing, which could be done by the pathfinder too.
Don't panic - My YouTube channel - Follow me on twitter (@XeryusTC) - Play Tribes: Ascend - Tired of Dropbox? Try SpiderOak (use this link and we both get 1GB extra space)
OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone
OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone
This is a "cheat" caused by the way TTD handles signals. Its not very realistic and should be discouraged (in my opinion). Two ways to combat this include making the price of signals and signal maintanence too high (for a hundred as opposed to ten) or by using "gradualslowing".Steve wrote:What Hyr says it all well and good, except if TTD is anything to go by, people put lots and lots of signals down in order to maximise the trains on a route, so waiting for an orange signal may be too late!
There is also the question of era specific signalling...
Some good articles can be found in Wikipedia.
http://en.wikipedia.org/wiki/Train_signals
http://en.wikipedia.org/wiki/Train_order_station
Im a LoMo slowmo, so I don't get your example sorry. Could you visualise this or provide some screenshots?XeryusTC wrote:Can't we have signals plan a few tiles/signals ahead (like LoMo does) so trains can reserve a switch so another train can get in front of it and causing it to slow down. This could make some kind of priority signals.
Presignals are also very usefull in big networks, #openttdcoop for example couldnt even exist without presignals because of the huge amount of stations and big junctions and for the load balancing, which could be done by the pathfinder too.
PBS is a given, although I'm hoping the implementation in TE will be more straight forward than TTD. (Perhaps automatically defaulting to presignals, or just smarter signals)
I considering the following (and somehow forgot to post it):
For each section of track (not sure how big a section would be), it has a field for the internal time that the next train will pass it. These would be set as a train passes down a line, settings the sections ahead of it. These times would be the best estimate, so the train could be slowed down by junctions and breakdowns. So after the train exits a junction, it'd need to be refreshed.
Once you have this, when a train is looking to join a main line, it can see when the next train is planned on that line and therefore decide if it needs to slow down and wait.
In my opinion this is the easiest method to solve the problem, but you need extra memory for all these track sections, I'm not sure if you could cram it in a single byte per section or you'd need two.
For each section of track (not sure how big a section would be), it has a field for the internal time that the next train will pass it. These would be set as a train passes down a line, settings the sections ahead of it. These times would be the best estimate, so the train could be slowed down by junctions and breakdowns. So after the train exits a junction, it'd need to be refreshed.
Once you have this, when a train is looking to join a main line, it can see when the next train is planned on that line and therefore decide if it needs to slow down and wait.
In my opinion this is the easiest method to solve the problem, but you need extra memory for all these track sections, I'm not sure if you could cram it in a single byte per section or you'd need two.
Here is a real life example (which I have been a apart of) which may not be practical but is a thought experiment nonetheless.
Train A - suburban express service which runs from the main line
Train B - suburban service stopping all stations which originates from a spur line
Train C - contry service which runs express through the suburban main line
I was on Train B, when the train came to a stop before it was due to merge onto the main line.
The driver informed us that "we have to wait for our slot".
Train A passes by.
Still waiting....
Train C passes by.
Wait a little bit..
Continue slowly thought yellow lights, then speed up through green.
Although Train B was the first one there, had it joined the main line, it would have held up the other two trains.
Train B could have slotted in between Train A and C under a yellow light, but again, this would have upset the expressness of the C train.
Path and priority signalling? Slots?
Where's the fat controller when you need him...
Train A - suburban express service which runs from the main line
Train B - suburban service stopping all stations which originates from a spur line
Train C - contry service which runs express through the suburban main line
I was on Train B, when the train came to a stop before it was due to merge onto the main line.
The driver informed us that "we have to wait for our slot".
Train A passes by.
Still waiting....
Train C passes by.
Wait a little bit..
Continue slowly thought yellow lights, then speed up through green.
Although Train B was the first one there, had it joined the main line, it would have held up the other two trains.
Train B could have slotted in between Train A and C under a yellow light, but again, this would have upset the expressness of the C train.
Path and priority signalling? Slots?
Where's the fat controller when you need him...
Unless you had the following situation I think its quite logical which one is the main line, and which one is a spur. (Which one is the straight one?)
Of course we could disallow that and only allow this
Code: Select all
\ /
\ /
\ /
\ /
\ /
\ /
\ /
|
|
|
|
|
Code: Select all
\ / spur
\ /
\ /
\ /
\ /
main \ /
|/
|
|
|
|
|
If I return to your example on Train A, B and C then there isn't a signal that gives right of way to faster trains. It was a human decision by the control room to keep Train B waiting, not an automated decision.aarona wrote:Yes, but I think it should be the job of the signals to represent the priority of the trains. Hence you have priority signalling...right?
Or did you have something else in mind?
Giving way to express trains on section of track where a main line and a spur join could possibily be done by letting signals check what types of train are approaching it.
Imagine 2 signals: signal S1 on the main line and signal S2 on the spur. Both signals are identical. If a commuter train is approaching signal S2 then signal S2 should "consult" signal S1 to see if a train with a higher priority than the commuter train is approaching signal S1. If that is the case Signal S1 "informs" signal S2 that a train with a higher priority is en-route and that signal S2 should remain red until that train with a higher priority has passed signal S1.
Who is online
Users browsing this forum: No registered users and 2 guests