One for Andis - Help on another new Signal ??? Updated....

[SteveP_trains]

Hi Andy
Hope you can advise me again on providing the right script for this type of signal??
Basically it is a ground signal mounted on a post with a path indicator for two routes - Platform & Yard.
My plan is to create the signal and indicator as one model and use the hide/show node for the alpha characters.
So basic question is there one of your clout light scripts that I would use / edit for this??

Appreciate any help in advance!

Steve

[AndiS]

I believe that this could work as the script that is referenced in the signal blueprint:

Code: Select all

require "Assets/AndiS/FPSignals/scripts/FP CLS Stop Signal.out"

function Initialise ()
   
   DefaultInitialise()

   gLightTable[1][LIGHT_RED]             = "the red lights"
   gLightTable[1][LIGHT_GREEN]           = "the white lights"
   gLightTable[1][HEAD_MAIN]             = ""    -- the head is not a child object
   gLightTable[1][LIGHT_FEATHER]         = "the illumination of the character for link 1"
   gLightTable[1][HEAD_FEATHER]          = ""    -- the feather is not a child object

   gLightTable[2][LIGHT_FEATHER]         = "the illumination of the character for link 2"
   gLightTable[2][HEAD_FEATHER]          = ""    -- the feather is not a child object
end

All four light names are the names of the object (model part) to switch on, i.e., make visible, to show the aspect. Just like the Kuju signals have mod_hd2_red there.

In the internal logic, this works as a CLS stop signal with a desaturated green light and two feather. I.e., there is no "straight" route that does not light a feather. (Would that be feather or finger? I never seem to remember.)

I hope it works with the empty strings for the head names. If not, try making the main head (the ground signal) one child object and the route indicator the other and put the name of the children as per blueprint into HEAD_MAIN and HEAD_FEATHER (twice the same for route 1 and 2). I only remember testing with external indicators (as external signal objects) but this is meant to work for all-in-one models, too.

[SteveP_trains]

Thanks Andy

Will give that a go and see how I manage.

I may be back !!

[SteveP_trains]

Well, worked first time - Thanks Andy!!

The empty strings worked so tats good to know.
Not many unusual signals left, I think.

Cheers

Steve

[SteveP_trains]

Hi Andy
Another query, I'm afraid.
I have the signal working fine technically.
However, operationally, I have a problem in that the signal forms part of a run-around loop (platform + loop + platform) and on trying to enter the platform a second time with the coaches waiting, the signal retains the red aspect (because the coaches are in the platform)
Reading your Signals Documentation, I have seen that a "Limited To Yellow" option (ie signal reacts as call-on when occupied) is not possible with CLS, and you say to revert to Movement Predicators instead.

Now the problem is that this Signal maintains the Red aspect even with Movement Predictors in place. Have I mis-interpreted the documentation in expecting the CLS to clear to green when using the Movement Predictors?? If so, any ideas as to how I can work around this signalling little problem??

I think the predictors are in the right places as they react as per your Demo routes if I replace the CLS with Semaphore signals.

Regards

Steve

[Widewanderer]

Hi Steve,

The way I do it is to put a route character "t" for each route over which the signal should clear permissively. I then use a calling-on movement predictor to have the signal clear into an occupied section. Andi told me, in the early days, that this configuration was needed when the main aspect of a signal had to clear for calling-on, as will be the case with the signal you are trying to model. Have a go - I'm confident it should work.

Cheers!

Rob aka Widewanderer

[SteveP_trains]

Thanks Rob.
I get confused over these config options so do you mean adding the "t" like this??

Steve

[Widewanderer]

Steve

Just put "t" in these boxes. The "$" is used only for when a configuration string is used in the signal ID field. If you take that approach, you would use "$1T2T" there. Dont get flustered over this, though; both approaches are valid.

Use the first approach here, methinks - keep it simple, eh?

Cheers!

Rob.

[SteveP_trains]

Cheers

I've done as you suggested and tested it.
I'm using a Free Roam as a test (not sure if that is fair?) and I get an "Ok to proceed" past the signal into the platform after runaround.
However, the signal still doesn't clear which I was hoping it would. In your experience does a CLS do that??

I'll check my Call On predictors to make sure they are set ok, but let me know if my expectations for a CLS are right.

Thanks for the help BTW

Steve

[SteveP_trains]

Hi
Can anyone tell me if this little bit of LUA code in Andy's signal script that I've added should work??

It is part of the Initialise to try and set the lamp nodes to default Red before the "startClosing" & "startOpening" functions kick in.
The code doesn't seem to do anything for me so not sure it is a valid part of Initialise

Thanks
Steve