[Jovet]

ebnertra000, on 12 October 2017 - 06:02 AM, said:

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

That's the kind of thing I've had in mind. This is far off topic for this thread, I suppose, but like a train path or something (which spiders out to all the tracks it touches, versus a single line like path) setup by the activity creator which can be activated/deactivated during an activity as a dispatcher would do. Shunting signals inside this "area", when active, would be "enabled" or whatever, and would show on the Track Monitor. Main signals would be disregarded if they're near (10m?) a permitting shunting signal—not matter to trains, and not show on the Track Monitor. The first shunting signal outside this area on each track would show on the Track Monitor as Stop, as would Main signals without a permitting shunting signal. There could be other caveats of shunting signals or operations of which I'm not aware (I don't claim to be an expert on European/Asian/Australian/African signaling) but I think this would be the most realistic to my knowledge.

[ebnertra000]

That sounds about right... I'm not really an expert either, but I could take a crack at translating some signal rules I have from a few countries that are known to have them if this idea takes off.

That would be for a different thread, I think, as it is a little off-topic for this thread

[rickloader]

ebnertra000, on 12 October 2017 - 06:02 AM, said:

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

Well, in timetable mode $pickup$transfer etc set the flag "has callon" (i think), so perhaps Rob could make a "$userdefined" command that would give a train a "user defined" flag. The signal script author could then make this fit the requirements of his particular railway.

Returning to my last signal script, this works fine with single signal heads. But with 2 head signals having callon, both heads clear, and sometimes unexpected signals off path also clear. So I need to experiment with multi headed signals. Maybe we need 2 signal types - normal "stop" , and "stopwithcallon". The latter would apply to multi headed signals.
Happily for my uk route, most ground (shunting) signals are single headed, and so the 3 aspects stop, callon, and clear work. Although they aren`t exactly callon signals they do frequently apply to a backward move to collect stock. ( which in OR needs a callon).

rick

[Jovet]

rickloader, on 26 October 2017 - 03:42 PM, said:

Returning to my last signal script, this works fine with single signal heads. But with 2 head signals having callon, both heads clear, and sometimes unexpected signals off path also clear.

Both signal heads use the same SignalType? The practical solution here is to have each signal head/arm be different SignalTypes, and then only program one to utilize the Call-on programing.

[rickloader]

Yes, thanks Joseph, you are right! I will use separate SignalTypes for multi headed signals. It was the ones with junction links giving problems, and also the UK combined home/distant. In many cases there is a main stop arm with a subsidiary arm, and the subsidiary can do the call on for shunting. In some cases the subsidiary arm was an actual "call on" arm (in railway terms as well as OR).
Thanks for your help as a signal expert. I know I`m going on a lot in this thread, but I was hoping a timetable expert would swoop in and rescue me!
I think a lot of ORTS timetables deal with block, multiple unit trains, whereas my 1950`s steam era had an amazing amount of loco changes.
My historical timetable is starting to come together at last, and it is very satisfying when trains operate as the official "Engine Working Notice"
We are lucky Rob has given us these powerful timetable functions, and it is just a matter of learning how to apply them.
rick

[rickloader]

Multi headed signals

Following Joseph`s suggestion I have made a 2 headed junction signal with types "LSWRMainstop" normal stop type for the main route, and "LSWRStopBranchCallon" for the diverging route. The latter having "callon_restricted" in its script.
Both signal types have "SignalFlags ( DEFAULT JN_LINK ) " in the sigcfg, and the links are set in MSTS RE.

In timetable mode both signals clear together.

In both scripts there is the check for the route set
!route_set()) // Switch not set as per link?
{
state = SIGASP_STOP;

So I don`t understand why one signal of both, is clearing when the "switch not set as per link?" = true.
A frequent timetable move is for a loco to switch from the main route onto a diverging set of sidings to pickup stock. Callon is needed to prevent stopped trains blocking the main line and causing a "log jam".
Work continues........
rick

[Jovet]

rickloader, on 02 November 2017 - 02:24 AM, said:

In both scripts there is the check for the route set
!route_set()) // Switch not set as per link?

You could post the entire scripts for these signals, if you want.

[rickloader]

Thanks for your continuing help Joseph.
These are 2 head junction signals .First LSWRMainstop.This is intended to be a normal stop for the main route, no callon.

SCRIPT LSWRMainstop.

// mainroute
extern float block_state ();
extern float route_set ();
extern float def_draw_state ();
extern float state;
extern float draw_state;
extern float enabled;

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;
}
else
{
state = SIGASP_CLEAR_2;
}

// Get draw state
draw_state = def_draw_state (state);
/////////////////////////////////////////////////////////////////////////
and LSWRStopBranchCallon. This is to be the diverging route giving entry to a yard, and having callon, to enable picking up stock.


SCRIPT LSWRStopBranchCallon

// Branch Stop Callon

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_Restricted();

if (enabled && route_set() )
{
if (block_state == #BLOCK_CLEAR)
{
// normal clear, e.g.
state = #SIGASP_CLEAR_1;
}
else if (block_state == #BLOCK_OCCUPIED && TrainHasCallOn_Restricted() )
{
// clear on occupied track and CallOn allowed
state = #SIGASP_RESTRICTING;
}
else
{
// track is not clear or CallOn not allowed
state = #SIGASP_STOP;
}
}


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

[rickloader]

Here is the sigcfg

Attached File(s)

•  SigcfgJctCallonSig.txt (2.39K)
  Number of downloads: 10

[rickloader]

Update! The above scripts are, in fact, nearly working. I was misled by getting the .tdb out of sync. Either I did not save my deleted signal, or MSTS RE didn`t. I have now trashed the test route! Can you believe, with my main route backed up on different media and computers, I don`t have a backup of my test route?http://www.elvastower.com/forums/public/style_emoticons/default/blush.gif
The signal type is, of course written to the .tdb, so changing signaltypes alters the saved route. Whereas just changing the scripting (same signaltype) can be applied to an existing save of a route.
I will try again, when I`ve rebuilt the test route, and maybe we need some screen shots. I will change the callon aspect to violet, as purple is hard to distinguish from red.
rick