Jump to content

updates


Recommended Posts

Posted

I thought after the .83 version that updates would be made ​​in parallel with the various simulations whereas I see that Gelsenk and Bonn are now with recent updates at version .91 while Andernach and Hurt are to version .85. If is possible to know are you pheraps developing aspect referred only to bigger stations ?

Thanks for reply

Diego

Posted

I thought after the .83 version that updates would be made ​​in parallel with the various simulations whereas I see that Gelsenk and Bonn are now with recent updates at version .91 while Andernach and Hurt are to version .85. If is possible to know are you pheraps developing aspect referred only to bigger stations ?

I really wonder why you think that as of version .83 the simulations will be all updated in parallel?

The past week it might have looked like that, but that's more likely due to the fact that there have been a couple of nasty bugs in the signals, which needed to be resolved for all simulations.

Now, as that has been resolved, the work for KRE, KBBG and KB goes, so the recent updates are most likely related to the LineOps functionality. Of course, may be some other things, but at least not changes that would also affect i.e. KKAS and KAND.

As you might know, all the simulations are based on the same engine, but of course each simulation also has its own specific details. The track network, signals, platforms etc are those kind of specifics.

If such details are not changed, there will be no reason to update a specific simulation.

On the other hand, the Signalsoft team might also choose not to update a specific simulation at a certain moment, as this means that each new built/version (update) needs to be checked/tested.

Hopefully you understand that there is a big difference between testing one simulation prior to release the update, or testing eight simulations prior to releasing its updates.

Anyway, I believe it is definitaly NOT fair/correct to suggest that Signalsoft is only focussing on improving/enhancing the bigger layouts.

Any functionality/enhancement, as long it can be applicable for the specific simulation regardless it is a small or big panel, can and will be added at a certain moment

Erwin

Posted

Each layout has significant different details to test. Some of the updates are related to ALL simulations (like the revocation of combined shunt routes) and you'll see an update for all sims happening then.

Some of that depends on some very detailed and specific testing, as we cannot test every functionality, every route, every train at every start time of the day. (I think we would have to do about 300.000 test situations in Andernach alone and about 4 million testcases in Cologne)

So we have test methods in place that catches a lot. But you can't catch everything at every layout.

And you can have some silly surprises... change something to improve Cologne, and suddenly on a totally different spot something in Gelsenkirchen goes wrong.

Most notorious of that is the jumping of trainnumbers.

Things we try most to avoid is unique situations in the code that are only valid for one specific layout. As in real life, the Sp Dr S 60 type of signal boxes ARE very modular, but there is a about 5% of the connections/relays that are very layout specific and individual solutions. EACH signal box has something like that.

At the moment Braunschweig simulation suffers heavily from that effect and a change to that sim is a long process of thinking and testing, before it can be released again. (Braunschweig has some very individual solutions, hence we wanted it to make FIRST before all the others. Cologne has some complex things as well, but they fitted within the complete concept)

Even this week we noticed that we encountered some problems that are oh-so similar as in real life.

Take the automatic block system "Block 60" (as seen in Hürth/Cologne). There are some very unique features, in case lamps go out due to a fault. In some situations when a fault occurs, the previous signal needs to drop at stop. Well this was hard to do in the sim within our concept of relays. So we asked a real expert... answer: very same problem they have too! Their solution: "occupy" the track before it, to trigger the previous signal to drop to stop. But only later they pulled an exta wire to check the actual aspect of the signal.

So we just implemented it that way too.

Again, all in the purpose of getting it as real as possible. But sometimes we run into limits as "even the experts don't know what a certain function/button is for on the signal box.

Posted

Absolutely i did not want to speculate or suppose anything abou bigger or small simulation and i apologize if someone can interpret this by my words. It's only the curiosity to understand the work of signalsoft team on various simualtion. Thanks at Erwin and Richard so i can comprise the "philosofy" behind the software

Diego

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.