[rickloader]

In my timetable a frequent move is for a light engine ex- depot, to $pickup a $static consist. (Declared in the #start field)
However, the last signal before the consist always remains red. If the signal is cleared to proceed in the dispatch viewer, the light engine will pickup the static consist in trainahd mode.
It makes no difference if the $pickup is in the station or dispose field.
If signals are deleted in some cases the pickup is successful, but in others the loco halts at the last node before the static consist.
I have replicated the problem in a simple test route.


I expect I`m doing something silly, but as I have spent hours any help would be appreciated
rick

Attached thumbnail(s)

• 

[rickloader]

I`ve run some more tests, including $transfer, and I believe the stop signal not clearing for pickup is intended behaviour.
Is $callon needed for to pass a stop signal? Or was it superseded in the May17 update?
With callon the signal did clear, and then I made some changes, and now it doesn`t!
Here is my attempt at integrating callon into my stop signal script. I would be grateful someone would check this, as I don`t fully understand the syntax.

//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 if (block_state == #BLOCK_OCCUPIED && TrainHasCallOn() ){
// clear on occupied track and CallOn allowed
state = #SIGASP_STOP_AND_PROCEED; }
else { state = SIGASP_CLEAR_2; }
// Get draw state
draw_state = def_draw_state (state);if (!enabled ||
// Not enabled


thanks, rick

[rickloader]

Some mistakes in the above script, but this one taken from the manual does work.


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

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

With this script both player and AI trains will now pass a stop signal and perform a pickup or transfer, under a restricted aspect in the track monitor. They would not without the callon added to the signal script.
So I guess the next step is to ask Rob if this is what was intended, or for clarification if I`ve been mistaken.
rick

[roeter]

Apologies for the slow response, but I am very busy at the moment.
It is indeed necessary to use TrainHasCallOn (or TrainHasCallOn_Restricted, see manual for differences).
Because all actions on a signal are performed through the script, it is not possible to 'directly' change the state of the signal in case of a call-on situation (such as callon, pickup, attach, transfer). There has to be some function within the script for which the returned result can reflect that state. To change the Blockstate in such a situation would not be proper - the section ahead is occupied, the fact that the train needs to access that section to pickup or anything does not change the blockstate.
There is no other function which could be used, so the TrainHasCallOn function has been set up to perform this test.

Regards,
Rob Roeterdink

[rickloader]

Thanks very much for the explanation Rob. I am sorry to have troubled you at a busy time.
Knowing that I`m on the right lines in changing the signal script is a great boost, and I can now go ahead in confidence.
When you get chance, I suggest mentioning the need for callon in the signal script, for pickup, attach, transfer in any revision of the manual.
Perhaps some of the signal experts on ET might like to offer a substitute stop signal script incorporating callon, for those who might be attempting to write a timetable using an existing route.
I will try, but I only partly understand the script syntax. At least my script above is partly working. ( The aspects in track viewer and train behaviour is correct, but I seem to have lost the signal animation)
Thanks again for providing these superb new functions,
rick

[Jovet]

rickloader, on 29 September 2017 - 10:44 AM, said:

I will try, but I only partly understand the script syntax.

If my dated books can be of assistance, which don't delve into any Open Rails enhancements, you're welcome to try them. Book 1, Book 2.

[ebnertra000]

I'll have to look into the OR-specific signalling features as I have yet to implement any into my route's systems. But I can say this: When I first started messing with signalling, I thought scripts would be impossible to learn. But now, I think they're easier than config files to deal with - less to mess up

[rickloader]

Thanks Joseph your guides are exactly what I need, but it will take me some time to learn. edit: fabulous, valuable info! thanks so much!
Yes ebner, generally scripts are more forgiving than config files, but a missing white space will still crash MSTS even if OR accepts it.
To recap,
I`m trying to alter an existing stop signal script to clear when in OR the "train has callon()" function is true. The train has the callon flag set by the commands $attach $pickup $transfer etc in the station or dispose fields in the timetable.
Without modifying the signal script the stop signal will never clear, and the halted train is in danger of blocking the whole timetable.
My current script now clears signals for callon ok, but the signal remains clear after the train has passed and even after the attach is completed.
Does the code cancel the callon flag when the attach is completed so that train has callon () becomes false, returning the stop aspect?
Perhaps the problem is that my signal only has 2 aspects stop and clear_2 . whereas there are 3 conditions in the script - clear, block occupied, and block occupied with callon.
I have had block occupied with callon return a restricting aspect. This worked fine in the track monitor, but froze the signal displayed in game. So maybe I need 3 aspects in the sigcfg as well.
My script now looks like this


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 (block_state == #BLOCK_CLEAR)
{
// normal clear, e.g.
state = #SIGASP_CLEAR_2;
}
else if (block_state == #BLOCK_OCCUPIED && TrainHasCallOn() )
{
// clear on occupied track and CallOn allowed
state = #SIGASP_CLEAR_2;
}
else
{
// track is not clear or CallOn not allowed
state = #SIGASP_STOP;
}
}

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

[Jovet]

rickloader, on 30 September 2017 - 03:12 PM, said:

My script now looks like this

I'd write your script like this:

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;
			
	}

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

I can't speak to how the "Call-on" routines work internally, but the case of a Call-on should be above track occupancy or being enabled I would think..though I cannot imagine a signal in a Call-on state that is also not enabled. In theory there is nothing wrong with a signal in a Call-on state not returning to Stop immediately when the head-end of the train passes it. For mechanical and interlocked signaling, that would happen whenever the signalman gets around to it anyways. But if the signal is no longer enabled then it should return to Stop at that time anyways.

[rickloader]

Thanks very much Joseph. Your script works fine for callon, and as it is easier to read than mine, I will use it as the basis .
I`m not worried about the signal returning immediately as that is just cosmetic, but if it also gives a clear to following trains that might lockup the timetable. I need to run more tests, but a second train running in the opposing direction did ignore the signals stuck at clear for the callon.
Rob has said that we do need callon with attach, pickup etc and for now we just need signals to clear correctly, avoiding blocked trains from jamming stations.
My route also has specific calling on signals, but the immediate need is to get simple stop signals working.
Rob`s new functions ( pickup,transfer etc) offer awesome scope, and the rewards for tweaking the signals are immense. I have 3 mail trains exchanging vans exactly as timetabled in 1954, but at the moment I have to act as dispatcher clearing some signals.
rick