[cesarbl]

At a multiplayer session, the dispatcher might want to allow a train entering an occupied track. It might also be needed to shunt the train. For these situations, forcing the signal to Clear or Approach aspects is too less restrictive. It should be showing Stop and Proceed or Restricting aspects, at least according to Spanish regulations.

In a personal OR version, we have solved this allowing all aspects to be shown in dispatcher window, but I don't know whether this is the best solution. I have also thought of adding a 'Shunting' or 'Override' option in signal's context menu, and a sigscr function to check if that is selected.

If OR development team thinks such a functionality is worthy, I can work on it.

Regards,
César

[conductorchris]

I wonder if it makes sense to distinguish between signaled and signaled track? The mainline can be signaled and the sidings not. Switches could be set to interlocked with the mainline signal system or manually thrown, just like in reality (on US lines anyway).

This could be a precursor to allow multiple different types of signal systems on different lines.

Christopher

[Csantucci]

 cesarbl, on 13 April 2020 - 12:17 AM, said:

At a multiplayer session, the dispatcher might want to allow a train entering an occupied track. It might also be needed to shunt the train. For these situations, forcing the signal to Clear or Approach aspects is too less restrictive. It should be showing Stop and Proceed or Restricting aspects, at least according to Spanish regulations.

In a personal OR version, we have solved this allowing all aspects to be shown in dispatcher window, but I don't know whether this is the best solution. I have also thought of adding a 'Shunting' or 'Override' option in signal's context menu, and a sigscr function to check if that is selected.

If OR development team thinks such a functionality is worthy, I can work on it.

Regards,
César

Hi César,
adding Stop and Proceed to the signal forceable states can be a good idea. I am instead perplex in adding the other intermediate states, because if the human dispatcher does not do things well, often forcing such states generates logically inconsistent states: nothing bad occurs, but that does may not correspond to reality.
So, if you will add Stop and Proceed (not Restricting, because at least in the signal scripts of my country it has other uses) to the forceable states, I might apply your related patch to OR NewYear MG.

[roeter]

 cesarbl, on 13 April 2020 - 12:17 AM, said:

At a multiplayer session, the dispatcher might want to allow a train entering an occupied track. It might also be needed to shunt the train. For these situations, forcing the signal to Clear or Approach aspects is too less restrictive. It should be showing Stop and Proceed or Restricting aspects, at least according to Spanish regulations.

In a personal OR version, we have solved this allowing all aspects to be shown in dispatcher window, but I don't know whether this is the best solution. I have also thought of adding a 'Shunting' or 'Override' option in signal's context menu, and a sigscr function to check if that is selected.

If OR development team thinks such a functionality is worthy, I can work on it.

Regards,
César

There are already signal script functions especially set up for such situations, these are the "callon" functions. These are in particular set up for timetable mode, the callon function is linked to and can be controlled by specific timetable commands. There is, however, a basic version available for activity mode but this is indiscriminate as it is not possible to set specific train commands in activity mode.
It would be possible to add "callon" to the signal commands in the dispatcher window, and make a link between this command and the callon script functions. The advantage of such a command over a more general "stop_and_proceed" or "restricing" command is that it allows the signal aspect to be defined through the scripting and signal definition rather than have a forced state, thus avoiding conflict with existing definitions.
There are two problems, though. First is that the commands in the dispatcher window are independent from the signal type. Second is that there is no way to check if a signal has callon functions set in its script. The result would be that the "callon" option would be available for all signals so also for signals which do not have such facilities. That could be confusing. If a way could be found to restrict the "callon" option to such signals as have these facilities, this would be a better solution than a 'blanket' "stop_and_proceed" or "restricing" command. By the way, adding one of these options would also have the risk of selecting this state for signals for which this aspect is not defined.

Regards,
Rob Roeterdink

[cesarbl]

I have managed to get call on working manually from dispatcher window. If "Call on" is selected in context menu, as soon as the signal is enabled, a variable is set in enabled train, storing the SignalObject of selected signal. When TrainHasCallOn or TrainHasCallOn_Restricted are called from the stored signal, both return true. When the train passes the signal, the variable is restored.

I created a variable in SignalObject, CallOnEnabled, which is false by default, but sets to true as soon as the signal script calls one of the CallOn functions. Dispatcher window then checks this variable for currently picked signal to decide if it should show CallOn option.

I attach a diff with respect to the last unstable version with my changes. I have a couple of things to work on, but I would like to hear if you like this approach.

I still have to fix:
-If train reverses direction, call on should be reset as soon as it passes a signal in the opposite direction.
-Forcing the signal to stop after having allowed call on doesn't seem to work. Reseting CallOn when forcing the signal should do the trick.
-Having the ability to disable call on again (this is really easy, but I didn't have time to check if it works).

Regards,
César

Attached File(s)

•  callon.txt (7.85K)
  Number of downloads: 252

[roeter]

Looks good.

Regards,
Rob Roeterdink

[cesarbl]

I think now it works properly. Is it OK to attach the diff, or do you prefer that I make a pull request in GitHub?

Attached File(s)

•  callon.txt (8.71K)
  Number of downloads: 233

[Csantucci]

It's good if you do both :)

[Csantucci]

Hi César,
thank you for the diff file and for the PR. With the diff file I'll add your feature in next OR NewYear MG release. Having your PR request accepted for inclusion in the official OR versions is instead a bit more complicated. You have to create a Trello card as explained here http://www.elvastowe...post__p__201634 . When someone from the OR management team (I'm not within it) will move such card from the unsorted group to the release 1.4 group, the developers (myself included) will have the authorization to merge your PR.

[cesarbl]

Hi Carlo,
Thanks for the information and for including the feature in your release. I have just created a Trello card.