[rickloader]

Well, the above script doesn`t work after all. The signals never return to stop and later trains crash through each other.
we need a "if not enabled state = stop" type statement. so that signals reset to stop.
For the callon we need a restricting aspect if the following are true - train has callon, route is set, block is occupied.
And for clear, just a block state = clear.
For the callon I have just strung together all the conditions with "and". It isn`t elegant but it does seem to work.
So here is the latest ,nearly working. Not sure it is correct- needs more testing


SCRIPT LSWRStop

// Stop

extern float block_state();
extern float route_set();
extern float def_draw_state();
extern float state;
extern float draw_state;
extern float enabled;
extern float TrainHasCallOn();

if (!enabled ||
// Not enabled/cleared to show natural state?
block_state() !=# BLOCK_CLEAR ||
// Block ahead not clear?
!route_set()) // Switch not set as per link?
{
state = SIGASP_STOP;
}
if (enabled && route_set() && TrainHasCallOn() && block_state() !=# BLOCK_CLEAR )

// clear on CallOn
{
state = SIGASP_RESTRICTING;
}
else if (block_state == BLOCK_CLEAR)
// normal clear
{
state = SIGASP_CLEAR_2;

}

// Get draw state
draw_state = def_draw_state(state);
Joseph`s tutorials have been a tremendous help - thanks!.

[rickloader]

This test callon signal was originally 2 state ( stop/ clear) but I feel with callon we have introduced a 3rd (restricting) state
So in the sigcfg signal type I have added another signal aspect - RESTRICTING "purple" and added a purple entry in the ltex section.

LightsTabEntry (
"Purple Light"
colour ( 255 129 0 127 )
)
Actually the LSWR never had purple for callon, but it is useful for testing.
As the route builder can`t know which signals will need a callon capability ( as set by the timetable), it seems desirable that most stop signals can have callon . Is there any reason why not?
In the UK there were specific Callon signals, but also ground (shunting) signals authorized a local move into an occupied block. (Of course in MSTS/ OR an occupied block means something different to the prototype).
I`m discussing this at length because I`m not the best person to explore signalling, having zero programming skill. So I welcome any contribution.
But I strongly believe that the timetable features, (pickup, transfer etc) deserve supporting signalling.
Here is an extract for the test stop signal cfg.


SignalType ( "LSWRStop"

SignalFnType ( NORMAL )
SignalLightTex ( "ltex" )
SemaphoreInfo ( 0.5 )
SignalFlags ( SEMAPHORE )

SignalLights ( 3
SignalLight ( 0 "Red Light"
Position ( -0.3 0 0.05 )
Radius ( 0.08 )
SignalFlags ( SEMAPHORE_CHANGE )
)
SignalLight ( 1 "Green Light"
Position ( -0.3 0 0.05 )
Radius ( 0.08 )
SignalFlags ( SEMAPHORE_CHANGE )
)
SignalLight ( 2 "Purple Light"
Position ( -0.3 0 0.07 )
Radius ( 0.05 )
SignalFlags ( SEMAPHORE_CHANGE )
)

)
SignalDrawStates ( 3
SignalDrawState ( 0
"Red"
DrawLights ( 1
DrawLight ( 0 )
)
SemaphorePos ( 0 )
)
SignalDrawState ( 1
"Green"
DrawLights ( 1
DrawLight ( 1 )
)
SemaphorePos ( 1 )
)
SignalDrawState ( 2
"purple"
DrawLights ( 1
DrawLight ( 2 )
)
SemaphorePos ( 1 )
)

)
SignalAspects ( 3
SignalAspect ( STOP "Red" )
SignalAspect ( CLEAR_2 "Green" )
SignalAspect ( RESTRICTING "Purple" )

)
SignalNumClearAhead ( 3 )
)

[rickloader]

Sorry to keep posting, but I am making progress! The previous script isn`t wrong, but the TrainHasCallOn() function is permissive, meaning trains may meet in deadlock outside of stations.
To answer my question about most stop signals having callon - it also allows callon in free line sections.
In my route callon will only be in booked station platforms so I need TrainHasCallOn_restricted() .
The manual also says that the check for block occupancy should be block_state == #BLOCK_OCCUPIED , so I have altered the script accordingly.
Testing suggests that the revised script maybe ok!


SCRIPT LSWRStop

// Stop

extern float block_state();
extern float route_set();
extern float def_draw_state();
extern float state;
extern float draw_state;
extern float enabled;
extern float TrainHasCallOn();

if (!enabled ||
// Not enabled/cleared to show natural state?
block_state() !=# BLOCK_CLEAR ||
// Block ahead not clear?
!route_set()) // Switch not set as per link?
{
state = SIGASP_STOP;
}
if (enabled && route_set() && TrainHasCallOn_restricted() && block_state == #BLOCK_OCCUPIED )

// clear on CallOn
{
state = SIGASP_RESTRICTING;
}
else if (block_state == BLOCK_CLEAR)
// normal clear
{
state = SIGASP_CLEAR_2;

}

// Get draw state
draw_state = def_draw_state(state);

[Jovet]

SCRIPT LSWRStop

// Stop

    extern float	block_state();
    extern float	route_set();
    extern float	def_draw_state();
    extern float	state;
    extern float	draw_state;
    extern float	enabled;
    extern float	TrainHasCallOn(); 

    if (enabled && route_set() )
    {
        if (TrainHasCallOn()) 
            // clear on CallOn 
            state = SIGASP_CLEAR_2;
            
        else if (block_state == BLOCK_CLEAR)
            // normal clear
            state = SIGASP_CLEAR_2;
            
        else
            // track is not clear or CallOn not allowed
            state = SIGASP_STOP;
            
    }
    else
        // show Stop for bad route/state
        state = SIGASP_STOP;
        

// Get draw state
    draw_state = def_draw_state(state);

That's definitely a goof on my part. The scripts I write, I usually reset the state to Stop at the start of each script, but did not do that above while continuing to rely on it. I've made a simple correction here.

rickloader, on 06 October 2017 - 09:14 AM, said:

As the route builder can`t know which signals will need a callon capability ( as set by the timetable), it seems desirable that most stop signals can have callon . Is there any reason why not?
In the UK there were specific Callon signals, but also ground (shunting) signals authorized a local move into an occupied block. (Of course in MSTS/ OR an occupied block means something different to the prototype).

This is a fairly complicated topic, which I considered bringing up earlier, but decided to spare everyone. It's complicated because of the different ways signaling is implemented and because of how MSTS/OR implement it.

A "call-on" is an intentional invitation by the control operator (dispatcher, signalman) for a train to proceed past an absolute (Stop and stay) signal into a known-occupied signal block. A "call-on" is always indicated by signal aspect. Verbal or written authorization to pass a signal at Danger is a separate situation. Call-ons are useful in situations where trains need to queue up around a passenger station, for example.

The simplest case is in the United States (and Canada). Absolute signals can be given the ability to show a "call-on" state, which usually shows a Restricting aspect and indication to the train. "Restricting" always means proceed slowly on sight, prepared to stop for whatever reason without causing an accident. The signal would otherwise be showing Stop. A few designs of US signals could even change themselves from absolute signals to showing a permissive (Stop and proceed) indication when in the call-on state; but most signals could not do this because a number plate is their only difference between absolute and permissive, and those cannot just be turned on/off. But in all cases, the signal responsible for stopping the train is the same one responsible for conveying the call-on indication. Signals had to be especially equipped to be able to do this (e.g. to be able to show the Restricting aspect). If a signal could not show that aspect, it could not be setup to do call-on runs, either.

In many other parts of the world, the "call-on" state is shown by a special, and sometimes dedicated, signal. This signal can be part of the regular absolute signal (e.g. a Call-on semaphore arm below the Home arm[s]) or a separate signal at the same location as the absolute signal. These special signals were developed because showing a regular Clear for a Call-on is not appropriate because it implies the track is clear when it is not. Conversely, manually granting authority to pass a signal at danger removes the protection of interlocking devices which greatly increases the risk of human error inducing an accident. The Call-on signal thus gives a special aspect to trains so there is sure indication of what is going on (e.g. proceed on sight, expect the track to be occupied) while still being subject to interlocking protection (e.g. call-on can't be shown if switches aren't locked, other conflicting routes active, etc.). Here, the signal responsible for stopping the train may not be the same one conveying the call-on indication. But signals so capable are still especially equipped as in the US.

The problem here the way MSTS handles signal indications that regulate trains: each signal object/track marker is independent. If the Home signal and Call-On signal are on the same signal shape, there is no problem. But if they're separate... the game doesn't really know that it's okay to pass the STOP indication because the signal 0.3 m away in the track database is a Call-on Signal which is allowing the train to proceed. Thus it becomes necessary to construct signal shapes in such a way that the Home and Call-on signals can appear to be separate structures but are the same .s file. That way there is only one track maker, and there are no competing SIGASP_STOP indications at a Call-on location. SIGASP_RESTRICTING is the appropriate indication for a Call-on signal that is engaged.

These same constraints and complications apply to Shunting signals as well, with the caveats: Shunting signals can appear anywhere and not have an associated Home/absolute signal with them; and Shunting signals only apply to trains doing shunting/switching operations—train movements not doing shunting typically totally disregard them. In the case of stand-alone Shunting signals without an absolute signal, they should only show to trains (on the Track Monitor) that have passed another Shunting allowed indication, but should otherwise be invisible on the Track Monitor/etc. But MSTS and OR do not allow this level of sophistication. Of course, there is the SHUNTING type of signal head, which is fine to use, except it can never impose any real authority on a train (e.g. end an activity if passed at Shunting not allowed).

[ebnertra000]

Rick, don't be sorry to keep bringing this up. I'm working on a route project right now with custom signals, and this discussion will help me a lot. I intend to implement OR-specific signal features, but haven't gotten round to it yet

[rickloader]

Glad it is some use Ebner! I think for developing your route the decision will be between "TrainHasCallOn" and "TrainHasCallOn_Restricted" (see manual P150). Rob says that "TrainHasCallOn" is for USA style permissive working. But I got a cornfield meet on a free line, so it needs care. However, if "TrainHasCallOn_Restricted" is safer and more appropriate for the UK, it is confined to station platforms. A WIP routebuilder can add platforms as required : for timetables in existing routes the required platforms may not be present.

Thanks for the discussion on signals Joseph. I`m ignorant of USA signals, and your description and signal charts are very helpful.
I think part of the difference between OR timetables and real life is that to a timetable,a couple of wagons in a siding returns a block occupied and a stop indication. So Rob`s explanation that callon is required for pickup etc is crucial. In the real railway a shunting signal would be cleared for a local move to pickup a few wagons in a siding. In MSTS to be any use, such shunting signals will be absolute stop signals. So shunt signals need callon capability to allow shunt moves in timetables.
Thanks also for the revised script. However, i think the callon section -

if (TrainHasCallOn()) // clear on CallOn
needs to test also for block occupied -
if (block_state == #BLOCK_OCCUPIED && TrainHasCallOn() )

If the active pickup train arrives first, before the passive donor train, it will precede the donor train and not be able to make the pickup. With the block_occupied test, the pickup train should halt at the signal joining the track set for the approaching donor train.
When the donor train is in position the pickup train then gets the callon indication.
This works in testing, and is really neat to see!
I`m now testing with stop and shunt signals on my own WIP route timetable.
rick

[Jovet]

rickloader, on 07 October 2017 - 02:49 AM, said:

Thanks for the discussion on signals Joseph. I`m ignorant of USA signals, and your description and signal charts are very helpful.

Happy to help. An archive of a definitive explanation of how to philosophically interpret US signaling can be found here. A compilation of an excellent explanation of how discreet applications of US signaling work can be found here.

rickloader, on 07 October 2017 - 02:49 AM, said:

In the real railway a shunting signal would be cleared for a local move to pickup a few wagons in a siding. In MSTS to be any use, such shunting signals will be absolute stop signals. So shunt signals need callon capability to allow shunt moves in timetables.

In the real world, Shunting signals take care of all of this. Shunting signals are a kind of "call on" signal in concept but there are also important differences, as I described above. A proper solution for OR would not "require" that "shunting" signals have "call-on" capability. MSTS/OR has no good way to properly implement Shunting signals as they should be operated as on the prototype, so any current tries to have them will have to fall short.

rickloader, on 07 October 2017 - 02:49 AM, said:

Thanks also for the revised script. However, i think the callon section -
if (TrainHasCallOn()) // clear on CallOn
needs to test also for block occupied -
if (block_state == #BLOCK_OCCUPIED && TrainHasCallOn() )
If the active pickup train arrives first, before the passive donor train, it will precede the donor train and not be able to make the pickup. With the block_occupied test, the pickup train should halt at the signal joining the track set for the approaching donor train.

Well, my script-writing also makes assumptions about how timetable mode works. It assumes that "call-ons" are only shown to the appropriate train [if OR is playing dispatcher, then it needs to know what is going on!], and that they reset as soon as that train accepts (passes) the signal. It also assumes that "call-ons" are only shown on absolute signals, and are not shown/needed to enter an unoccupied signal block—since otherwise spoils the purpose in the first place. But if you find that additional condition works better for you in practice, go for it! I just suggest you get rid of that # since it's extraneous.

[roeter]

Jovet, on 11 October 2017 - 04:37 AM, said:

In the real world, Shunting signals take care of all of this. Shunting signals are a kind of "call on" signal in concept but there are also important differences, as I described above. A proper solution for OR would not "require" that "shunting" signals have "call-on" capability. MSTS/OR has no good way to properly implement Shunting signals as they should be operated as on the prototype, so any current tries to have them will have to fall short.

I'm sorry but I completely disagree with the above statement. Neither MSTS nor OR implement any actual signal logic. Both only provide basic building blocks from which the logic can be build using the signal scripting. So, if no proper shunt signals do presently exist, it is because no script writer has been able to define the correct logic.
It may be that some specific 'building block' to define such logic is missing. But, upto now, I have not received any request from any writer of USA-based signal scripts to provide such a specific function. I have received such requests from a number of writers of Europe-based signal scripts, indicating specific situations or specific logic which could not be implemented and requests and suggestions for additional functions to overcome these problems, which have indeed been created allowing the signals to work as required. But, as I said, I have not received any such requests for USA-based signal scripts.
So, in my view, the fact that no proper (USA) shunt signals exist is not because of limitations in OR, but because of a lack of effort by the script-writers to provide the proper logic for such signals. There is a small excuse for this : MSTS could not handle situations with multiple non-player trains (AI or STATIC) on a single section of track, and so for MSTS there was never any need to create proper shunt signals. But OR can handle such situations perfectly well.
If any functionality to provide proper shunt signal logic is indeed still missing I would be interested to hear of this.

Quote

Well, my script-writing also makes assumptions about how timetable mode works. It assumes that "call-ons" are only shown to the appropriate train [if OR is playing dispatcher, then it needs to know what is going on!], and that they reset as soon as that train accepts (passes) the signal. It also assumes that "call-ons" are only shown on absolute signals, and are not shown/needed to enter an unoccupied signal block—since otherwise spoils the purpose in the first place. But if you find that additional condition works better for you in practice, go for it! I just suggest you get rid of that # since it's extraneous.

The call-on function as such has nothing to do with timetable mode - it could work just as well for activities provided there was some way that the necessary information could be added to the activity definition.
But as for its function : the call-on functions only test if the train which is requesting the signal to clear should be allowed to pass that signal, based on commands set for that train and the actual train ahead. The function does not check if the path to the train ahead is actually clear - that information is available through the blockstate function. So, indeed, one must always check on BLOCK_JN_OBSTRUCTED as a signal should never be allowed to clear on that blockstate.
The logic as shown, using BLOCK_OCCUPIED in combination with the call-on function, is an equivalent way to properly handle the blockstate.
So it's not that the test on BLOCK_OCCUPIED is required as otherwise the signal would not clear, it is required to avoid that the signals clears on blockstate BLOCK_JN_OBSTRUCTED.

Regards,
Rob Roeterdink

[Jovet]

roeter, on 11 October 2017 - 08:11 AM, said:

I'm sorry but I completely disagree with the above statement. Neither MSTS nor OR implement any actual signal logic. Both only provide basic building blocks from which the logic can be build using the signal scripting. So, if no proper shunt signals do presently exist, it is because no script writer has been able to define the correct logic.
It may be that some specific 'building block' to define such logic is missing. But, upto now, I have not received any request from any writer of USA-based signal scripts to provide such a specific function. I have received such requests from a number of writers of Europe-based signal scripts, indicating specific situations or specific logic which could not be implemented and requests and suggestions for additional functions to overcome these problems, which have indeed been created allowing the signals to work as required. But, as I said, I have not received any such requests for USA-based signal scripts.
So, in my view, the fact that no proper (USA) shunt signals exist is not because of limitations in OR, but because of a lack of effort by the script-writers to provide the proper logic for such signals. There is a small excuse for this : MSTS could not handle situations with multiple non-player trains (AI or STATIC) on a single section of track, and so for MSTS there was never any need to create proper shunt signals. But OR can handle such situations perfectly well.
If any functionality to provide proper shunt signal logic is indeed still missing I would be interested to hear of this.

Rob, I am not talking about North American signaling at all. There's no such thing as a Shunting signal here, at all; the concept is foreign. Call-ons can be used in lieu, where needed and available.

I'm also not, in any way, suggesting that OR (or MSTS) has or should have built-in signal logic—deciding which aspects show on signals, when. Not sure how you read these things into my post, but...

My point was that the necessary prototype conditions of Shunting signals is above and beyond the framework provided by MSTS. For example, only NORMAL signals can govern trains. Shunting signals must be able to govern trains, but only during shunting operations. I'd be happy to be pointed to some examples where users of and extensions to OR have addressed these problems. But the finest solution, in my mind, is a new type of signal type that only matters to trains part of the time, as defined by new parameters of an activity, and which only shows on the Track monitor when needed; to my knowledge this solution does not exist, and is far above anything MSTS ever dreamed of.

[ebnertra000]

I wonder if you couldn't define a train as being under the authority of a shunting signal in an activity file? Though making that jive with other signals could be difficult