The Hell of Dependent Disks - Paddock Wood

[MrGronx]

Hello All!

I'm signalling Paddock Wood, and there is a single dependent disk (signal 53) that will not work no matter what I think up. I'm throwing this out to the floor here to see if you guys can get any sense out of it.

This is what I am attempting to signal here:

I have set up the gantry signals like so:

And this is how the dependent disk (signal 53 in the diagram) is set up at the moment:

I have set up the script for the dependent disk as follows:

Code: Select all

require "Assets/AndiS/FPSignals/scripts/FP Facing Disks.out"

function Initialise ()
    DefaultInitialise()    -- no need to give the route count here

    gArmTable[1][ARM_HOME][SEM_CHILD_NAME]          = "ARM_HOME"
    gArmTable[1][ARM_HOME][SEM_PROCEED_ANIM]        = "Clear01"
    gArmTable[1][ARM_HOME][SEM_BLOCKED_ANIM]        = "Stop01"

end

In this stage of the game, the dependent disk (signal 53) will not clear, and neither will the main stop arms (signals 79 and 81). I know that I am doing something wrong here, but I'm too in the deep end here to work out what's wrong. Any help I can get here would be greatly appreciated.

[FoggyMorning]

Forgive me if I'm barking up completely the wrong tree here, I've never delved in to using AndiS's signals, but it looks like you have multiple signal links placed along the same paths. With "traditional" signals, you can only have one link per path or the whole system throws a wobbly. Where there are multiple possible "sub-paths" between signal and destination you can in some instances set the track directionality to force the desired routing, in others, additional (and in this case unprototypical) signals may be needed between the main signal and the destination.

Again, I'm only going on my own experience with more limited signal functions. Hopefully Andi will be along with some thoughts on the specific signal scripts you're using .

[MrGronx]

...it looks like you have multiple signal links placed along the same paths.

Don't worry about those - those are "inner links" which are imperative to how the AndiS signalling system works.

[AndiS]

The links of the main signal should not wrap the indepenent disk.

In the straight track, you only need the first link, right after the diverging switch.

To make sure that arm 1 only clears for the straight route, put 1 into the route character of the disk, at link 1 and 2 at link 2 there. This will cause the disk to report these routes. Default behaviour is not to influence the route shown at the main signal.

You need inner links beyond a converging switch and in approach to a diamond.

Thus I would move the link of the disk beyond the diamond nearer, do be on the approach side of the diamond. The diamond seems to send a "path broken" message against the direction of travel to links pointing at it. So your inner link will not get it where it is now. But it is a rare case that these messages play a role.

You cannot put 2 characters in the route character in the table in the fly-out. "1f" will just be eaten by the game. I am not sure whether it will give the signal "1" or nothing. 1 is the default for link 1 anyway but f is the default when no main signal follows. So you can drop all of 1f.

For the main signal, you have three options that all sound a bit complex.

Option 1: Link 1 in the straight track without any route charcter. Link 2 beyond the trailing switch on the left with route character 3. A sunken distant signal between this link 2 and link 0 of the wrapper ahead to substitute for the "a" character that does not fit into the route character.

Option 2: Link 1 as before. Inner link 2 between the diverging and the converging switch (with route character "-" as you correctly have it). Link 3 beyond the converging switch, where before I had link 2. Now you can put "a" into the route character field for link 3.

Option 3: Both other options assume that the disk sitting on the bracket of the main signal is arm 3 of that signal and that you wand the disk at the bracket to clear when the path left right at the main signal. You can "think out of the box" or "see it logically" and make this disk arm 2 of the main signal. The lower stop arm on the bracket will become arm 3. (This is controlled by the indices in gArmTable.) Now link 2 of the main signal refers to arm 2 and arm 3 is only ever cleared when the dependent disk sends "3". You use "3" as the route character of link 2 in the disk to achieve this.

I am truly sorry not to have a simpler solution for such a situation within the constraints of this game and I surely congratulate anyone for digging through the signalling of such a complex layout.

A final note on the dependent disks: The are just wrappers with an indicator. Use them just like wrappers. I assume you got the wrappers right, at least it looks like they all just wrap one switch each which is a very safe way to go.

Note after the last: The hell arises from the fact that you must control the aspect of the main signal based on information only available beyond the links of that signal. To this end, you put figures into route characters of wrappers of dependent disks and forget about the ambitious spanning of links over great distances. One of the reasons I invented wrappers was that I got tired of dragging about the track links of signals to all sorts of remote locations where they love to snap to the wrong track or slip a bit to the wrong side.

[MrGronx]

Thank you for your response, AndiS. I won't lie that I feel a bit at sea here, but that's more a reflection on my (lack of) intelligence! However, I have made some progress. Using a test route with an identical track layout (ignore the terrible point rendering), converting the gantry signals to a 3T and using option 2, and replacing the dependent disk (signal 53) with a real shunting signal, I have got a semi-satisfactory response. The new problem is on the gantry, only signal 79 clears no matter which platform road I direct a train into. I managed to get the gantry shunting dummy working by making the wrappers and shunting signal in the rear of it to send a route number.

I have the gantry signals set up like so (where the second link is the shunting dummy):

This is signal 53 as it is now:

If we can't get it to work like this, is there a way to "cheat" by somehow preventing signal 53 from being affected by messages from/to the gantry in advance of it?

[AndiS]

Maybe all you need is an "a" in the route character of link 1 in the gantry, just like you have it for link 2 of the same signal.

In signal 53, I would replace "f" by "a" für link 2.

If the result is fine, then forget the rest of the theories.

[MrGronx]

No joy, I'm afraid: if I put route character "a" in the gantry's link 1, signal 53 refuses to work like it should.

I'm very tempted to leave it out - I've been fighting this signal layout for months and it only works properly if I don't include signal 53.

The only way I can see this working is if there was a way I could have signal 53 without sending messages to the signals in advance or to the rear of it. Otherwise, we'd have to go without that shunting signal.

[AndiS]

"a" in the route character of link 1 in the gantry was my mistake - I forgot that you substituted the dependent disk for a "normal signal". The "a" suggestion is only valid when you have a dependent disk there (or a wrapper).

Since this is just your own hobby route, you definitely fare best when you simplify the signalling until you get a working solution.