Objective criticisms of Railsim

[jamespetts]

Also in the scenario section there is a section on timetabled scenarios which is not the same as the description james quoted. Their definition of a timetabled scenario is the same as mine i believe, the ability to drive a train to a timetable, not set up a whole network operation.

My description is based on the pre-release publicity information. To what definition are you referring? Can you cite a source?

[pmorgancym]

If your right that seems an incredible thing to leave, it is one of the key things about "driving" a train, keeping to timetable.

[AndiS]

signals cannot detect something as basic as the uncoupling of a train and only part of the train leaving the section, for instance.

Sorry, bad example. With better scripts, you can keep track of the "metre of train" on some stretch of track, just like KRS counts trains currently. But until we learn better, we must use funny heuristics to guess whether a consist is shunting or travelling as a train. The scenario engine would know it (whether you are executing a "Stop At Instruction" or a "Consist Operation Instruction"). Too bad it does not tell the signals, or they are not telling us that they there is a way to tell.

Otherwise, I fully agree, with both the assessment of the scenario execution engine and the sorry feeling about the lack of communication to the signals (or, much better, a more realistic framework).

I have already a long list of things to try out....

[Lad491]

Lad491 wrote:
Also in the scenario section there is a section on timetabled scenarios which is not the same as the description james quoted. Their definition of a timetabled scenario is the same as mine i believe, the ability to drive a train to a timetable, not set up a whole network operation.

My description is based on the pre-release publicity information. To what definition are you referring? Can you cite a source?

It does appear Im wrong too hasty a conclusion from a quick read of the manual on scenario's There is certainly an option in the scenario tools to create a Timetabled Scenario. Later in the description of creating scenario's it talks about the ability to switch on or off the timetable to give error reports in the final evaluation. A closer reading this morning however shows that this is talking about standard scenario's, whereas i took it to mean you could turn timetabled scenario's on or off.

I find it really confusing to have two very similar descriptions, standard scenarios with timetable and timetabled scenario's. A different description is needed for the latter i think.
Network operation scenario's would be better, since what you want to do is have the whole network running whereas i only want the services affected by my player service running.

Anyway since timetabled scenario's are in the list of options available - I wonder what it does?

[jamespetts]

Sorry, bad example. With better scripts, you can keep track of the "metre of train" on some stretch of track, just like KRS counts trains currently.

That's very interesting. Can you elaborate how that might be done?

[AndiS]

When a train passes a signal (or stands within 100 m from a track link), the function OnConsistPass is called for this signal. It receives, among others, parameters "front distance" and "back distance", which is the distance between the track link and the front end resp. back end of the train. Subtracting them gives the length of the train.

Currently, if you pass a signal, it remembers "1 train passed". Then you pass the next signal and it reports to the first one "1 train here" and the first one clears again. If you change that to "X m of train passed" and "Y m of train here", then the first signal would only clear if X = Y. If you leave back some wagons, then X > Y. Initially, some each train will surprise the system with its existence when it passes the first signal. In these cases X = 0 < Y, which needs to be handled by the system, just like it handles it now, when we only count trains.

Of course, shunting signals and call-on signals and the like must leave the next train in even if the block is not occupied, but the normal block signal stay at danger at the same time. Later, when your engine enters on a shunt signal and pulls out the wagons, the "balance" will be positive -- only the engine went in, and the engine and the wagons came out. So the total is zero again and the block signals can clear.

I have this already implemented in a test system, but some tests with complex junctions need to be done before releasing the whole thing. And there are a few bits in the docu which I need to digest/test/integrate first, as detailed in that thread in the signal forum. And then keeping track of the stock is only one of several aspects which must work to provide an overall working system.

[jamespetts]

Andi,

I continue to be very impressed by your ability to invent ingenious workarounds to the most awkward of problems!

However, as ingenious as it is, it is still a workaround, not a solution, for a problem that should never have been there in the first place. It is not a case of mere incompleteness - it is that the basic design principles are fundamentally flawed from the very start. Mere pressure of time cannot excuse such errors, since nobody should ever have started designing a signalling system that way: so much is overwhelmingly obvious.

And of course, there's still no possible solution (or workaround) to the problem of the lack of proper route locking/interlocking.

[jamespetts]

After the release of the developer tools and their associated documentation, it is pertinent to return to some of the issues in this thread that were specifically postponed for discussion until after that release.

Once people have the signal document, read and understood it and what can be done, then we can take the signal subject from there.

Given that it is quite plain, having seen the documentation, that the two critical issues that I raised: the lack of direct, as opposed to deduced train detection (track circuits); and the lack of interlocking/route locking at junctions, are not addressed to any extent in the signalling documentation that comes with the developer tools, we are no further forward now than we were when I wrote that e-mail in the first place. I don't see how waiting for the developer tools and documentation has helped matters. There were no hidden function calls in the API after all.

Having read through james post, and admitting that I had seen this communication from him to Derek previously, but been to busy to fully take in the findings, I am just not sure how to respond – There’s no quick answer.

I will be attending the Flight & Train Simulation show in Birmingham on November 17th and will be more than happy to discuss these issues in person.

I doubt that I'll be able to attend that, I'm afraid.

In an attempt to summarise an answer, here are some pointers:
• We accept that there has been a lack of early documentation on signalling which has lead the community to misjudge Rail Simulator, when clearly so little is known and understood about how things work under the hood.

We don't seem much further forward on this issue: the released documentation has given not much more information than AndiS was able to deduce from looking at the scripts, and certainly nothing that addresses the main concerns. Are there any remaining undocumented function calls in the signalling API, or do we have everything that there is?

• We admit that some important signalling operations were not included in the default routes, this is not because we did not know about them it was a choice, just because something isn’t present, don’t assume it is not achievable.

The important things do not appear to be achievable by looking at the signalling documentation released on Monday any more than they do by looking at the default routes.

• It would also appear that we mis-judged how much of the basics we needed to implement and how much should be left for the community to play around and come up with. After all we wanted a simulation that will grow, not just by us at RSDL but by you guys too.

The community can only come up with things in so far as Rail Simulator is flexible enough to allow it. The community cannot solve basic problems in signalling if such solutions are not possible (or, alternatively, not practical: one cannot sensibly expect users to place track links every two hundred meters for each and every signal placed, as is implied by AndiS's workaround) with the basic executable code provided. That much should have been obvious from the very start.

• There is wide spread confusion over which systems govern what operations in Rail Simulator, which again is not due to the software, but due to the lack of time that the community has had to understand just how things work. Thus more time, interaction with the development team, and documentation about these systems when they are released will resolve most of the problems people are concerned about.

Unless I am missing something specific (in which case, please tell me what it is), nothing released in the developer tools documentation takes us any further forward with track circuits and route locking. Are those important and basic functions possible without absurd workarounds involving manually placing track links every 200m with Rail Simulator as it stands or not? If not, do you acknowledge that the absence of such basic functionality is a serious deficiency, and plan to address it in a future (not necessarily the first) patch? If not, why not?

Since release of Rail Simulator we have had meetings in person with people from this forum who were concerned about the state of signalling, and every one of them has been pleasantly surprised about the state of things once the full picture could be realised and understood. We only wish more people would give us the benefit of the doubt as we simply could not cope with getting everyone of you down to Guildford to chat with us personally.

Why on earth can you not make public to everybody this information that you are imparting to the people that you have invited to Guildford that has made people pleasantly surprised? Surely it would take far less time to tell everybody on your website, or on this forum, than to invite several people to Guildford and tell them in person one by one. I had hitherto assumed that the information in question was information contained in the developer tools documentation: if it was, people cannot have been pleasantly surprised about a solution to track circuits and route locking because the documentation contains no such solution.

All in all, as far as I can see, the responses to my original points do not make any sense at all in the context of the documentation that has actually been released. Am I missing something, or have Adam and Derek not understood my original points?

[AndiS]

Maybe someone brings a notepad and asks Adam to report on the signalling API from memory. That would save RSD employees some time. But it is not the best practice in documentation generation (although not a rare practice).

While I still think that the document on signalling was prepared with effort and care, I am certainly disappointed that there was not much new information in it, and not a breeze of a reference manual. But I should not repeat what I said in the signalling forum.

Just this: Please, bring along the full list of API calls and their parameters and return values, and meanings of the same, plus the list of included functions from the standard libraries, and a description of the inner logic of the AI dispatcher, so we can find ways to make him act the way we want it.