twpol
commented
7 years ago Imported from https://bugs.launchpad.net/or/+bug/1697312/comments/1
| Property | Value |
|---|---|
| Posted by | Victor (vitro) |
| Date posted | Sun, 11 Jun 2017 21:28:44 GMT |
Open twpol opened 7 years ago
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | Victor (vitro) |
| Date posted | Sun, 11 Jun 2017 21:28:44 GMT |
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | Carlo Santucci (carlosanit1) |
| Date posted | Tue, 13 Jun 2017 05:58:15 GMT |
Hi Victor, please try release x.3875.
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | Victor (vitro) |
| Date posted | Tue, 13 Jun 2017 11:28:48 GMT |
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.
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | Carlo Santucci (carlosanit1) |
| Date posted | Wed, 14 Jun 2017 05:14:02 GMT |
Yes, I know that this problem has been introduced with x.3863. Waiting that an official solution is developed, you can replace file Orts.Simulation.dll of release x.3875 with the attached one.
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | Carlo Santucci (carlosanit1) |
| Date posted | Wed, 14 Jun 2017 11:51:03 GMT |
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).
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | Victor (vitro) |
| Date posted | Wed, 14 Jun 2017 22:33:18 GMT |
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.
The fifth signal doesn't open. Before STOP it should be three STOP_AND_PROCEEDs, then RESTRICTING, and so on.
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.
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.
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | r.roeterdink (r-roeterdink) |
| Date posted | Thu, 15 Jun 2017 21:43:08 GMT |
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.
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | Victor (vitro) |
| Date posted | Thu, 15 Jun 2017 21:57:03 GMT |
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
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | r.roeterdink (r-roeterdink) |
| Date posted | Fri, 16 Jun 2017 17:07:44 GMT |
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
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | Victor (vitro) |
| Date posted | Fri, 16 Jun 2017 17:37:32 GMT |
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?
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | r.roeterdink (r-roeterdink) |
| Date posted | Sat, 17 Jun 2017 15:09:17 GMT |
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.
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | Victor (vitro) |
| Date posted | Sat, 17 Jun 2017 15:36:03 GMT |
I'm using approach control to stop a train on STOP_AND_PROCEED. Not to clear.
twpol
commented
7 years ago | Property | Value |
|---|---|
| Posted by | Victor (vitro) |
| Date posted | Sun, 18 Jun 2017 07:33:59 GMT |
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.
Imported from https://bugs.launchpad.net/bugs/1697312
Crash when an AI train clears a next block