Andi's Signal Scripts (W.I.P.)

Use this forum to show off your hard work to the other visitors of this site.

Andi's Signal Scripts (W.I.P.)

Postby AndiS » Fri May 09, 2014 1:23 pm

Feeling that it might be better to have vapour ware instead of haze ware, I herewith lift the haze from what I have been doing signal-wise.

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.
All signals write extensive logs but I have not yet written the program that automatically checks them against a rule base to detect fishy sequences of events, i.e., signal aspects that do not match train movements. It is impossible to guarantee proper working of a complex system like this without sending loads of AI trains through complex track networks and analysing how they did it automatically.

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.
This resembles placing 1T shunting signals for otherwise unsignalled paths, which is not supported by my scripts.

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.
Last edited by AndiS on Sun May 11, 2014 10:08 am, edited 2 times in total.
AndiS
Top Link Driver!
 
Posts: 736
Joined: Wed Apr 09, 2014 5:48 pm
Has thanked: 268 times
Been thanked: 308 times

Re: Andi's Signal Scripts (W.I.P.)

Postby rivimey » Sat May 10, 2014 1:30 am

Wow Andy, that's a lot of really good stuff you have hiding there! If you're not ready for release, perhaps a video demo of some of your tests might be nice way to show it off?

Regards
Ruth
rivimey
Fit for Firing Duties
 
Posts: 43
Joined: Sat Apr 05, 2014 6:59 pm
Location: Cambridge
Has thanked: 17 times
Been thanked: 12 times

Re: Andi's Signal Scripts (W.I.P.)

Postby JamesLit » Sat May 10, 2014 10:01 am

Blimey, to heck with any scripting efforts of my own, I think I'll just stick to making the signals themselves! This is all absolutely fantastic Andi, you must be proud. Really, REALLY looking forward to reading/seeing more about this. :D
The Forge Simulation | Like us on Facebook!
Owner & Director | Content built with care, not compromises.
User avatar
JamesLit
Driver
 
Posts: 370
Images: 26
Joined: Mon Apr 07, 2014 3:26 pm
Location: Kent
Has thanked: 433 times
Been thanked: 141 times

Re: Andi's Signal Scripts (W.I.P.)

Postby JasonM » Sat May 10, 2014 6:04 pm

Excellent stuff Andy, I like the "Nothing clears for the opposite direction as the train passes", that is one(not the only one)thing that I hate to see in TS.
Looks like you are doing some great stuff within the limatations of the simulator.
It would be good if there was an option like with Zusi that you could state what percentage of the time could the signal be at red so that even if you play the same scenario twice the signalling won't always be the same.
JasonM
Full Time Fireman
 
Posts: 80
Images: 13
Joined: Wed Apr 30, 2014 7:26 pm
Location: UK
Has thanked: 13 times
Been thanked: 13 times

Re: Andi's Signal Scripts (W.I.P.)

Postby AndiS » Sat May 10, 2014 6:31 pm

Thanks for the encouragement!

rivimey wrote:If you're not ready for release, perhaps a video demo of some of your tests might be nice way to show it off?

I will stick to sceenshots for now so as not to distract me with yet another new thing. And maybe release some test routes. I would not have done it on UKTS for fear of complaints "this is not a real route, this is a joke". But here, it should be fine if I attach a few warnings.

JamesLit wrote:I think I'll just stick to making the signals themselves!

I will describe the signal builder soon. Basically, you describe the bits and pieces in a few tables (Excel sheets stored as tab-separated text, could be written in a text editor, too) and then you enter a table describing the signals you want. A Perl script invoked from the DOS command line takes the tables and produces .bin files to copy into the Assets folder.

Parts basically are arms, dolls, ladders, and balance weights and motors if you like. The output is a group of dolls with arms but without support. The route builder places them on a bracket or bridge of their choice (often two on one support structure).

JasonM wrote:I like the "Nothing clears for the opposite direction as the train passes", that is one(not the only one)thing that I hate to see in TS.

That was one of the reasons to start it all. The other was this difference between showing clear and reporting back clear that made you run against signals that know that there is no reason not to clear and are even announced as clear but the visual representation is still at danger. But you open a can of worms wherever you treat. In the end, you got a bag of features like the one above.

JasonM wrote:It would be good if there was an option like with Zusi that you could state what percentage of the time could the signal be at red so that even if you play the same scenario twice the signalling won't always be the same.

It is on my list of ideas for scenario-specific signalling objects. I will update the original post to link to there, as that list is hidden in another thread, and it is what made me believe in the signal scripting venture now.

I proposed this scheme long ago :- no AI on player path but random delays faking a train or some delayed shunting movement 2 miles ahead. But people said they needed the thrill of watching trains cross their path. Nothing against that, except that it is the same thing every time and if you are late or early, the scenario is wrecked.

The beauty of invisible "modifier objects" as I called them previously is that you can put them where you like and the signal scripts are nearly not complicated by such extra features. Now that they can be scenario-specific, you can run the same route in various modi :- following AI, random delay in clearing, random number of signals not clearing before you reach a certain spot (the location of the modifier object, so you can even vary that, per signal/scenario.

Edit: fixed BBCode for link.
Last edited by AndiS on Sat May 10, 2014 8:16 pm, edited 1 time in total.
AndiS
Top Link Driver!
 
Posts: 736
Joined: Wed Apr 09, 2014 5:48 pm
Has thanked: 268 times
Been thanked: 308 times

Re: Andi's Signal Scripts (W.I.P.)

Postby JamesLit » Sat May 10, 2014 6:44 pm

AndiS wrote:Thanks for the encouragement!


Well deserved!

AndiS wrote:
JamesLit wrote:I think I'll just stick to making the signals themselves!

I will describe the signal builder soon. Basically, you describe the bits and pieces in a few tables (Excel sheets stored as tab-separated text, could be written in a text editor, too) and then you enter a table describing the signals you want. A Perl script invoked from the DOS command line takes the tables and produces .bin files to copy into the Assets folder.

Parts basically are arms, dolls, ladders, and balance weights and motors if you like. The output is a group of dolls with arms but without support. The route builder places them on a bracket or bridge of their choice (often two on one support structure).



I meant geometry and textures etc specifically. I'd be happy to contribute some bits and pieces like that if I could find/be given some reference. That signal builder is absolutely fantastic though, it'll make things so much easier for me and countless others!
Last edited by JamesLit on Sat May 10, 2014 9:39 pm, edited 1 time in total.
The Forge Simulation | Like us on Facebook!
Owner & Director | Content built with care, not compromises.
User avatar
JamesLit
Driver
 
Posts: 370
Images: 26
Joined: Mon Apr 07, 2014 3:26 pm
Location: Kent
Has thanked: 433 times
Been thanked: 141 times

Re: Andi's Signal Scripts (W.I.P.)

Postby JasonM » Sat May 10, 2014 7:58 pm

AndiS wrote:
JasonM wrote:It would be good if there was an option like with Zusi that you could state what percentage of the time could the signal be at red so that even if you play the same scenario twice the signalling won't always be the same.

It is on my [url]list of ideas for scenario-specific signalling objects[/url]. I will update the original post to link to there, as that list is hidden in another thread, and it is what made me believe in the signal scripting venture now.

I proposed this scheme long ago :- no AI on player path but random delays faking a train or some delayed shunting movement 2 miles ahead. But people said they needed the thrill of watching trains cross their path. Nothing against that, except that it is the same thing every time and if you are late or early, the scenario is wrecked.


Great stuff, of course there are many times that a train could get checked down and it seems to the driver there is no reason but as an example it could be level crossing gates/barriers being closed late after train has passed the distant signal due to problems at the crossing or a slow person/car, also signalman/lady in the toilet and taking longer than planned(it does happen), farmers crossing at user worked crossings with cattle etc and taking longer to call back to say crossing is clear meaning train possible approaching a red by now, points problem which self rectify just as train approaches red signal, that is just a few examples but there are more.
JasonM
Full Time Fireman
 
Posts: 80
Images: 13
Joined: Wed Apr 30, 2014 7:26 pm
Location: UK
Has thanked: 13 times
Been thanked: 13 times

Re: Andi's Signal Scripts (W.I.P.)

Postby AndiS » Fri Nov 20, 2015 3:27 pm

Torn between Show Room and Route Building, I ended up placing the thread about the outcome of the above there.

In short, the unbelievable happened today - I uploaded something! Last time that happened was 2008 and then it was just repackaged documentation from RSDL.

I suggest continuing the discussion in the other thread.
AndiS
Top Link Driver!
 
Posts: 736
Joined: Wed Apr 09, 2014 5:48 pm
Has thanked: 268 times
Been thanked: 308 times


Return to Showroom

Who is online

Users browsing this forum: No registered users and 2 guests