[mauried]

Anyone know what AI trains do when approaching a permissive signal thats showing Red (Stop and Proceed).
Ive been getting some odd behaviour from AI trains when encountering these signals when red , and it could be anything
thats causing it , but knowing what the default behaviour is would help.
What seems to happen is that the AI train slows down when approaching the signal,gets to around 10 - 20 metres of the signal,
then applies full power and goes past.
As soon as the loco passes the signal it then brakes hard and stops, and then never moves again.
If its the Stop and Proceed definition in the Signal.cfg file, Ill just remove it.
Thanks

[roeter]

The behaviour should be that the train slows down to almost stand-still, then proceeds. If there is a train in front (as one might expect), the AI train will adjust it's speed to that train, following it at a distance of about 300 meter.
It the train ahead is stopped, the AI train will close up to about 20 m. for passenger trains, and about 50 m. for freight trains.
Please take a look at the Dispatcher Info (press Shift-F5 until that info is shown). It displays both the aspect info for that train, and also it's path and any other trains ahead of it. If you can take a screen-shot of that display when the AI trains is stopped, I could have a look and see what goes on.

Regards,

Rob Roeterdink

[mauried]

Thanks for responding.
I replaced the permissives with absolutes and the activity worked fine .
Could be I have some buggy signal scripts , so Ill play around some more and try and replicate the problem with some differant style signals.

[Buttercup]

I have a similar problem. Route: Sandpatch at Yoder Eastbound Siding. I have two ai trains: one eastbound on the main approaching east end of the siding. There is a permissive signal "protecting" this end of the siding. I have another ai approaching from the opposite direction that has reserved the switch to enter the siding. The eastbound approaches the red permissive slowing almost to a stop and then passes the permissive and immediately stops at the reserved switch to wait for the opposing ai to enter the siding. The opposing ai approaches and enters the siding. During this the dispatcher window appears to indicate that the stopped ai is still trying to accelerate with the brakes on. After the opposing ai has entered the siding the dispatcher window indicates that the stopped ai now has a clear path to proceed thru the switch. This ai train now stops trying to accelerate and just sits there. It seems that the train remains under power after passing the permissive even though it brakes to a stop a the reserved switch. When it gets the path thru the switch its power gets toggled off so it just sits there.

[roeter]

Giving this some thought I think I can understand what happens here.
As I described above, when a train passes a STOP_AND_PROCEED aspect, it will try to settle itself at a fixed distance behind the preceding train, adapting it's speed to that train. But in this situations, the preceding train is actually approaching as it is moving in the opposite direction - something the program is not expecting.
So, part of the program tries to increase the speed to match that of the other train, the other part tries to brake the train as it tries to keep a fixed distant. Allthough the train can not actually be in both states at the same time, in this situation is is likely to 'toggle' between these two states.
However, I think that it is wrong to use permissive signals in this situation. As far as I am aware, in real life permissive signals were never used to protect junctions or yards. So until it is convincingly proven that I am wrong, I consider this to be a route signalling problem rather than a program problem.

Just one remark : in this situation, permissive signals should not be confused with 'calling on' signals.
Permissive signals do not have a 'STOP' aspect, and trains will therefor always pass this signal, regardless of whatever is ahead. A 'calling on' aspect is a subsidiary aspect, such a signal would also have a normal 'STOP' aspect, and trains will only be allowed to proceed to occupied track if the train ahead is stationary or moving in the same direction. Therefor, 'calling on' aspects can be used at yards and stations, and will work properly, also for AI trains.

Regards,

Rob Roeterdink

[Buttercup]

Thanks for the explanation. I was expecting that after the ai passed the permissive signal it would treat the switch that is reserved by the approaching ai in a way that is similar to absolute signal and proceed when the approaching ai has released the switch and the path beyond.

[roeter]

OK - I see. I'm afraid that's not so - the AI which passes the signal adjusts itself to the other train.
It is true that there is a kind of option missing here, something that has indeed been on my mind. What is needed, in this situation but also in others where trains are entering yards or sidings, it the possibility to 'switch' a train to NODE control, instead of SIGNAL control - so it will go into the yard and check on other trains where it can go, stopping for switches over which other trains are booked etc.
It would require an additional type of control item, and at present such additions can not yet be made.
Something to keep in mind, though.

Regards,

Rob Roeterdink

[mauried]

Couple of questions for the devs.
Ive been trying to track down whats causing the AI trains to get stuck on my route, and its permissive signals which are "dark" when they are supposed to be showing stop and proceed.
What do AI trains do under this situation?
What is making the signals dark Im still trying to figure out , as the indication in the track monitor is correct, ie it shows the signal is showing stop and proceed, but the physical track side signal is not lit up at all.
Note this only happens for the stop and proceed aspect (red) , the signals are OK for the other aspects , and light up properly.
Does OR determine the signals aspects by reading the sigcfg and sigscr files the same way MSTS does.
The signals do work OK in MSTS.
As a workaround Ive temporarily replaced all the permissives with absolutes which work fine , but Id like to sort this out.
My sigcfg file does have a lot of signals in it , around 120 differant types, so could this be part of the problem.
Does OR have a limit for the maximum number of differant signal types.

thanks

[roeter]

Couple of answers.
First : check your log-file for any sigcfg or sigscr related errors.
Generally, if a signal remains dark, it is due to some error in either of these files. In particular, OR is a bit more strict on the syntax in the sigscr.dat file than MSTS.

There is no limit on the amount of signals. I've got routes with about 100 or more signals and no problems.

If AI trains stop on those dark signals, it is likely that the aspect is not STOP_AND_PROCEED, but probably STOP but with invalid state or something. There are ways to find this out but for that a lot more information is required.

Best to start with checking the log-file - if you want some help, then attach logfile + sigscr files.
If you don't want to publish these in the open forum, then send me a PM or mail (my mail is in my profile).

Regards,

Rob Roeterdink

[mauried]

Yayy, problem finally solved.
Duplicate SignalTypes in Sigcfg.dat and corresponding duplicate scripts in Sigscr.dat.
Strangely, the duplicate signals had nothing at all to do with the signals that were playing up.
Many thanks for your help Roeter.