Distant gantry junction signal

[albinopigeon]

I'm working on my signal kits again. I've managed to get a junction gantry signal working, and figured out setting up more exits than posts, but I am currently struggling with a distant gantry junction signal as seen in the picture below.



My philosophy was to copy the home gantry signal and change the arms to distants and use this code instead:

require "Assets/AndiS/FPSignals/scripts/FP Universal Semaphore.out"

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

gArmTable[1][ARM_DIST][SEM_CHILD_NAME] = "ARM_DIST1"
gArmTable[1][ARM_DIST][SEM_PROCEED_ANIM] = "Clear01"
gArmTable[1][ARM_DIST][SEM_BLOCKED_ANIM] = "Stop01"

gArmTable[2][ARM_DIST][SEM_CHILD_NAME] = "ARM_DIST2"
gArmTable[2][ARM_DIST][SEM_PROCEED_ANIM] = "Clear01"
gArmTable[2][ARM_DIST][SEM_BLOCKED_ANIM] = "Stop01"

end


Is there anything I might be doing wrong?

Thanks,

Joe

[AndiS]

I love up-to-date texturing! Where is the drool emoticon?

You simply got the wrong script. Those stand-alone distants have their own scripts. The information is a bit spread out all over section 8 in the manual.

8.2 gives you the name, FP Semaphore Distant Script.out for the distant in place of FP Universal Semaphore.out for the semaphore stop signal.

8.4.3 tells you to get rid of [ARM_DIST] in gArmTable. Distants have one dimension less in their gArmTable since they only ever carry distant arms. Other than that you are fine.

There would be FP DD.lua in Assets/FPKuju/scripts for an easy starting point but you are already there once you got the two things above settled.

Just in case anyone wanders what happens when you do what you did, I can only speculate as I never tried it. I am pretty sure that this stop signal must be very unhappy when it finds out that it has no home arm to clear. It only ever clears any distant after the animation of the stop arm completes. On a side note, if that were a stop signal, then you would have configured the only arms for junction route 1 and 2. The script will rather not produce an error message if you have more entries than routes at a junction, because you could have some wrapper ahead that sends "we got route 2 now" to this signal, so it is a silent failure that I never came across most people write rather less than more code.

Did I mention they look good?

[albinopigeon]

Thank you for the reply Andi!

I've tried the method outlined in your reply as stated in section 8.4.3 of the manual and it seems to work fine initially, but for some reason if the home arms change on the second signal the distant arms on the splitting distant signal remain up. I'm not sure if it's a TS thing or something that I've done wrong. See the below screenshots to explain:

[AndiS]

I can only think of a naming mismatch in the closing animation.

When the stop arm closes, the distant arm will do the same, at the same time (not afterwards, as when opening). This is pretty sure to state with any certainty you can have with software.

The fact that the distant arm opens means that the child name is ok (and the opening animation, too).

There will be absolutely nothing between the unnumbered link 0 of the stop signal and the only track link of the distant. A switch there that is not "wrapped" in a wrapper would be a cause of faults I saw more than once. But you would have to put link 0 beyond the near end of the curved track piece that defines the logical point of divide in the facing switch to get into trouble in this case.

[albinopigeon]

I did some more testing and it only does weird things in free roams, in scenarios it works perfectly fine.

On to the next signal type! I'm going to try and sort out some calling on arms and see how I get on.

[albinopigeon]

Speaking of calling-on arms:

I've made a signal with a calling-on arm where the home arm behaves like the call-on arm should. Here are some screenshots to illustrate what's happening:




I've talked to Ken from the Glorious Devon team and we think it's a pathing issue, since the call-on arm model works by itself, just not on this particular signal.

This is the script I've used:

require "Assets/AndiS/FPSignals/scripts/FP Universal Semaphore.out"

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

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

gArmTable[1][ARM_CALLON][SEM_CHILD_NAME] = "ARM_CALLON1"
gArmTable[1][ARM_CALLON][SEM_PROCEED_ANIM] = "Clear01"
gArmTable[1][ARM_CALLON][SEM_BLOCKED_ANIM] = "Stop01"

gArmTable[2][ARM_HOME][SEM_CHILD_NAME] = "ARM_HOME2"
gArmTable[2][ARM_HOME][SEM_PROCEED_ANIM] = "Clear01"
gArmTable[2][ARM_HOME][SEM_BLOCKED_ANIM] = "Stop01"

end


I'm all out of ideas, getting close to the straw-grasping stage by now!

(as I was writing this post I realised it's not actually a call on arm, but I think it was worth the effort anyway!)

[albinopigeon]

Quick update, I got it working. I simply had the wrong script referenced in the blueprint! Schoolboy error...

[AndiS]

Haha, my first thought was right, kind of. Phew! I was running out of excuses ....

Original post:

My first thought was that you must have confused the two in the blueprint. I.e., the child named ARM_HOME1 in the main blueprint would link to the blueprint that represents the call-on arm. But I am not sure it is that simple, would be nice though.

Next thought: You you sure you want so many switches beyond the signal? More to the point: Is link 1 placed between the farthest switch and the engine?

If it is not, chances are that the information that the engine is there gets lost. What happens is this: On scenario start-up, all manned engines send message "Train here" in both directions. When any message hits a trailing switch, it only passes through when the switch is set for this track. If the switch is just running around or is set for the other track, then the message simple gets lost. On start-up, many switches run into the position set in scenario editor, or dictated by the first path through them. Thus the requirement that all switches are wrapped, either by signals or by wrappers, because those all take care of the situation in a complex way.


Third thought would be that there were some complex rules under which I would clear the main arm under some conditions, maybe even when a call-on arm is there. In particular when the track is clear. If there is no switch wrapping issue, maybe link 1 is not where the engine far ahead is? Just a straw ...