Atomic Systems

jamespetts wrote:

AndiS wrote:"7. AI trains ignore gradients" L (they reportedly ignore their load, too)

I have just done some carefully controlled testing. I can confirm that they definitely ignore gradients, but do react appropriately to loads.

Glad I wrote "reportedly" ... I did not run tests myself, just read someone else's strong claim ...

New items:

The signals do not know about the intent of movements. L
The scenario engine knows whether a train performs a "stop at" order or a "consist operation", but it does not tell signals. Also, signals do not know whether a train terminates where it is (or continues the travel in the same direction). Also, they do not know whether the train will stop here (and no one knows what happens to the overlap in such a case). In short, the AI dispatcher must tell each signal either "clear for train" or "clear for shunting movement", otherwise the show aspects can only be guesswork.

Ahh, this is the same as route locking, isn't it? Certainly in British practice, the system is that the booked path of the train (or an alternative path chosen by the signalman if there is a reason to deviate from the booked path) determines the route that is locked through a section. The locked route sets all the points to what they need to be to allow the train to take the desired path, then prevents any conflicting route from being locked through the same junction, then allows the signal protecting that section to clear, provided that there is no other train in that section taking the same path (a route can be locked through a section even if there is already a train in it, but only if the train is on the same path, and in any event the signal will not clear until the train is out of the section). So, the route locking suggestion covers this.[/quote]
As far as I understood, the issue of route locking concerns just the fact that you prevent other train movements to endanger the one for which you just clear the signal.

What I mean here is that the dispatcher's/signaller's/schedule maker's intent is completely unknown to the signals. Assume a train arrives at a platform, there are different things it will do next.

a) Move on as a whole - normal starter (block signal) needs to clear. Next order on the scenario's todo list for this engine is a stop order for a station ahead.

b) Engine uncouples and runs around - shunting signal needs to clear, starter remains at danger. Next order on the list is a consist message (uncouple from all wagons and couple them to the other side).

c) Train returns to where it came from (without engine running around, because it is a DMU or similar) - clear starter for opposite direction, leave starter for original direction at danger (and shunting signals, too). Next order is a stop at order for a station in the other direction (AI dispatcher must realise this change in direction, it's part of his job).

Similar if there is a train at a platform, and another one halts before the (home) signal protecting it. If these trains are to unite, or halt behind each other at the same platform, then clear the call-on arm. If the second one just has to wait, or if it will be routed to another platform, you certainly should not clear the call-on arm.

* they are not configurable beyond setting the links. Signals are far more complex, especially, if they have to implement signal box logic (as a consequence of the general lack of it in the game)

I'm not sure that I quite follow this - can you elaborate?[/quote]
In Trainz (I think), and in Zusi, if you place a signal you get a dialogue box asking you for a few parameters, like (for UK junctions signals) "Approach control: none, from red, from yellow, from double yellow", or a list of all possible feathers where you tick off the ones you want. Since KRS does not allow this, you need to produce tons of signals to cover each of the many combinations. E.g., 6 feathers would give 2^6 combinations. If you consider half of them realistic, you have 32, each of which have four different modes of approach control, giving 128 different signals, and that only gives you uniform approach control for all branches of the junction which is poor.

Not sure where to place this issue, do you have a "pain in rear" department?

Update

I have added one new sub-critical issue (manual editing of timetables) and three new non-critical issues (train roster, signal parameterisation, and dynamic changing of service name).

AndiS wrote:As far as I understood, the issue of route locking concerns just the fact that you prevent other train movements to endanger the one for which you just clear the signal.

What I mean here is that the dispatcher's/signaller's/schedule maker's intent is completely unknown to the signals. Assume a train arrives at a platform, there are different things it will do next.

a) Move on as a whole - normal starter (block signal) needs to clear. Next order on the scenario's todo list for this engine is a stop order for a station ahead.

b) Engine uncouples and runs around - shunting signal needs to clear, starter remains at danger. Next order on the list is a consist message (uncouple from all wagons and couple them to the other side).

c) Train returns to where it came from (without engine running around, because it is a DMU or similar) - clear starter for opposite direction, leave starter for original direction at danger (and shunting signals, too). Next order is a stop at order for a station in the other direction (AI dispatcher must realise this change in direction, it's part of his job).

Similar if there is a train at a platform, and another one halts before the (home) signal protecting it. If these trains are to unite, or halt behind each other at the same platform, then clear the call-on arm. If the second one just has to wait, or if it will be routed to another platform, you certainly should not clear the call-on arm.

Route locking would work like this: the pathing engine would say to the signalling engine, "I want route X in section Y". The signalling engine would either say "yes", and set that route (importantly, including the direction of that route), or "no", in which case the pathing engine would keep trying at pre-programmed intervals until the signalling said "yes".

The signalling engine would say "no" for any of the following reasons:

* there is a conflicting route set;
* there had until recently been a conflicting route set, which was cancelled, and the time lapse after cancellation has not yet expired;
* there is a route set in a neighbouring section with a conflicting overlap; or
* a train with a higher priority is about to request a conflicting route to be set.

A route might be set to either a signal at the other side of the section, or some stopping point in the section. If it is the latter, then, once it has stopped at that point, a further route would have to be requested and set in order for the signals to clear.

The fact that there is already a train in the same section travelling in the same direction on the same path would not stop the route from being set, but the signal protecting that section would not clear until the train had left that section.

I hope that that system covers everything - tell me if it doesn't

In Trainz (I think), and in Zusi, if you place a signal you get a dialogue box asking you for a few parameters, like (for UK junctions signals) "Approach control: none, from red, from yellow, from double yellow", or a list of all possible feathers where you tick off the ones you want. Since KRS does not allow this, you need to produce tons of signals to cover each of the many combinations. E.g., 6 feathers would give 2^6 combinations. If you consider half of them realistic, you have 32, each of which have four different modes of approach control, giving 128 different signals, and that only gives you uniform approach control for all branches of the junction which is poor.

Not sure where to place this issue, do you have a "pain in rear" department?

The "sub-critical" or "non-critical" depending on the extent of the pain I have added that one to "non-critical".

jamespetts wrote:Ahh, overlaps They didn't make it into Railway 3d, and they are, if I recall correctly, a fairly recent invention. I'll put that into the sub-critical list, since I know that they're important in modern practice. As to the correct distance between signals for the speed of the line, the most realistic solution is to leave that to the route designer: that is how it is done in real life, after all.

I don't know what you consider as recent. But I would guess that overlaps exist at least for 50 to 100 years. Maybe mechanical signal boxes didn't have it (since they have a time component), but it should have been possible with electrical (relay based) signal boxes.

jamespetts wrote:

* they are not configurable beyond setting the links. Signals are far more complex, especially, if they have to implement signal box logic (as a consequence of the general lack of it in the game)

I'm not sure that I quite follow this - can you elaborate?

Andi already explained it a bit. In Germany, it is possible to combine home and distant signals (for the next one) at a single post. Each signal can be configured with different lights. Combining all (including the more exotic ones) results in more than 100 combinations. But that's not all. There are additional signals that may be mounted on the post, like speed signals (up to two, each showing numbers from 1 to 16) and destination indicators (showing letters A to Z depending on the chosen route).

So you simply cannot pre-create all possible combinations. Either you have a way to configure a signal within the game itself (e.g. tell the signal to show letter "G" on link 3, but letter "E" on link 2) or you have to create a tool that allows the user to individually construct a signal (outside of the game) for a specific location on the route and import it into the game. The latter one is surely not a satisfactory solution.

Klaus

Overlaps (in the UK at least) are certainly far from a 'modern' development. One of the key principles of Absolute Block working going back 100 years or more, was (and still is, more or less) the requirement to have the line clear up to the clearing point before accepting a train from the box in rear. The clearing point would generally be 440 yards beyond the home signal. It might not be called an overlap, but it performs much the same function!

Re. route locking: The way you describe it, it (mostly) includes what I meant. I understood it as a model of the interlocking itself, without the signaller, but you clarified that. Anyway, the one change I suggest is:- Change "I want route X in section Y" to "I want a route from signal X to point Y" where point Y (as you explain below) is either another signal, or another point ("destination marker", so to say). The point is, that you need to distinguish shunting movements from train movements. Sometimes, they have identical paths, but need different signalling (with different implications, namely the shunting movement does not require a clear block). By saying "Home arm of signal A to track B" or "Call-on arm of signal A to track B" you can distinguish the two cases.

Re. overlap: I can confirm that it is basically ages old, but due to "hardware limitations", the implementation in practice relied mostly on the responsible action of the signaller, until they invented electronic (or very sophisticated electric) interlocking.

Tomnick wrote:Overlaps (in the UK at least) are certainly far from a 'modern' development. One of the key principles of Absolute Block working going back 100 years or more, was (and still is, more or less) the requirement to have the line clear up to the clearing point before accepting a train from the box in rear. The clearing point would generally be 440 yards beyond the home signal. It might not be called an overlap, but it performs much the same function!

Ahh, thank you. Reference to "recent" removed. I do remember reading somewhere, though, that overlaps were a consideration recently in a way in which they were not in the past. Perhaps the rules have recently become more strict about them.

AndiS wrote:Anyway, the one change I suggest is:- Change "I want route X in section Y" to "I want a route from signal X to point Y" where point Y (as you explain below) is either another signal, or another point ("destination marker", so to say). The point is, that you need to distinguish shunting movements from train movements. Sometimes, they have identical paths, but need different signalling (with different implications, namely the shunting movement does not require a clear block). By saying "Home arm of signal A to track B" or "Call-on arm of signal A to track B" you can distinguish the two cases.

Will do, and will add the information on the detail of route locking.

Update

Added a new critical issue: AI trains ignore signals.

Update: Added new sub-critical issue: train speed limits.

James

After reading your exhaustive list it almost feels like the way things stood after Trainz 1.0. Many of these issues were raised in Trainz AI about 4 years ago and were subsequently addressed. The individual vehicle speed limit issue was finally addressed recently it looks like in Trainz Classics. I am afraid you may well be looking at similar time lines with RS although I hope not. I still don't see how RS can "fix" the AI to work right with so many fundamental flaws. I just don't see RS being a railway network simulator in the forseeable future.

Update: Added new sub-critical issue: cargo weights.

Update: Added new non-critical issue: multiple locomotive train performance.

Update: Removed reference to crashing on non-slip crossovers in consequence of absence of route locking following information on a hitherto unknown feature documented publicly for the first time to-day (3.02 - signalling interface parameters).

Update: Added sub-critical issue: scenario diagnostics.

Update: added link to detailed suggestions about how to address critical issues nos. 1 and 2 (direct detection of track occupancy and route locking).

Update: Downgraded "flying to destinations" from sub-critical to non-critical having found and documented this workaround.