Basically, it is my most recent, most modest attempt at knocking up something that does not crash against the limitations of RW but still provides a nice benefit over the default signal scripts. In contrast to my previous projects, I focussed on UK semaphores now, as AI treats each signal as UK semaphore.
Testing occurs on three levels.
- Brute force feature tests (aka branch tests). Boring but unavoidable. Hard to establish that a set of moderately complex tests guarantees the working of the overall system because of the combinatorial explosion of the feature interaction.
- A tutorial route or two. If I cannot convince myself that someone can knock up all the complex stuff I introduced, there is no point in releasing it. There are two things to do actually, provide a gentle introduction into the standard cases and explain plus demonstrate the rest of the features.
- Through a series of twists of fate, Taunton became my reality check. If I can signal that, I know that I have achieved something. At the same time, it keeps me from inventing mad settings that were not found anywhere in practice.
I am a bit weary about the limited uptake (read: less than 100% which would be my estimate) of Mark's scripts, so I struggle to provide something simple. But I don't get far, the prototype is plain difficult and the purpose of all the effort is to do the prototype justice, or else you just stay with the default signals.
I am also a bit more shunting-focussed that the average, which complicated the development very badly. Scenario-specific signals break some spell in this regard because the relieve the burden of guessing what is going on from the signal scripts.
Implemented and tested features are:
- Signals can be outer or inner home, starter or advance starter, and the rules for clearing (rule 39a) are observed. Distants can be outer distants for the next, second or third box, or inner distants. Inner distant arms can also be omitted (as they were at times). Slotted starter&home and permissive working are covered, too. Also paths (through yards or goods loops) for which the distant is not operated. Plus approach control. All this is configured using the route indication letter which means the route builder uses a little look-up table but it cuts down the number of signals in the list. Alternatively, these signal properties can be encoded in the script, which relieves the route builder but blows up the list of unique items.
- Shunting signals that are first class citizens, seamlessly integrated into the message passing circus.
- Warning arrangement (of the overlap at the next home is not clear) and shunt-on/call-on, with and without subsidiary arm.
- Up to 9 stop arms each with 9 distant arms would be supported by the script. So put "unlimited" there. I must say that I never found something that cracked the limit Mark set, but Bob was extremely happy about one home signal with 6 arms and I was very happy to make someone happy with little effort.
- Nothing clears for the opposite direction as the train passes.
- Better signal preparation schemes. I tried to make them compatible with the default signals, but frankly those use quite funny heuristics, so I am not sure I will tag my scripts "compatible with the default" in the end. It was my intention at the beginning, though, to keep people from shying away from this "all or nothing" decision.
- Signals don't get confused by trains straddling links on start-up, or trains returning while on a link, or trains coupling/uncoupling while on a link.
- Multiple links can share the same arm.
- Animated balance weights, if provided by the model. Alternatively "sky arms", properly named co-acting arms, if implemented as copies of the stop arm.
- Signals don't clear for 6 seconds after a numbered link was cleared. The dispatcher waits for 5 seconds after that event before changing switches, so a permissive stop signal would clear for 5 seconds after the first train passed and before the switches it protects are changed.
- All signals can have any number of inner (or special in Kuju terminology) links. These are placed beyond extra trailing switches in the path. So a starter protecting two trailing switches will have link 1 beyond the far switch and an inner link (happening to be numbered 2) beyond the near trailing switch. That way, the signals sees a shunting engine reversing over the near switch without touching link 1 beyond the second switch. Default signals (with the exception of a few "special" semaphores) block in such case, because they miss the fact that the engine is gone.
Implemented but not tested:
- Splitting distants (in countless variants of signal sequences).
- Detecting the reverse movements of consists. This drove me nuts when the project stalled. Scenario-specific signal objects take all the pressure from this. But it would be nice to retain the capability for free-roam scenarios.
Not yet implemented but trivial:
- Scenario-specific markers. They are all a few lines of code, except maybe for wrong-line working, and great fun to do, but require lots of testing, which cannot be automatised where coupling is required.
- Route indicators. Found at Taunton, shape available, but first, I will adapt the signal builder to place them, because I hate manual work including blueprint creation, and I love to implement knowledge in code.
- Colour light distants, yellow disk signals and banner repeaters. Not found at Taunton, very easy.
- A disk signal placed at the post of a main signal as a separate shape (thus positioned freely), which acts like an arm of the main signal.
Not yet implemented but on my must-have wish list:
- Shunting signals in the path of running movements. They are found at Taunton.
- Their invisible cousins could help signal placement :- for complex junctions with multiple approaching tracks, you form a subgroup of a few switches and signal that using an invisible signal. Then you signal the approaches up to link 0 of that invisible signal, which means a drastic link count reduction overall. Arm selection for the running signal would be done in communication with the invisible one. Not a must-have feature, but it would help route builders, and the invisible ones are nothing but a simplified version of the visible ones.
To be implemented in version 2:
- Colour light signals other than the distant. They only require some code reorganisation because the change aspect instantly, so there is no waiting for the animation to complete. Incidentally, if someone had shapes where the switching of lights is implemented as animations, they could be integrated easily. But still, I need to single that out from the first round.
- Better arm animation sequences. Currently, I don't spend effort to make the sequence of arm motions look good. But since the distant arm only clears after the stop arm ahead cleared, you sometimes see the stop arm next the engine clear and then the distant arm and it looks so nice that I want to have it in all cases. However, the internal logic is vulnerable during these periods of change - considering that the user can change a switch at any time. So I am glad enough they work as is, for now.
- Configuration of the time of arm reset. Currently, this is hard-coded at clearing the farthest link. It could be done at lots of other moments, like clearing the overlap, arriving at the signal box. However, I did not rate that too important.
- Since RW4 changed the way of handling TAB presses, I took out all support for that for now. For free-roam scenarios, it might be worth bringing it back. But first, I want to see how scenario-specific signal objects fare in practice.
Now if you ask me how much of that is finished, this is not easy to judge. A branch test for running movement without junctions was completed before the recent hibernation of the project. I am trying to combine the branch test for the junction signalling with my (rather schematic) representation of the Taunton track work.
Giving an estimate as to how many signals work there (at Taunton) as of now is difficult because of the wide range of complexity of signals found there. It is also impossible to judge their working without a systematic analysis of the log files. But I did try to restrain myself to just make them all clear for my train, for any path of my choosing and stay with that. I will report when that has been achieved. But "worked once" is not the same as "works still" and to establish the latter you need to send AI trains through all the paths and analyse the log file because setting 3 or 5 paths for several dozens of signals is something you don't want to repeat.
The demo route is in is infancy, but clearly, it will be tracks only, thus much faster to knock up than its description. The main challenge there is to restrict it to something people will want to digest, as all the signal variants meet with the possible movements at each signal box, so it grows into an epic saga in no time.
Edit: Added link to scenario-specific signal objects.
11 May: Added features 6-second delay and inner links.