12601 RB Problems in Remagen

[intallonabile]

Timetable 2012

i had this train coming with +5 (Remagen normally arrive is at 6:47, departs 6:48 for Bonn) So, after route 955-002 i fix route 002-952. I noticed that with signal P002 open when train was entering in Remagen (switch 042 and 039) train had not stop in Remagen. In Train Overview train was announced with is normally duty (stops at Remagen) but train was already towards Oberwinter. Arrived at Oberwinter train dont make is stop. In timetable viewer no hours are reported in renagen and Oberwinter. Last stops is write for Bad Bodendorf.

The problem may be to open starting signal 002 when train is not at stops on platform 2 ?

thanks for the reply

Diego

[TjoeTjoe]

Hi Diego,

though I did a lot of reproduction for this specific train, and here are the results:

situation 1: train from Neuenahr delayed for 5 minutes, entry route plus exit route via track 2 set in advance .

Result: Train does not perform stop at KRE 2 and onwards.

note: seen this before. If train misses one stop, it won't execute it's next stops either unless train is forced to stop there by setting exit signal to Stop at the next station.

situation 2: train from Neuenahr (956) delayed for 5 minutes, entry route to track 2 set in advance . Set exit route when train had stopped at KRE2.

Result: Train does perform stop at KRE 2 and following stops.

situation 3: train from Neuenahrnot delayed, entry route plus exit route via track 2 set in advance .

Result:Train does not perform stop at KRE 2 and onwards. (similar to test #1)

situation 4: trainfrom Neuenahr not delayed, entry route to track 2 set in advance . Set exit route when train had stopped at KRE2.

Result: Train does perform stop at KRE 2 and following stops. (similar to test #2)

situation 5: train delayed for 5 minutes, entry route plus exit route via track 5 set in advance.

Result: Train does performs stop at KRE 5 and following stops.

situation 6: train not delayed, entry route to track 5 set in advance . Set exit route when train had stopped at KRE5.

Result: Train does perform stop at KRE 2 and following stops.

During test 1 through 4 I noticed some very odd behaviour on the panel, which might be causing or be related to this issue. That is when the train starts to occupy track section 002, so 022 occupied and 002 going to be occupied, the white lights in section 002 distinguish for about a second, and after this darkness, the section is showing the red track section occupied lights.

This only happens (as far as I have been able to reproduce) if a route from 956 towards 002 has been applied. (more on this in the results of another test)

So my general conclusion is that there is a bug in the simulation being that trains do not perform a train stop in KRE 2, when they access from 956 into 002

situation 7 : train from Brohl, not delayed, given entry route 954>002 and exit route 002>952 before train is at KRE.

Result: Train does perform stop at KRE 2 and following stops.

situation 8 : train from Brohl, delayed for 5 minutes, given entry route 954>002 and exit route 002>952 before train is at KRE.

Result: Train does perform stop at KRE 2 and following stops.

In these last two tests (7 & 8) I did not see the odd behavior of the track occuption lights of section 002.

So from that point of view I am pretty sure that the issue is just depending on the type of entry route being set.

Interesting stuff for the Signalsoft team as well. Will report this as an issue in the Bug Tracker.

Of course: there is a work around here, and that is not setting the exit route in advance

Erwin

[intallonabile]

Hi Erwin. I appreciate always your professional approch to my questions . You have tried all test that i had in mind to make. Now is in evidence that problem may be arriving from Neuenhar and entrance signal and exit signal both opened at green for train . If there is a list of improvements to do at simulations please, i ask you to introduce this bug in it.

Thanks and have a good we

Diego

[TjoeTjoe]

Hi Diego,

I have logged the above in the Bug Tracking system, so the developpers are aware of the issue

For the rest it is out of my hands. The developpers need to find the time to fix it.

Erwin

[intallonabile]

Thanks

Diego

[intallonabile]

Hallo Erwin

Pheraps you can report again this bug at developpers because problem still remains with last update

Good evening

Diego

[intallonabile]

i'm very happy and i thank signalsoft that there are several new simulations incoming and several new at our disposal (Main Weser, Dusseldorf, ecc) but i'd like that reported bugs (in Remagen and Bonn Bad Godesberg, ecc) to be solved definitively..

i hope that the Signalsoft team find time so to work on bugs.

Good evening

Diego

.

[TjoeTjoe]

First of all, an update of a simulation does not always means that all previously reported issues are resolved. Some may be resolved, some may be not.

Sometimes an update is just required due to changes in or for another simulation. It is one simulation engine in background after all.

I am pretty convinced that the programmers are doing there outmost best to resolve issues as much as possible, but there can be many reasons for not doing it (right away).

In some cases it just can't be done immediately as fixing it affects many if not all simulations (i.e. wrong line operations together with communications). An other reason could be that the issue is not critical enough (read: low priority) as a work around is available. Another one I would like to address is the lack of detailed information about the issue being reported (when does it happen, what settings for the sim are used, which timetable is used etc etc). Reproducing issues can be time consuming in some cases, so if there is not enough background information on something that does not sound that critical, then even I can imagine that such issues get low priority.

A good example for this is a posting on the Dutch forums about disappearing Movement orders yesterday. Here the end user spent some serious time on investigating when a certain bug occurred (and when not). This gave the Signalsoft team some serious clues on where to look in the code. It worked out that they were looking at the wrong spot before. Anyway, it is just to state that reproducing issues is time consuming, so the more detailed input is given there is a higher chance that things can be fixed sooner as the code magicians know where to look. At least I do understand that they do not start trying to reproduce everything themselves without proper or detailed backgrounds. For example, something simple like your issue took me more than an hour to fully reproduce, to record things and to report into the Bug tracker.

So I do understand your frustration but I think it is all about priorities and input information in this case.

With all this new simulations it might look as if issues are not being looked after, thus that focus is getting out new things. Well, I can assure you that that is not correct. Most of the newest simulations are not put together by the Signalsoft team/programmers themselves. In fact, there are a couple of forum members, with a very high level of knowledge about the German signal boxes busy, on creating new simulation/panels. A lot of unannounced simulations are on their way by now. As others are now doing the building , the Signalsoft team has more time to implement new features but also to overhaul existing functionality and solving major bugs or things that just cannot work yet. Think of the dark territories, overhead line things, wrong line operations, the generic dispatcher features in some bigger sims and probably much more. Not saying that it will be done within a month though.

Personally I appreciate it that focus will be on such enhancements and/or revisions on the code/simulation engine. To give you an example, I have not played the Amsterdam CS (not even started) for more then a year now. It is just because it becomes unplayable pretty soon, due to all issues which really need revision like the dark territories, communication stuff and generic dispatcher. Unfortunately, I know of the complexity of this part of the simulation engine, giving me full understanding of that the issues here can not be resolved that easily without the risk of braking things or blocking other sims for updates. So in other words, I think it is good too have those critical issues on a higher priority then an "simple" issue about a train stop (even though the last should be resolved some day as well), as more critical issues not being solved can lead to turning people there back on a certain simulation (or maybe even the whole product line)

Just my two cents

Erwin

[intallonabile]

Thanks as always for your reply.

Diego