[rickloader]

Jan has kindly sent his modified signal script, attached.
I hope I don`t appear to be labouring this callon issue, but it isn`t an easy subject unless you are familiar with signal scripts.
There are now 2 additional advanced callon modes, making 4 total. While the quick response to a problem must be applauded, I can`t help wondering if a simplified callon might be useful.
Something like a #station or #dispose command, say callon_any. So that a train with callon_any would pass a station entry signal to couple without needing a modified sigscript
It seems to me that in a fully signalled route if 2 trains have been brought together, most likely they are intended to couple.
If trains get out of sequence and the wrong trains couple, well callon_any won`t be viable, but I suspect in many situations it would be ok.
Rick
 Jan_callonscript.txt (1.48K)
Number of downloads: 279

[roeter]

rickloader, on 14 August 2020 - 12:20 PM, said:

There are now 2 additional advanced callon modes, making 4 total. While the quick response to a problem must be applauded, I can`t help wondering if a simplified callon might be useful.
Something like a #station or #dispose command, say callon_any. So that a train with callon_any would pass a station entry signal to couple without needing a modified sigscript
It seems to me that in a fully signalled route if 2 trains have been brought together, most likely they are intended to couple.
If trains get out of sequence and the wrong trains couple, well callon_any won`t be viable, but I suspect in many situations it would be ok.
Rick

Allowing call-on would not automatically couple those trains - that's a separate check and trains will only couple if they match the related command.
What could happen, though, is that a train is allowed to call-on but the other train is supposed to depart in the opposite direction - that would create a nice deadlock.

I can see two ways options to allow a call-on without the need to adapt the signal script could be introduced. One is through a general option at route level, so in the .trk file (or the include portion of a .trk file). This would then be applied to all situations.
An other option would be an additional qualifier for the ADTP commands (P is for $pickup), say "/forcesignal".

In both cases, the signal process would, under specific conditions, perform an 'automatic' HAS_TRAIN_CALLON check, and release the signal if the train does match the required criteria.

I'm afraid though that I am no longer in a position to make the required code changes. I have stopped active code development; the present setup etc. for code changes is costing me too much time which I prefer to spend on other things. The fact that my 'private' version of OR is ever more diverging from the 'official' versions is not helping, either.
I am a bit disapointed, though, that no other developer seems to have any interest in timetable mode. If this is just about 'cold feet', i.e. one is a little fearful to start tackling timetable code because one does not no how it works or how the code is set up, perhaps I can help by giving advice, pointing things out etc.
If this would help a developer to cross the bridge that would be great. If, on the other hand, there is indeed no interest among the present developers to maintain, improve and perhaps even expand timetable mode, I fear that the timetable mode has been shunted onto a dead-end track and is about to run into the buffers.

Regards,
Rob Roeterdink

[rickloader]

Thank you Rob for considering my suggestion. I think your qualifier "/forcesignal" would be an a splendid solution. I hope some dev will take up the proposal.
Generally, I think that modifications to the route are undesirable because users see that as the routebuilders province. So a modified .trk and sigcfg would face user resistance.
I understand (though regret) that you may not continue timetable development. I`m sure all would agree that your contribution to signals and timetables is of inestimable value. It is heartening to know that you are on hand for advice.
Timetable mode canot be considered a dead end. It is unique in train sims, and can stand alone as is, without further development. Indeed OR activity mode needs to catchup with timetables.
Somewhere on the roadmap the aim of converging timetables and activities was declared. I wonder if that has been forgotten?
There are of course too few developers. The discussion about consists shows that some quite senior figures in the ORTS firmament have only a limited understanding of timetables, and so not much incentive to contribute.
If timetables had more users perhaps this might change, and that the reason for this topic.
One area that would benefit users is extra information about what a timetable train is actually doing: its state and relationship to signals and other trains. Currently the only source is the shift F5 dispatcher window. This is not user friendly, being abbreviated, and needing some experience to interpret.
Chris Jakeman has produced a marvelous modification to the ctrl9 dispatcher window in a NewYear MG version. In this the trains are tagged with their number, and their current state/ mode. accelerating, braking, following, train ahead etc. In addition you can see signal states . Currently Chris is modest about his work, and although bug free in timetables, the mod has not been tested in other modes. I will try to share some pics before I go on holiday. Chris` mod will be of the greatest value to timetable compilers
Rick

[YoRyan]

The lack of documentation is a serious handicap for both prospective users and developers. When I wrote my autotable program, I had to dig through PDF design documents posted here to obtain an up-to-date list of commands. The official Open Rails manual still lacks many of them and is flat-out incorrect in some descriptions when compared with the actual C# code.

Personally, I don't believe the differences between timetables and activities are as large as some are making them out to be, so I think the good news is that if we ever get around to designing the native OR activity format, it should be possible to unify them. I believe they are already unified in our sole competitor for timetable mode, Train Sim World.

[rickloader]

Thanks Ryan. I can`t read C# so it is helpful to have the view of somone who can. As well as documenting at this level, there is also a need for guidance at the user level. And I think that OR could provide a lot more information to help the user baffled by his train stuck at a red signal.
So to introduce Chris` dispatch viewer mod. I`m trembling in fear of not doing it justice. I considered anotating the attached screenshots but decide against adding clutter. So I ask you all please to study the pics based on the train number given by the timetable, and try to match this with my commentary. I hope my description is clear and can be followed.
The sequence shows a healthy $pickup /static operation, through a signal with calllon_restricted using the script I gave earlier.

[rickloader]

Train 274 (8:59BmthC) is a locomotive backing from left to right to pickup a static consist 478 bottom right. The mode is Braking Auto_Signal because the train "knows" it will soon stop, and it is under signal control.
The move is guarded by signal 445 which is displaying the permissive "restricting" aspect because the train $pickup command is valid for the signal with callon. (A signal without callon would not clear.)
Note that the signal state shows that it is controlling train 274. This feature is very valuable. If the signal showed any other train number it would be a vital clue to problems. (this might be very useful if extended to switches)
Our backing loco 274 is shown bold red type, because it is an active train. Passive trains like the static coaches are shown feint pink type.

[rickloader]

Pic2
Having gained entry to the occupied station our loco 274 is clear to pickup the static consist. It shows modes "Following" because it is detecting another train . "Auto_node" because it is now beyond signal control. "Train_Ahead" seems to be the vital authority to couple, and is helpfully also shown on the ingame window. As far as i`m aware there is no actual flag that denotes a train has callon.
Let`s look at some other features.
At top left train 152 is showing "stopped" "auto_node" "Train_ahead" This is an unhealthy situation because train 152 shows a delay of 2hours in the Shift F5 HUD It does not have call on and is attempting to reach a stabling position beyond static train 127. Being in auto_node train 152 has approached 127 closely but is stopped short. if a player was in control the train would pass through.the static one
Train 000_00 is the player train. it is a static observer train with a short path so it shows "End_of_authority"
Well, I hope this does justice to a marvelous new aid to timetable compilers
Rick

Attached thumbnail(s)

• 

[Weter]

Great improvement!
I will wait its appearing at ORTS release, as I hope, this will clear-up some "dark" moments at timetable realisation process.

Rob!
Thank You alot for Timetable conception implementation and for ready to answer on every question about it!
You gave me the preshious gift
for many hours to define, tune-up and to ride-
It's my favorete part of ORTS!
Brilliant Job!

[rickloader]

Agree 100% Weter!
Returning to the pics above, You can see that both274 and 152 trains show Train_Ahead. But 274 is authorised to couple, and 152 not. To quote Rob
"Allowing call-on would not automatically couple those trains - that's a separate check and trains will only couple if they match the related command".
We need to display this authority to couple because it is vital info in managing ADTP operations. Is there anyway to add this? Either by adding a flag to the code like "coupling_authorised" or by a change of colour in the Ctrl9 window.
Now the coupling_authorised state can change giving what I call a "stuck" train. I want to tackle this when I get back from holiday, but will say for now that stuck trains are associated with over complex trains. Too many $commands, path reversals in 1 TT column . Solution split 1 column into 2 or more columns.
So please could we display this "coupling_authorised"?
Or Rob in his advisory capacity suggest how it might be done. please?
Rick

[rickloader]

Reserved Switch (RSW)
The reserved switch means that another trains path has claimed the switch ahead. As part of deadlock avoidance signals will not clear.

Faced with a signal that will not clear, as player you can attempt to TAB past it, or in the ctrl9 dispatch viewer you could set the signal to clear, but of course any AI will be held before a RSW.
In the Shift F5 dispatcher HUD look at the right hand path section. Characters like # ^*~ indicate possible deadlock. The internal TT train number responsible will be shown, and this train will need path or TT changes.
The train number can be linked to the train ID , either in the alt9 list, or the ctrl9 dispatcher mod . This roundabout way of matching the internal timetable train number with the train ID (as given at the head of the timetable-or column), is awkward, and it would be helpful if the train number were displayed in game in the f7 label. (perhaps in place of the timetable name : does the TT name serve any purpose?)
It would be very useful if a list of all internal tt numbers could be available with the train id (name as in the tt-or)
For example, in my own timetable, I know that train 281 is causing a RSW, but I can`t see this train in the dispatcher HUD. Maybe it has already terminated. So how can I identify train 281 in the timetable-or?
So a RSW situation is about path control.
There are several commands to limit path propagation, $hold, $noclaim, $hold $wait, $activate, but these may not work when a train is on a 2nd or greater sub path ie. after reversals.
If this is so, the usual stand-by is to split the train into 2 columns, so that the new split train doesn`t claim the switch.