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).
Log In
Register Now!
Help
