Scripts for Freeware Pack Signals

[Widewanderer]

Good morning from Western Canada, Andi - where I am waking up to news of your new scripts becoming available for test

Realistic signalling is definitely my "thing" in TS20xx, as you probably already know, having been a signalman for a while on the West Somerset Railway (albeit some while ago...!) It's Saturday, so I'll set about downloading your pack asap (laundry and food shopping notwithstanding!) and clear the rest of the weekend for having a "play"

I've been really looking forward to this one, Andi - I'll PM you and post here with some feedback. Meantime, thanks for all your help

Best wishes,

[Widewanderer]

No signal clears for the opposite direction as the train passes, unless the player presses TAB/Shift-TAB for that direction. When a train approaches a signal that is not prepared, it prepares. This is useful for reversing AI, and for freeroam.

This is most significant for me, Andi - It's long been my biggest gripe in TS, signals automatically clearing unnecessarily when passed in the reverse direction. Mark Brinton's scripts solved this, but lacked the facility of the TAB/ctrlTAB key press to clear that signal when consciously making a reversal in a loop or platform, say. It is necessary to actually move the train towards the signal in rear to get it to clear, though (not so realistic!) I am sort-of learning how to read .lua script - I'd love to be able to learn how you have achieved this little bit of functionality, Andi...

I've done a lot of resignalling on semaphore routes (eg WLoS) using Mark's scripts - do you have any thoughts on compatibility between your scripts and Mark's? If your scripts and his do mix happily, then it opens up the possibility of throwing in a couple of CLS in areas where I now have Mark's semaphore code installed, without too much extra work: Another level of realism! If that isn't possible, no worries, as you have both CLS and semaphore in your pack; I'll devote my attentions in that case to adapting your scripts to existing signal models I have downloaded (I'm not an actual 3D modeller, you see; I just play around with the blueprints to create custom signals for routes, or for re-scripting. Just for my own amusement, let the reader understand ...)

OK, I'm off to download your pack...

Cheers!

[AndiS]

Sadly it is not a little bit to find a solution to clearing signals correctly. This mostly shows how bad the game is designed and to a lesser amount how much scripters achieve.

Basically, you have three options:

1) Assume the train will return at every signal. Looks stupid 99% of the time.

2) Assume the train will only return when you see it does. Looks stupid 1% of the time, when you have to start your train against the closed signal.

3) Introduce objects that tell the signals what the train will do (named movement predictors by me). Only if the scenario author places such objects (and they exist in the first place), you get a chance to keep signals closed that should be closed and to clear signals without the train starting the reversing movement.

A similar situation exists on scenario start-up when signals at both ends of every single consist are invited to clear, even if there is no engine in that consist. Only a small part of these signals clear rightly, but if none clears, it confuses the player. Again option 3 is the way, but it requires a lot of things set out first.

For the automatic clearing when the train approaches, you find yourself between a rock and a hard place again. If you set the distance at which the signals clear to something low as 100 m, the driver needs to initiate a stop before finding out whether the signal clears or not. If you set it to something like 400 m, then every movement in that direction will trigger the signal, including some shunting on the other end of the track.

Mark opted for 100 m throughout, I opted for 100 m when the signal does not have a distant arm and 400 m when it has one. I put some naive hope into this (assuming that distant arms will be more frequent at advanced starters where shunting is less frequent) but basically, it did not get too far.

When you approach a distant signal at speed, you want to clear much farther away. But if you extend the 400 m, you get beyond the signal in approach which means a train stopping there sees the signal beyond the closed signal clear - very bad.

So I opted for clearing one extra block once you move. Preparation needs to be done signal box by signal box anyway. I.e, when an outer distant senses a train, the all the signals up to the section signal of that box must clear in order for the distant to clear. Since each signal arm starts the animation only after the one in advance completed, this can take a few seconds. This is why I currently clear to the starter of the second box, not the first one.

Now you ask why I fuss about this auto-clearing if I got movement predictors. You need a delicate balance. Neither route builders nor scenario creators want to place tons of these objects. So the rule is that you only place one where something special happens -- a reversing movement or entering occupied track. Or stopping dead. The manual spells out how you end up having 10 cases.

Each object is for just one train pass. If two trains pass some place and you need predictor action for both, you place two objects. That way, the scenario author easily sees which movement they predict. Originally, I wanted to have single uniform objects and you would enter the details by a sequence of these 10 characters. But people would have killed me, so I put on my artist head and designed the colourful stuff spread in front of the signals on the picture shown at the thread start.

Each object has a five-stage life cycle.

Initially, it waits for the preparation message.
Then, it waits for the train to arrive.
Once the head passes the track link, the predictor starts monitoring for a possible stop on the link.
After the train stopped or passed in full, action takes place.
Then the predictor waits for the train to leave in case of a stop.
Then it hands over command to the next one and unlocks locked signals.

Action means sending some flavour of preparation message in some direction (which is half the difference between the 10 versions). Initially, some more messages are sent to keep signals from clearing too soon and to tell other predictors to shut up until this one is done.

There are some versions that skip a state in the above list, which makes for the rest of the 10 versions. Like passing through without hesitation versus only clearing when the train is here.


Of course, signals need to react to the messages from movement predictors. This is why prediction will not work with other signals.

Mark developed his own ideas for some of the things that need to be fixed. My signals do not cooperate with his extensions.

One thing to understand is that in this game, all the signals (and extra signal-like objects) form a large distributed code base that emulates those parts of the game that got left out: signal box, schedule, signaller. Signals are by means isolated objects. Not in the prototype, but ten times less in the game. They are cogs in a clockwork.

The key reason for putting a few extra months into CLS although they are not my main interest is that I failed to achieve compatibility under any type of set-up. I just came up with some filter object for easy cases. Imagine my face when my signals cleared for the wrong direction when placed near a Kuju signal! That is avoided now but diverging routes are not supported at the filter unless someone cries for them loudly.

[Nobkins]

At any rate, most of the long post is in Introduction.pdf in the download, so people will come across that sooner or later.

Ahh good stuff. No problem then I will leave as is.

[AndiS]

I just found out that the comment line at the start of most scripts under FPKuju is nonsense. This results from hastily copy-pasting. I fixed that now so not to confuse aspiring scripters.

There were two little bugs that involved a wrapper and an inner home between outer home and starter when the starter is a bracket and the outer home is approach controlled for the diverging branch and has a custom approach speed set. I fixed that, too.

I uploaded these fixes together with some cosmetics as "First Update to Version 1.0.3" so you don't need to re-download the whole 5 MB for these few bytes. It will show up in due time. In case you want to know, Richard was the sole user of version 1.0.2 that had one one of the two bugs fixed.


I also came across the following questions so let me spell out the answers here. They will make it into the Reference Manual later on.

Can I modify the scripts?

Yes, you can modify the Lua files under FPKuju/scripts and republish them as you like. Same for the blueprints under FPKuju.

I do not recommend messing with FPSignals. Every bit of it is intertwined with three other bits. As a primitive indication, my code as three times the lines of the Kuju code. I also showed how simple things get complex in the post before, concerning clearing at the right moment.


Can I have more than two arms?

Sure. The oldest file is called Universal Semaphore hailing back to when hertsbob talked me into creating a stop signals with six arms. The current limit is 9 stop arms and 5 distant arms per stop arm.


Can I have stacks of disks?

Yes. I assumed 4 would be enough but 9 are possible, too.
Note that you can have an indicator at disks. Actually, more than one, if you like.


Where are the yard links?

You don't need them. Make the arm into the goods loop a Permissive Section Signal. For collocated disks implementing external "arms", this is the default.

You are better off when you place a few wrappers in sidings that would go unsignalled with the default signals. AI will reward you by not derailing or crashing on the switches concerned.


Where is the automatic block signal?

I forgot it. To maintain equal rights for semaphores, I might add a scenario-specific object that tells a signal box that it is temporarily closed, locking its semaphores in the off position. But maybe that is another gimmick that no one uses in practice.


What about these letters in the character column in the signal properties?

Section 3.1 is a fat one, so let me put the gist here.

Section signal = last signal at a box, just before you enter the block section.
Home signal = any other stop signal.

You don't need configuration for the following:

A section signal with a stand-alone distant in advance.
A section signal with the route end in advance.
A section signal with a distant arm or a yellow light.
A home signal without distant arm nor yellow light.
A collocated disk that leads into a goods loop under permissive block working.
Modern CLS are section signals with rare exceptions when the spacing is insufficient.

If your signal does not fall under one of these categories, you will most likely need one of these:

a - Section signal with inner distant or not distant arm (no yellow light).
f - Home signal with an inner distant arm, or a yellow light but insufficient distance to the next signal.
g - Home signal with outer distant for the next box.
t - Permissive block signal in the middle of a goods loop. In practice, p and q are fine, too.

[Widewanderer]

That's a very well thought out post, Andi, setting out your thinking about what signals do, or assume, when passed in reverse directions. Your solution of using the movement predictors to tell the signal about what the train is going to do - reverse or otherwise - is very much the way forward, methinks. It's a little bit more work for the scenario writers, but well worth it. I'm certainly up for it!

The process of adapting the little bits of lua script for each (type) of signal model is proving much easier than I thought - so far, I have Anthony Braillsford's home signals, both plain stop arms and with calling-on arms, up to four routes, working splendidly with your scripts, Andi. I have also found the "Limit to yellow" toggle useful for getting the calling-on arm to clear properly when entering occupied dead-end sidings or platforms in standard scenarios (at least, in my little test scenarios...), without resorting to movement predictors.

These scripts are, so far, just what I've been waiting and hoping for. Great work, Andi, for which I cannot thank you enough.

[Widewanderer]

The automatic block signal is definitely something I would find attractive in scenarios. In times of tight budgets, it was common for the railway to switch out signalboxes, and it would be great to be able to simulate this. I don't think I can ever remember boxes such as Torquay or Dawlish, for example, being open and operational in the latter days of semaphores in south Devon...!

Thanks for the digest of FAQs in your last post. Definitely a help in learning your new system.