Hi!
We often use the token block especially in single track line. But the train stops every token block signal, so operation time will be longer.
However, there's a way WITHOUT stopping at token block signal like the video below.
In this video, a signalman takes a token with next station signalman, and sets the token on a token server. When the train passes through the station, the driver throws to the token receiver and catches from token server. The typical speed is around 60km/h.
Is it possible in Simutrans Extended?
Edit:
This is an example in Taiwan. The speed of last one is around 90km/h! The speed is quite high.
QuoteIs it possible in Simutrans Extended?
This looks mechanically complicated as it has similar limitations to the original railway policemen system used for time interval, that a signalman has to be close enough to the line to walk and physically prepare the token for pickup. It also requires the use of pre-signals to notify passing trains that the staff is not ready for pickup at speed so they will have to stop by the token pickup point and wait. Additionally it is highly prone to human error as grabbing the token is a manual process which could be missed for one reason or another requiring the train to stop past the token pickup point and either reverse or have the token delivered to them.
As far as I am aware the only reason any line still uses such a system is because it is historical (heritage railway lines in the UK), extremely remote (some Scottish line uses it between two stops), the country is extremely poor and so cannot afford to upgrade (India, places like that) or it is a temporary signalling method during line/signal maintenance to allow some traffic (Australia apparently does this quite a bit).
I think modern block signalling systems with multiple aspects allow trains to enter single line segments at full speed because there is no need for a physical token to be collected. Instead the token can be tracked from a block level, making the entire single line railway segment a single block. No trains going in the other direction are allowed into the single line segment due to block reservation mechanics.
In other words one can think of modern block signalling based railway systems as operating with automatically controlled electric tokens between every signal along the line as only a single train can enter any signalling block at any given time.
Thank you for your thoughts. The token block signalling system has to be general, and I suspect that such fast token exchanges are/were relatively rare, especially in earlier times when this method is more common. RETB signalling requires trains to stop completely, and it is likely that early token systems required this also (as early tokens did not have the hoops necessary for collection at speed).
Additionally, as Dr. Supergood indicates, the current system is much easier to code than a system allowing an at speed token exchange.
This token exchange systems were commonly used in Japan and other countries such as Taiwan. There were many single track lines and express trains. Passing token exchange were operated at almost all passing stations.
I suggest to introduce a new .dat parameters such as "can_exchange_token_without_stopping=0/1". If it set 0, the token must stop at the signal (same as before). The top speed should be set using "topspeed=".
Altering this would be quite a large amount of work, and coding priorities are currently elsewhere (and very great in number), coding time being very limited.
Would you be interested in coding this?
Currently, token block signal can not have presignal in Simutrans-Extended.
However, in Japan, token was often exchanged at the station, so token block presignal was often build in front of the station.
Token block presignal only shows a one step loose display of the main signal. This presignal never indicate "DANGER". If it has 2 aspects, it only indicates "CLEAR" or "CAUTION".
When this signal shows CLEAR, this means that the token of the next block is already prepared and the train can pass through the station.
This presignal eliminates the need to stop at the station! (Due to the uncertainty of the existence of the next token)
Interesting - that is a rather different way of doing things than in Extended at present.
Ranran - Thank you very much for your opinion!
It is very useful information - If we use a token block signal with distant signal, it will not change any .dat parameters. And also it makes simutrans more realistic.
James - I will try coding in this direction. If I have some questions, I will ask you.
Interesting - thank you. However, do be sure to allow pakset authors to disable this by requiring that the distant signal be of the token block type for this behaviour to work.
I would welcome the ability to have token block signals that you dont need to stop in front of (modelled as a setting in the dat file), as well as the ability to have presignals in front of them.
Regarding the presignal, would it make sense to be able to use a presignal of any working method?
In old Japanese signalling system, a signal called "passing signal", which is distant signal for starting signal, was required in order to operate passing token exchange.
The passing signal shows clear when the next starting signal is clear, otherwise it shows "caution", and the passing signals were always used together with home signal.
(https://cdn.discordapp.com/attachments/483941895773618196/483942375748534283/udeki-02.JPG)
(https://cdn.discordapp.com/attachments/483941895773618196/483943192996085760/hqdefault.jpg)
The function is very similar to "combined signal", but the home+passing signal should be controlled from the same signalbox of starting signal.
The signal is also home signal, so it requires distant signal.
On the other hand, "token receiver" is also required in order to operate passing token exchange. The receiver is not a signal, but the function is like a "double_block" signal since the receiver reserves beyond the starting signal.
In summary, I think it is better using "passing signal" and "token receiver" whose working method is "absolute_block" and "token_block", respectively.
The trouble with using an absolute block "passing signal" is that a pakset (such as Pak128.Britain-Ex) which does not use this method of working will not be able to prevent players from invoking this behaviour simply by not defining any token block distant signals.
What practical problem would be caused by defining a passing signal as a pre-signal with the token block working method?
There's no problem using "token block" presignal as a passing home signal.