Signal #492

[graham]

Hi again,

Where about is signal 492? I have 59415 & 66363 complaining they are stuck at signal 492 but for the life of me I cannot find it. I suspect it is one of the spur tracks. Location is given as Aardorp.

I hope these chaps have a lunch box with them as they will be there for some time!

[signalsoftRC]

It's a "virtual" signal, where the train should have never called from. it's needed to prevent the train entering the mainline from the spur in Aadorp. It's like a "stopping point by operational rules".

We've though long to solve that bug and came up with a much nicer solution that doesn't need that "virtual signal" at all and therefore no bug anymore.

The solution turned out to be a complete overhaul of a kernal part of the simulation, as the "old" method would not work in Amsterdam simulation.

We've been working incredibly hard on Amsterdam and Braunschweig implementing and finetuning that solution as it has many advantageous for us in the future.

The advantage for the users is a more realistic operational experience with more possible irregularities and a quicker follow up of simulation packages.

Though the simulation techniques are so "interwoven" with each other that we can't update Hengelo right now. We have to finish a couple of more bits of all three sims before we can output the update of Hengelo.

Give or take it 2-3 weeks likely. and that "spur" problem will be solved. :-)

[EisenStern]

Hi again,

Where about is signal 492? I have 59415 & 66363 complaining they are stuck at signal 492 but for the life of me I cannot find it. I suspect it is one of the spur tracks. Location is given as Aardorp.

I hope these chaps have a lunch box with them as they will be there for some time!

By the way.... Aardorp is a connecting point to the main line between Almelo and Vriezeveen. This bug occurs, if you deny a train to enter this main line (perhaps only after the second, third.... time), if it has been occupied. It should be that way, that you can call the train driver back and order him to enter the main line, but just here you will find the bug and the train will never move. Then, the train driver will call and complain about the (not existing) signal 492.

So - don't just give them a lunch box, but also spend them some tents or so

[Pierre]

Now that Amsterdam has been released, is this bug on the way to being solved? I have 100% extra trains, and there are at least 11 trains waiting to come out of the spur. Where they actually come from beats me. One train is 350m, and before this bug occured at least 7 trains came out of there already. Does NATO have some kind of secret ultra-fast train factory there?

[signalsoftRC]

Yep, we're busy with the Hengelo Update. We're making some changes to the spur and the way the train turnaround and come from Marienberg.

Also you'll be able to allow a train to pass a red light with a written order.

We HAD to finish Amsterdam first, as that was our testbed for testing code for the Hengelo simulation.

[graham]

Hi Everyone,

Did anything ever become of the update mentioned in this thread? Just encountered the dreaded waiting at Signal #492 again using the most recent timetable. I tried my "check for updates" but nothing was available.

Currently runnung V 1.6.1.9925

Thanks as always,

Graham

[Dre]

Well, it seems that most attention is going to the German SpDrS60-signal simulation (unfortunately, I'm a huge GRS-NX* fan and SpDr60/59 just doesn't seem to be my thing). So the update for GRS-NX hasn't been released up to this moment. Maybe Richard can give us an update about it (so it would be an update on the update )

There are some bugs with the Overlay Track Circuit-section. A train entering the spur needs a big amount of time, about 15 minutes, to leave the Almelo-Vriezenveen mainline. And once you've denied a train asking for permission to leave the spur, you have to wait until he call back to ask for permission to leave again. You can call the train yourself and give it permission to leave the spur, but the driver will simply deny the permission (probably has to do something with this "ghost-signal" 492 to make the spur work in the simulation). Personally the bug mentioned never occurs with me. Did you deny a train comming from Aadorp (between Vriezenveen and Almelo) for several times? Sometimes I have to deny permission to leave because there's a local train going from Almelo to Mariënberg, but I never have to deny permission to the same train twice or even more.

*) The fact that Oldenzaal, part of the Hengelo PSB, is my birth town has absolutely nothing to do with that

[graham]

Hi Dre,

Thanks for that.

I actually had the option to call back (can't remember which train now) and tell him to come out of the spur when I was ready. He then called back and asked permission so all good there. Some time later I received calls from two extra trains complaining they were stuck at #492. I don't recall hearing from these two previously, they may have been stuck behind the timetabled train waiting to come out. When I called them back I had no option to tell them to proceed, likewise when they called me I just had the option to say "I will get you going as soon as possible". Maybe it is just the extra trains causing grief for some reason? I sent my assistant over with a round of sandwiches and a thermos

As a side, I too enjoy the GRS-NX panels, although living in Melbourne Australia they are all far from my back yard

I find Amsterdam a little frustrating still as the neighbouring dispatchers still tend to get a little too confused for me. I know the trains can be turned down but that just wouldn't be realistic now would it?

Thanks again,

Graham

[Pierre]

Posted 14 March 2011 - 04:11

Yep, we're busy with the Hengelo Update.

Why is there still no update?? Please stop making new simulations, and improve the existing ones.

[signalsoftRC]

The development of the simulations is a continuous process. Changing one thing, affects and improves all simulations. Though there are many differences between the simulators that makes testing just horribly difficult.

To FIND a bug you need to set up the complete system as where approximately one encounters the error. Than you have to exclude it that it's not an "operator error".

just to set up the sim properly for that specific bug, you might need 20-30 minutes. then to find that there is NO bug because all is working as it is designed.

so you set it up again and try it again, with some difference from what we think the user has done. Another 20-30 minutes are gone. And again, all works fine.

Then... where to look? With messages like "it doesn't work" we are searching for AGES to find such bugs. Our problem is that we operate exactly as it is designed, according to the manual and real operations. If one does it slightly different, there might indeed be something we simply CAN'T find, unless we receive a full bug report with ALL information.

As we never expect that from a normal customer, we keep searching (and finding).. But the process eats a lot a LOT of time.

By providing free updates, we give our customers the opportunity to have new functionality as well. (as a side effect of the bug fixing). The Sp Dr S 60 sim ARE important, as they provide us a new way of building sims.

Also we need bread on the shelve. We're not even want to have butter and other nice stuff on the bread.... just the bread :-) As the sims for retail are not our main sources of income, we need to do other things as well. They are very much simulator related and will again improve our sims very much. But that also takes time.

For that "other thing" I'm currently in South Africa working hard on our sims for professional purposes. and you will see some improvement to the sims happening likely in the next year. We're working hard on it. But we're simply NOT Microsoft with 1 billion customers and 25000 support staff. So it takes a bit longer :-)

[Pierre]

As we never expect that from a normal customer, we keep searching (and finding).. But the process eats a lot a LOT of time.

Well then, since I complain a lot about bugs, let me help you find bugs. The more I can help, the earlier the bugs can be fixed, and the earlier there can be a bug free version of the sim (Hengelo, Amsterdam, Köln).

[TjoeTjoe]

Well then, since I complain a lot about bugs, let me help you find bugs .....

I really don't think that reporting a 'bug' is being considered as "complaining"

This support forum exist to help users with any kind of problems. Problems which could be the result of a bug or the result of operator errors.

Other communication channels, specifically with respect to bug reporting are:

- the feedback e-mail address (listed in pdf manual)

- the public Bug Tracker

Anyway, you are already helping by reporting the potential bugs.

Tracking down the real causes of the real bugs is something that only Signalsoft can and will do (mainly but not limited to the reason as mentionned by Richard)

Now, the following is something that you or anyone else on the forums should not take personal, as it is not really intended to be personal.

However, I will refer to some of your posting, using them as an example for the problems the Signalsoft team is having whilst trouble shooting. Again, nothing personal here

Example 1:

Topic: Support Forum SIGNALSOFT → Nederlands → Post T Köln Hbf → 2 fouten in de avonddienstregeling

Ten eerste moet trein 1-225 volgens dienstregeling op spoor 062 aankomen, waardoor trein 2-77609 geen ruimte meer heeft om aan te koppelen. Trein 1-225 zou op spoor 061 moeten aankomen, dan gaat het wel.

This is a typical example of where Richard's says:

.... With messages like "it doesn't work" we are searching for AGES ....... unless we receive a full bug report with ALL information ....

the 'bug' report would have been more complete if the following had been written:

A.

- train 1-225 arrives at track 062 as per timetable, train occupies 062 through 069, loc 2-77609 from Bf then has to couple at the back of that train at 069

- loc 2-77609 can not go to the occupied track section 069, as a trainroute can not be set from 335 to 069

or a more detailed description of your description on how worked around it

B.

- train 1-225 arrives at track 061 (as 062 as per timetable does not work), train occupies 061 through 068, loc 2-77609 from Bf then has to couple at the back of that train at 069

- I set the ZD signal 068 to stop with HaGT + 068

- I set a trainroute from 335 to 068, loc 2-77609 stops at ZD 068

- Brought ZD 068 back to Kennlicht as soon as loc had stopped at 068, using SGT + 068

- Then loc 2-77609 couples fine

If you would have described it as listed under A then I am pretty sure that someone would have replied with the remark that you shouldn't set a train route, but a shunt route from 335 to 061 without having to touch any ZD-signal.

Description B could have resulted in a simular reply, however the repro here does not actually describe the situation leading to the 'bug'. It describes the 'workaround'. (Workarounds are nice to know, but the bugs need to be fixed)

With these two examples I hope that anyone understands how essential a good description of the potential bug is for the Signalsoft team, so that they will be pointed into the right direction as much as possible.

Which brings me to the next quote:

.... to set up the sim properly for that specific bug, you might need 20-30 minutes .... .... Another 20-30 minutes are gone ....

and that is exactly how it is. Reproducing a situation is the most time consuming thing there exists.

For example: reproducing your issue, though I excluded several factors, took me 90 to 120 minutes. (done with pleasure by the way) Setting up the database, running the sim in the various situations being described as well as simulating the intended situation. This is just to emphasize and confirm that tracking down a bug is really time consuming, not speak of finding a proper solution without breaking other things.

.... Than you have to exclude it that it's not an "operator error" ....

I think I am quite optimistic when I say that 50% of the potential 'bugs" being reported are actually "operator errors". (read: user has made a mistake or actually does not understand what has to be done). Those "operator errors" can be filtered out easily only when sufficient detailed information about the situation is provided (see above)

... Changing one thing, affects and improves all simulations ...

Just quoting this statement to confirm that is really true. A while ago I have had the opportunity to see how things are setup (in the code), and still there are many people that do not realize that all simulations have the same simulation engine in the background. It has happened in the past that a bug fix in one simulation had very bad effects on all other sims available back then. This should also explain why bug fixing is also a long proces from this point of view. They have to be very careful not to fix one thing, resulting in breaking things elsewhere.

Finally, back to your orginal reply ...

.... The more I can help, the earlier the bugs can be fixed .....

Not exactly understanding what you mean by this. If you mean that you want to assist in actually debugging the code, well I do not think that is ever going to happen.

I don't think Signalsoft is very keen on letting external people having (direct) access to the programm code. Simply to the fact that this code is their Intellectual Property plus source for income.

For sure they do not want someone to run of with it.

In all honest, I truely want to assist Richard and his team on doing exactly this as well: reproducing the real 'bugs' with the C# code to track things down, and point out to them where things go wrong.

But I am afraid / sure that I will have to sign some contract and have to do a collateral deposit (or buy myself into the company) before they even start thinking about giving me such access

As that means that they are giving access to their "bread"

To summarize:

For everyone: Please keep posting any issue. And provide as much relevant details around the situation as possible

As stated by Richard: Bugs will be fixed, however due to works in South-Africa things are going slower for the moment.

@Pierre: again, nothing personal here

Erwin

Edited September 11, 2012 by TjoeTjoe
Corrected some really bad typing errors