News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

[11.6] choose signal bug.

Started by ӔO, August 19, 2013, 03:15:19 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

ӔO

The trains are behaving in all sorts of strange manners.

- They don't choose a platform and instead wait for their assigned platform to clear
- They choose a platform that is very far and through a nearby open platform
- They choose through end-of-choose signals
- They weave, even if there is a clear route to the platform

Class 170 at the top
Class 221 in the middle
Class 16x and 15x at the bottom
so that it is easier to see which trains are going to platforms they should not.


---

I don't know if it is related, but occasionally, trains will get stuck on a platform that they are scheduled for, but are not assigned to wait at.
My Sketchup open project sources
various projects rolled up: http://dl.dropbox.com/u/17111233/Roll_up.rar

Colour safe chart:

Carl

A couple of observations here:

On loading there are some convoys waiting at a choose signal even though a platform is free. It seems that opening and closing their schedule window, starting with the 158 in the southwest, causes them to choose a platform in the usual way. Interestingly, though, having done that a few times, the bug desists -- after a while, convoys will arrive and leave as normal.

One interesting effect after this happens, however, is that the convoys to the west of the station appear to be given priority over the convoys to the east of the station with regard to choose signals. That is, the convoys at the southeast signals are having to wait a very long time for a platform.

Edit: in fact, the convoys to the east have registered an error (orange bar), but they, too, will choose a platform as normal after their schedule window is opened and closed. Very odd!

jamespetts

I think that I have fixed this on the 11.x branch - although when the game loads, there is still a convoy (no. 32) that waits a long time at a choose signal despite free platforms, this is because it has saved its previous route, which was generated when the error was still present: this route takes it on a round-about route that passes through one of the end of choose signals, so the choose signal reservation system will not work until it searches for a new route.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

whoami

#3
To check out the current state of ST-Exp, I have started a small new game with 11.12 and Pak128.Britain.Exp 0.9.0 in the year 1880. It seems that both the semaphore-style choose signal and the long-block signal do not work as such (that is, they behave like standard signals). The first does not select another track (don't know how long to wait for this to happen, it might occur eventually) in a very basic situation.
The problem might be caused by a pakset definition, but looks much like what can be read here.
Count me as a beginner with ST-Exp, but I have used these signals for years in ST-standard.

jamespetts

Can you upload a saved game in which this issue can be reproduced?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Junna

This appears to be happening on the current server game, too?

jamespetts

Where does this occur, may I ask? And can anyone confirm whether, for any specific given track layout, Experimental behaves differently to Standard in this regard?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl


whoami

Quote from: jamespetts on October 15, 2013, 04:17:28 PM
Can you upload a saved game in which this issue can be reproduced?
http://simutrans-germany.com/files/upload/PC184G2_ST-Exp_Pak128.Britain_013_SJ1881-01_ST-Exp_11.12_bankrott.sve
1st choose signal at Ingolstadt Nord, but it is used for Ingolstadt Hbf. There used to be a long-block signal to control both stations (when Ingolstadt Nord had only one track), which also did not work.
2nd choose signal at Recklinghausen. Only the one on the left side does not work, this may depend on the line/schedule. I think I have seen the right one (used by one line) working.
The two-block signal even more to the left of Recklinghausen also does not function properly, or is it that replacing a signal does not have effect until the routes are calculated again?
And please ignore the "you are bankrupt" messages, it is only my first try.  :)

The pattern that emerges is that three different signal types cannot provide their special function, but this may depend on their location, direction, or the schedules of the trains.

jamespetts

Thank you for that - I probably shall not have time to look into that until next week now. However, the calculation of the route does impact on the functioning of special signals, so routes calculated before they were changed might very well result in the functions of those signals not being used for the convoys that have so calculated. Can you confirm whether this issue occurs with convoys that start their journeys after the signals are installed?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

whoami

#10
If you mean by "start their journeys" that they have repeated their schedules from the beginning after the signal placement: even in these cases, the signals seem to fail in providing their special functions. Coming from ST-standard, I assume the signal to be effective immediately (unless the train's track reservation has bypassed the tile), though there have been (and still may be) bugs or limitations with special situations. This becomes especially important when signals have to be moved when extending or reorganizing a station that is used by many trains (and I like to limit pause mode to a few exceptions).
If you mean that the individual schedule has to be reset (e.g. by changing the line schedule) for the signal to become useful: this should not be required. If it is necessary for some technical reason, then it should happen automatically by checking all routes whether they use a certain tile that underwent specific types of changes (and just writing this makes me expect that it will be severely computationally expensive).

jamespetts

I did mean the first. I will have to look into this when I get an opportunity - thank you for the report.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

whoami

Some notes for my savegame (written from memory):
The second choose signal (Recklinghausen) seems to misbehave only for line 60. For line 61, I have seen a choice of an alternate track at several times. Accoding to the convoy details, all the involved trains have at most length 2, which should fit in any of the three tracks at this stations. BUT: Only line 60 is set to use the one platform with length 3 by default, the other lines are not! I have also found that, in the provided savegames, the track with the loop had a signal on a points tile, but removing this signal does not change the behaviour.

The two-block signal to the left sometimes works, sometimes not. The latter was only observable (a few times) for line 61. This line has two convoys, so perhaps exactly one of these trains disregards the special function.

whoami

Correction: the problems are not line dependent, the theories I wrote here cannot explain what happens. But I have a new idea: it seems that the choose/two-block/long-block signals lose their special function if the trains actually have to stop and wait there. After the stop, the signal would just be regarded as a standard signal.

jamespetts

Thank you very much for that. Is this a theory that you have been able to test?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Carl

Quote from: whoami on October 22, 2013, 07:15:31 PM
Correction: the problems are not line dependent, the theories I wrote here cannot explain what happens. But I have a new idea: it seems that the choose/two-block/long-block signals lose their special function if the trains actually have to stop and wait there. After the stop, the signal would just be regarded as a standard signal.
Interesting hypothesis - I'll try to test this in my save later on today at the places I was experiencing oddities.

whoami

Quote from: jamespetts on October 22, 2013, 10:07:01 PM
Thank you very much for that. Is this a theory that you have been able to test?
I have tested the choose signal and the two-block signal, both show this behaviour. For the choose signal, just take one of the savegames that I have published, block the points area temporarily by stopping a moving train until the next approaching one has stopped at the choose signal, then release the first train. For the two-block signal, you can use the savegame linked here on October 17th ( http://simutrans-germany.com/files/upload/PC184G2_ST-Exp_Pak128.Britain_013_SJ1881-01_ST-Exp_11.12_bankrott.sve ) in the same way. The two-block signal is placed at (93,101).

jamespetts

I think that I have now found and fixed on the 11.x branch the problem whereby special signals would not work as such when the train had stopped behind them. Is there any more to the problem than this, as far as anyone can tell?
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.