[Weter]

Quote

You can put a train (player or AI) into auto node by moving to an area with no signals and reversing it through a switch.

Both actions together, or one of them is enough?
At described case, there ARE signals at both ends of platform tracks, so, this condition is inacceptable, right?

Quote

It is a useful check that your syntax and paths are correct

What Do You mean?

Quote

It could be that you have too many sub paths in your train

the red one is "traffic" train: it
1.starts outside the station (somewhere at pool park's track in real life)
2.arrives to platform with engine at the head for boarding (~10 minutes)
3.performing runaround, as soon as possible, during that time (without success)
4.departs to the branch line, at opposite direction, rather have arrived.
So, it has main path, runaround path and than, forms outbound train.

I should to choose that train and drive its engine manually, trying to perform all of predefined actions.

[rickloader]

Hi Weter, the first part of my post above attempted to answer your request for more information about auto node mode. The rest of my post has suggestions that I hope might help everyone. Now I`m happy to try to discuss your problem.
I don`t know all of the conditions to move from auto signal to auto node. Certainly you must pass a switch (enter a new track vector??), and perhaps reverse to start a new sub path.
The reason I suggested auto node mode is because it is outside of the influence of signals and hopefully other trains. If your ADT works in auto node, then you know you are using the corect syntax ( commands and qualifiers, spaces etc)
As you describe it, you don`t have too many sub paths, so this isn`t the problem.
Your red signal isn`t protecting the runround carriages, and the locomotive will be trying to claim a path forwards through the switch. Callon isn`t required yet. It is very likely that the static train has already claimed the path ahead, and the signal is correctly red. How do you know the static train really is static? Was it made static through the #start field or #dispose? Or perhaps from a command like $detach /nonpower /static.
Or possibly another train is making a conflict. This is why you need to look at the Shift F5 dispatcher viewer, because it shows information on train conflicts.
Suspected trains can be disabled temporarlily by putting comment at the top of the train column
Weter`s problem is different from Jan`s because Jan has a signal that leads directly to the runround consist, and Weter does not. Jan probably has a callon problem, and Weter does not.
Yes when you have a problem train, it is good to watch it as AI, and to drive as player.

[roeter]

Weter, on 02 August 2020 - 05:33 AM, said:

the red one is "traffic" train: it
1.starts outside the station (somewhere at pool park's track in real life)
2.arrives to platform with engine at the head for boarding (~10 minutes)
3.performing runaround, as soon as possible, during that time (without success)
4.departs to the branch line, at opposite direction, rather have arrived.
So, it has main path, runaround path and than, forms outbound train.

When you refer to 'runaround', do you actually use the /runaround qualifier in the $forms command?
If so, what you could try is to drop the /runaround command and use $detach and $attach commands, making the run around move a separate train.
The runaround qualifier is much 'older' than the $detach and $attach commands and does not have the same active interaction with the signalling as the later commands do.

Regards,
Rob Roeterdink

[Weter]

Thank for recomendations.

Quote

Was it made static through the #start field or #dispose?

That train arrives(from the left), then forms another train, which has to depart to opposite way(to the left on diagram) 40 minutes later.
so, first one has dispose field, second-only start and during that 40 minutes, third performs runaround.

[VicenteIR]

roeter, on 03 August 2020 - 04:38 AM, said:

The runaround qualifier is much 'older' than the $detach and $attach commands and does not have the same active interaction with the signalling as the later commands do.

Hi, Rob!
Now I am a little confused. Obviously, I didn't understand this point well.
What did you mean by saying "interaction with the signalling"? Does that mean that a signal script is overruled by the qualifier and an action of /runaround will permit to "runarounding" unit(s) to pass signal at danger aspect?

Regards
Oleg

[roeter]

The interaction between the signalling and the $attach, $transfer and $pickup commands runs through the various TRAIN_HAS_CALLON signal script functions.
These functions do not only check if the train is supposed to attach to the train in the section ahead, but also if this is indeed the correct train. It performs these checks based on information set to both trains based on the attach-transfer-pickup commands.
The runaround command was created much earlier and did not set the same level of information for both trains.
I would need to check the code for details, but it could well be that the TRAIN_HAS_CALLON signal script functions do not properly derive the required callon state in case of the runaround command.

Regards,
Rob Roeterdink

[VicenteIR]

To rickloader:

Did you / does your friend tried to use the $forcereversal command in situation that you described at the starting post?

Regards
Oleg

[rickloader]

Hi Oleg, thanks for your suggestion. No I didn`t try $forcereversal. My understanding is that this makes the train reverse before the switch, instead of reversing right back to the next signal and then forwards through the signal. Forcereversal would help if there was enough space for the train between the switch and the signal.
But in many cases the signal is close to the switch, and the train can not fit.
I do not think that $force reversal over-rides the signal, and callon would still be needed to pass the signal.
Rick

[rickloader]

I`m pleased to report that jan has cleverly modifed his signal script to incorporate callon. The red signal now clears to allow coupling, and his problem solved.
However, this requirement for a user to modify their signal script to enable ADT is too demanding for many.
I would like to explore ways to make this easier. I think both diagnostic tools and some code changes are required.
I`m not critical of timetable mode : I admire it greatly. With a few minor changes, I think timetable mode could be much more accessible. Unfortunately, I`m not a programmer, so I can`t do this directly. Help appreciated!
Rick

[rickloader]

A check list for ADT problems.
1) Open the OR log file
Search for entries about your target train

2) Check the timetable-or for syntax errors
Look for typos - copy and paste all path, consist and train names from the timetable-or and the consist folder to make up an error free train column . Look for white spaces - extra or missing

3) Drive the train as player
. Can you tab past red signals and still couple? If yes it is likely you need callon in the signal script

4) Watch as observer
Either make an observer train, static out of the way or jump to your train with alt F9. Enable the signal state with ctrl alt f11. Try changing signal states from the ctrl 9 dispatcher viewer

5) Make a test train in auto node mode. This should be away from signals and reverse through a switch. If you can couple then it is likely that signal scripts need changing to enable callon

6) Test signal links. In explore or manual mode open the ctrl9 dispatcher viewer. set the switches to the train route and see if the signals clear. The route builder may not have set the signal links

7) Open the dispatcher HUD shift F5 Find your train and look for conflicts with other trains
(RHS path info ) characters like #*^~ suggest possible deadlocks. Also look aut "Auth" the authorisation state eg TRAH = train ahead

8)Comment out conflicting trains
Put comment at the head of a train column to disable it. Will the problem train run now?

9)Try alternative commands.
eg try making a $transfer in to a detach followed by a $pickup. Substitute generic type commands for train names. eg nonpower, static etc

10) Split the train in two using $forms in the dispose column
A single complex train with several commands and reversals can fail. 2 (split) trains is easier for OR to handle

[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: 335

[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.