System.NullReferenceException at Orts.Simulation.Signalling.SignalObject.getBlockState_pathBased (X3874, KahLineOR, Новый сценарий)

[Victor]

Crash when an AI train clears a next block

[Carlo Santucci (carlosanit1)]

Hi Victor, please try release x.3875.

[Victor (vitro)]

Hi Carlo, thank you, there is no more crashes. Here is a new problem: AI train stops on waiting point, but "WTP" is not appearing in AI mode in Dispatcher Information and so waiting point never expires.

[Carlo Santucci (carlosanit1)]

Yes, I know that also this problem has been created with x.3863. X.3876 should have solved that. Pls. check. There could still be a timing problem (AI train slowed down more than usual at waiting points).

[Victor (vitro)]

I've checked X3876. Waiting points now operating properly. There is next problem in my activity. NORMAL signal before switch isn't cleared, until I dont occupy a block just in front of them. Here is some screenshots.

http://imgur.com/a/P7mLJ

1. The fifth signal doesn't open. Before STOP it should be three STOP_AND_PROCEEDs, then RESTRICTING, and so on.

2. By the way, I am driving a traffic service now. And if it was an AI, there train would stop on first STOP_AND_PROCEED by Approach Control function. We can do not slow down and so we ignore it and move directly to STOP.

3. Once we have passed last STOP_AND_PROCEED, the route are cleared further.

I understand that it is quite a not standart usage of signalling, but it was working on previous versions.

[r.roeterdink (r-roeterdink)]

It looks to me that signal 5 is the signal protecting the section which is still occupied by train 1 - see image.
It could be that the changes cause a slight difference in timing such that train 1 is now in a slightly different position as it used to be.
It does not look like a signal error to me.

[Victor (vitro)]

You're pointing to PLAYER service, but I have switched to Pzh1 service at this screenshot. The PLAYER is behind me, and after fifth signal there is nothing except switch

[r.roeterdink (r-roeterdink)]

You mention approach_control.
Do you use the approach control functions to switch between signal states other then STOP?
If so, that could explain what happens - if a signal uses an approach control function and the conditions are not met, the system will not clear any signals further on.
If that is what happens here, I would need to extend that logic by also testing the present state.
If that is indeed so, can you test it by removing the test for approach control?

Regards,
Rob Roeterdink

[Victor (vitro)]

I'm using approach control to change STOP_AND_PROCEED to STOP, until next block will be cleared. Is it able to clear the fifth block behind the train using signal variables for example?

[r.roeterdink (r-roeterdink)]

Are you using approach_control on the signal that remains at STOP?
If so, than the sequence is correct, as approach_control will not clear a signal until it is the first signal ahead of the train.
If you want to clear that last signal using approach_control if there are still other signals ahead of the train, try using approach_control_position_forced(distance) - this disregards other signals inbetween train and the actual signal.

[Victor (vitro)]

I'm using approach control to stop a train on STOP_AND_PROCEED. Not to clear.

[Victor (vitro)]

I've removed the Approach_Control from these signals. Anyway, the fifth signal stays at STOP with only difference that signal clears after I passed first signal for me on that first screen.