News:

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

Timeinterval signals (with telegrapg) protecting a junction, doesnt get clear

Started by Ves, April 29, 2018, 07:34:13 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Ves

On the servergame  at location (1102,1151) there is a Slotted post signal (timeinterval with telegraph), and it doesnt ever get clear. To resolve it, delete the signal and the train will go away in drive by sight. Build a new signal in its place and it will happen again when the next train arrives.

I have saved the servergame and when you open it up, the signal in question (at location 1102,1151) will be in sight.
https://github.com/VictorErik/saved-games/blob/master/master/bug%20-%20Time%20interval%20w.telegraph%20protect%20junction%20too%20well.sve

jamespetts

Thank you for the report. I am having some trouble reproducing this: a short while after loading (when the train next checks the route), the signal will clear and the train will depart. Can I check that you are using the latest version?
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.

Ves

That is very odd! It happens to me when I load the savegame, even with todays, as of 30/4, nightly build.
Did you wait for the next train to approach the signal (the train named "(4522) LBSCR Gray Single 2-2-2)"?

What happens is that the "(4522) ...." nicely reserves the path up until the tile in front of the signal (shouldnt it actually reserve the tile with the signal too??). When it get the distant signal (1106,1150) in sight, the signal will turn to CAUTION as it should and it will reserve the junction, but when the train is within 4 tiles of the signal, it turns back to DANGER again staying like that forever, with the junction reserved and all.

Also note that the earlier train, which left the scene when the game was loaded, "(5561) ..." will be similarily holding at location (1089,1197), just in front of a signal protecting the next station on the line.

edit:
The effect can also be observed quite frequently on the servergame, like around the "Bloxingpike Railway Station" at (3347,1149)

Rollmaterial



jamespetts

My apologies: I had not realised that you meant the following train. Debugging on the server game is fantastically difficult because it is enormous and therefore is unplayably slow when running with a non-optimised debug build necessary to diagnose problems.

However, I think that I have now fixed this. In fixing this, I had to revert an earlier fix to a much more minor problem, viz. that signals immediately before stations at which all trains passing them stopped were treated as protecting a junction even if they were not. This problem was more cosmetic than functional, and I have not been able to find within a reasonable amount of time a reliable way of fixing that original issue without causing more serious problems such as this.

I should be grateful if you could confirm whether this issue has been fixed with the next nightly build.

My apologies for the proliferation of signalling issues: this has been caused by a few use cases that I had not anticipated not having been coded for, requiring significant extra logic, which then has ended up requiring extensive debugging, which the complexity of the signalling code and difficulty with debugging using the server game have made extremely difficult.
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.

Ves

No worries, we, or at least I, use the servergame to stresstest among others, the signals, and when this game has ended (in way future) we can start a new one to help iron out further bugs! ;D
I will check with tomorrows nightly!

Ves

Thank you James, this appears to be fixed!

Finally it is all starting to come out nicely with these time interval signals!  ;D

DrSuperGood

If this reverts the other issue it messes up some of my lines because the trains only bother to travel at half speed between stations... Oh well guess I need to add buggy distance signals as those count as another signal so the train will travel at full speed most of the way, until seeing the distance signal in which case it drops to half speed and arrives at the platform.

My conclusion so far is that time interval is a total disaster, like one-train-staff. I just hope the up coming absolute block signals work better...

Ves

Well, now I think you are being a tad too harsh, dont you think?
When I logged onto the server this day, the only trains that where stuck was due to a design error in my station planning. The signals where performing just as they should.

I have notet too that distance signals appears to be threated as normal signal in some occasions, but not got around to report it. Did you?

jamespetts

Ves: thank you for confirming the fix.

Dr. Supergood - the other issue only affects signals that protect a station at which all trains that pass that signal stop. If you put the signal close enough to the station (as would have been almost universally the case in reality), it will make no practical difference to the speed of your trains.

As to distant signals, you describe them as "buggy". I am not aware of any outstanding bug reports relating specifically to distant signals of the time interval type. I should be grateful if you could file a proper bug report, complete with reproduction case, in its own thread for each specific issue that you are able to observe and reproduce with time interval distant signals.
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.