Hey there,
I love the wide diversity of working methods and the wide diversity of signals within these methods.
Especially for historical working methods, I didn't even know these existed.
However, I would call some of them not pretty well designed assuming they should work close to reality.
In this thread I will collect all thes things and I will share my ideas about how we could improve these.
I want to explicitly say that I don't want to call the whole signaling system bad, it's really awesome, but apart from bugs, there are some details that are not perfect by design.
Sighting:I really love the idea of this feature!
However, I don't think it is pretty well designed for multiple reasons:
1. Inconsistency between diagonals and straights:
When a train travels along a long straight, it can see to the last tile in that direction, which is graphically already a diagonal.
When a train travels along a diagonal, it can see to the last tile that is graphically a diagonal, but the last tile in that direction would be first tile of the straight.
Given there are only 8 directions in Simutrans and there are no real curves, i would expect trains to see at least everything at a straight in moving direction until some given max sighting distance.
In the case of diagonals, this means the train should be able to see that first graphically straight tile behind the diagonal since it is still on that line.
Also, for slopes, a train should be able to see a raising slope, when it is on a flat track and the flat track, when it is on a falling slope. Don't forget about raising slopes immediately after a falling one.
1. Inconsistent behavior of sighting at diagonals:
Not quite sure if this is a bug or I just don't understand how it was designed, however, such an essential feature should be easy to understand. If this is a bug, please let me know, so I will create a bug report.
Sometimes a train will look ahead to the last tile that is graphically a diagonal, sometimes it will look ahead to first tile behind that diagonal and sometimes it will not look ahead at all.
What I would expect is not that important because I would suggest suggest some different behavior in later points but for completeness, here is what I would expect of the current sighting system:
A train should always look ahead to the last tile that can be seen in the current travel direction (for sure limited by max_sighting_distance), that means always the first tile behind the current straight or diagonal.
Furthermore, when entering that first tile of the next diagonal or straight, it should be able to look ahead to its end again. Currently it seems that a train will start to look in a new direction when it leaves its reservation.
2. Corners are handled as corners but this is not consistent to curve speeds in simutrans-extended, which does some kind of curvature radius approximation from corners.
In reality it is not a problem to see ahead a few kilometers when the curve radius is high enough. The lower the curvature radius, the shorter you can see.
My idea about sighting distance is to couple it to the curvature radius, for sure never being larger than some max_sighting_distance.
3. Slopes:
Currently, when the slope changes it is not possible to look ahead that point, however in reality it is possible to do so as long as the slope raises (e.g. going from downwards to flat or from flat to upwards)
I would expect it to act just like this.
Furthermore, when the gradient changes are low, it is still possible to look further than in case of a rapid gradient change.
Since I don't think we have a measure of gradient changes yet, I think implementing this would not be worth the work, or at least not as long as drive_by_sight does not really care about sighting distance anyway.
Emergency halt and emergencies:Currently, as far as I know, unexpected trains on the route, making an emergency halt necessary, can only happen in time_interval signalling mode. No matter how fast the train is, it will always come to a halt at only one tile and will always wait after the emergency halt.
My other ideas will create more situations in which emergency halts and emergencies can happen.
An emergency halt in reality would mean using sand or magnetic brakes (I don't know how exactly these are called in english).
In simutrans-extended it should greatly increase operating costs while it is braking but also increase brake force. By how much these are increased could be set up in the dat files by adding some emergency_brake_force value and some emergency_brake_cost value, additionally there should be some hardcoded default value in case the dat does not specify these.
When a train starts an emergency brake and comes to a halt without crashing, there will be no emergency, so the train can immediately continue its journey in drive_by_sight.
When it crashes into another train, it will have some waiting time before it can continue. How long depends on how fast the train was when it crashed.
This should simulate the fact that at low speeds there may be low damages to the train so the train can still move on its own or get pulled by an other train, while at very high speeds a crane is needed to move the train away from the track and the track needs to be repaired before operation can continue.
Blind people should never be employed as train drivers in Simutrans-extended:Tran drivers in simutrans-extended should always use their sighting distance to watch out for other trains on their route to brake down their trains if they can or start an emergency brake if they can't. Currently, this can only happen in drive_by_sight, where this is already properly handled and in time_interval mode, where train drivers won't even try to prevent an emergency when a train appears in sighting distance.
Train drivers not being blind will become more important with my further ideas about drive_by_sight and one_train_staff
The drive_by_sight working method:The most simple working method:
I really like it for its simplicity but sometimes it is too simple simulating blind, sometimes magic, idiots moving a train instead of train drivers.
1. Currently, a train will simply drive along its way, as long as at least one tile ahead is free.
This is fine, as long as everything is moving. When for example at the end of a completely double tracked line there is a junction and immediately after this junction is a head station with a train reversing in it, and the train moving towards that station can see the train in the station, it will simply continue until getting stucked in front of that train reversing in the station. Deadlocks can also occur when a train has to stop at a junction of a branching line.
My idea is that if a train can see another train on its route, and there is a junction somewhere in between these two trains, it will try to stop in front of that junction, waiting there until it can continue. If it can't brake quick enough, it will start an emergency halt. If it still can't brake quick enough it will simply come to a halt later.
For sure, considering its brake distance. If it can't stop in front of the junction, it will still block that junction, which simply means that the player did not install enough brake carriages to that train for that specific route.
If it can't see ahead of that junction, the train will still come to a halt at the junction, which is in this case a bad design of track.
I also want to mention that my suggested sighting_distance rework would also greatly improve this.
2. Apart from being blind, train drivers in Simutrans-extended also seem to be wizzards!
When a train in drive_by_sight crosses a track that is controlled by some other signalling system, for example absolute block, and there is a reservation of a train that is far-far away, the train driver operating in drive_by_sight will magically know about this reservation and wait until that train has passed.
What I suggest is that some types of operation modes will not create these red "registered" reservations but only create an other type of "unregistered" reservation which simply represents the trains boundings and is only considered when that train is in sighting distance.
Trains operating in these modes (drive_by_sight, one_train_staff, time_interval) should just ignore registered reservations, that means not stopping at them and not erasing them while passing over. In this case, for sure operation is not safe anymore which can lead to emergency stops or emergencies.
The one_train_staff working method:Currently my favorite signaling system because of its very simple but also extremely strong layout just before the telegraph was invented.
I have already written a whole post about it so here is the short version of it:
1. Wizzards everywhere:
When a train being in any other mode than one_train_staff enters a one_train_staff cabinet, it will wait until the next section is free. Also for this working method, there are some wizzards knowing if there is any reservation between this cabinet and the next one.
What I would suggest is that this working method, does not use nor check for reservations at all. The reason for this is that nobody, except the person who has the staff, knows if this section is free or not nor does a driver waiting at a one_train_staff cabinet know if there is anything else on the tracks that did not pickup the staff.
The decision if a train may enter a one_train_staff signaled section or not should only be determined by the one_train_staff cabinet itself. To do so, it needs a bool has_staff that will switch to false when a train not being in one_train_staff mode passes and will switch to true, when a train being in one_train_staff mode passes.
However, one has to implement some way to manually reset one train staff cabinets and there needs to be some thoughts of what should happen when a train in one_train_staff working method is sold or its working method is reset to drive_by_sight using the block tool.
2. Slow down at the cabinet:
Trains seem to slow down to round about 14 km/h when entering a one_train_staff controlled section, but they won't stop! When leaving, they won't even slow down.
I would expect trains to stop at any one_train_staff cabinet on its way.
3. Staff and Ticket:
It would be nice to also simulate Staff and Ticket working method which works like one_train staff but also allows multiple trains in the same direction to enter the section.
4. Automatic exchange
It would also be nice to simulate automatic exchange by introducing some one train staff cabinet with automatic exchange which allows to hand over the staff without stopping at up to 64 km/h. The working method is still one_train_staff.
The time_interval working method:1. Yet another wizzard? Oh no it's a witch! :
It seems to be solid but also with some wizzards in case of a tile in sight distance is already reserved by some far-far away train.
Well I would expect it to ignore that reservation and not to create any registered reservation. However, it should check if there is actually a train in sight distance.
Not much to say about absolute block and token block. Apart from some already reported bugs of the token block, these seem to work just as expected from reality assuming token_block is what english wiki calls an "Electric Token"
https://en.wikipedia.org/wiki/Token_(railway_signalling)#Electric_tokenWell so far about my thoughts up to the absolute block era. I will complete this as ingame time passes by.
Recent Posts![[FR]](/lang/fr.png)
Français (French)