Andis Signal and Text Based Route Indicator

[AndiS]

I fail to understand this. So you got _123456_ as the signal ID of the indicator, right?
And its link is between link 0 of the signal and the signal post (surely, or else it would not influence anything here).

The code quite clearly states that this indicator only eats SHOW messages and passes all others throught. And FP Route.lua sends EXTERNAL_JUNCTION_CHANGE messages to indicate the route. I have no idea how the indicator would mess up here. Maybe you can reduce it to a simpler case, where the route indicator works and then to one where it does not, but without the whole load of complexity you have here?

[albinopigeon]

What works depends on what link is in front. Either the arms work for the set routes and the indicator does nothing, or the indicator works and only the highest-numbered arm rises.

I have it set up as an Animated Signal Blueprint; is that correct for what we are trying to achieve?

I may have to go back to my original method of coding it as a co-acting arm. Is there anything I can do to the indicator script beyond setting the closedCharacter at 0 (to represent a blank indicator)? Also the FP Route.lua script you mentioned is different to the one required in the script I wrote (literally two lines) for the indicator, so that might hold the answer. Ken and I might just not be looking into this hard enough!

I would check said script but I'm away from my PC until Wednesday 2nd, so I shall have to ponder over it in the meantime.

[AndiS]

What works depends on what link is in front. Either the arms work for the set routes and the indicator does nothing, or the indicator works and only the highest-numbered arm rises.

New elephant in the room: The logic wants the indicator routes to be the highest numbered. So despite the locality, it will be necessary to arrange the routes like this:

Route 1 goes to down siding, associated with arm 1 on the left.
Route 2 goes the up sidings, associated with arm 2 on the right.
Routes 3 to 8 go to the platforms, associated with arm 3 in the middle. So the indicator ID is __123456. The two _ are important, of course, telling the indicator to shut up for route 1 and 2.

I would try that before taken any other step.

(The indicator link always goes in advance of the signal link no. 0, so the signal link's arrow points to the indicator link. Otherwise, the indicator becomes an indicator of the signal in approach and if that exists, it does nothing there, as there is no junction to signal there.)

I have it set up as an Animated Signal Blueprint; is that correct for what we are trying to achieve?

Sure.

I may have to go back to my original method of coding it as a co-acting arm. Is there anything I can do to the indicator script beyond setting the closedCharacter at 0 (to represent a blank indicator)?

No. And having an explicit closedCharacter rules out another option to fail, that may be a red herring. So basically, I am just puzzled you have this 2 in the name of the .out file but that may be because there was an update in 2017 adding this closedCharacter feature.

Anyway I put enclose the version of the file lying around on my disk here. You may want to stick that into FP External Text-based Indicator.lua and change the require line accordingly and see whether it does anything. But I can't figure out how it would make a difference.

Code: Select all

--------------------------------------------------------------------------------------
-- A theater box type indicator in a separate slave object controlled by the master stop signal
-- The current implementation is based on texture set switching.
--

require "Assets/AndiS/FPSignals/scripts/Shared by All.out"

function Initialise ()
   
   InitialiseId()

   InitialiseConstantsAndArrays()

   gConnectedLink = 0
   gAnimState = -1
   
   gInitialised         = false               -- has the route finished loading yet?
   
   ResetSignalState ()
end

function ResetSignalState ( )
   
   gId = Call ("GetId")                  -- TODO: insert parsing for special codes in ID here
   if gId == nil or gId == "" then
      ErrorPrint("ResetSignalState", "Indicator without ID shows nothing")
      gInitialised = true                  -- do nothing on update (a bit redundant since BeginUpdate is not called)
   else
      gInitialised = false               -- induce resending of SIGNAL_I_AM_ARM
      Call( "BeginUpdate" )
   end
end

function OnConsistPass ( prevFrontDist, prevBackDist, frontDist, backDist, linkIndex )
   -- don't care about trains
end


--------------------------------------------------------------------------------------
-- UPDATE
--
function Update (time)
   if gInitialised then

   else
      SimpleSendTestMessageWithinLinks()
      
      -- new 21 Sept 2017
      if closedCharacter == nil then
         Call( "SetText", "", 0 )
      else
         Call( "SetText", closedCharacter, 0 )
      end
      
      Call( "SendSignalMessage", SIGNAL_I_AM_INDICATOR, gId, -1, 1, 0 )
      
      gInitialised = true
      Call ("EndUpdate")
   end
end

-------------------------------------------------------------------------------------
-- ON SIGNAL MESSAGE
-- Shunt signals just forward the signal messages on to other signals
--
function OnSignalMessage( message, parameter, direction, linkIndex )
   MessageLog( message, parameter, direction, linkIndex )

   if (message == RESET_SIGNAL_STATE) then
      ResetSignalState()
      
   elseif (message == SHOW) then
      -- new 21 Sept 2017
      if closedCharacter == nil or parameter ~= "" then
         Call( "SetText", parameter, 0 )
      else
         Call( "SetText", closedCharacter, 0 )
      end
         
   elseif message == OPEN_LOG then
      OpenLog(parameter, direction, linkIndex)
      
   -- Ignore initialisation messages from trains straddling a link - these will have the "DoNotForward" parameter
   -- Otherwise forward on the message
   elseif parameter ~= "DoNotForward" then
      Call( "SendSignalMessage", message, parameter, -direction, 1, linkIndex )
   end
   
end

Also the FP Route.lua script you mentioned is different to the one required in the script I wrote (literally two lines) for the indicator, so that might hold the answer. Ken and I might just not be looking into this hard enough!

FP Route.lua is what drives the editor-only object Ken put near the buffer stops (called Route Token in the manual). This is the sender and your two-line script is the receiver.

[Auscgu]

Andis,
The text based route indicator and signal by route numbers.
I made the change to the arm link order, this alone did not resolve the signal issue.
Put the new .lua for the FP External Text-based Indicator.lua
The combination of the two mods once I sorted out the route token number order works.

To test and prove it works.
First I built a conventional signal with arm link script.
To test the arms activate in the correct sequence with the correct link. Sanity check

Next was convert that signal to an 8 link signal and change script to route arm order.

Link 1 left arm
Link 2 Right arm
Links 3 to 8 Middle arm, call on arm and route indicator for the platforms.
Order Plat 1 to 6 left to right.

Next place and order the Route Tokens
Route numbers left to right
13456782

Route Indicator code
Order for arm sequence
__123456

This works.
The issues I see is in free roam the the right arm needs a crossing changed to get the arm to activate.
I think because its behind the 3 way crossing its not seeing the switch to activate it.
Needs more links to pick up the change of the 3 way crossing.
You can change the arm order with the route token numbers.
This feature had me scratching the head for a bit, then the penny dropped.

[Auscgu]

The signal in action in direct link test route.

The platform routes with indicator.
Plat 3 which is straight through on the test route.
Works for all platforms routes 3 to 8

Route 1 left arm

Route 2 right arm

[Auscgu]

Now to test the Callon arm works for all routes and platforms with the indicator.

With the scenario predictor the callon works for all routes.
Set for straight through and platform 3 in this test.

Note the call on will active the arm if no call on arm is present.
Routes 1 & 2 the arm clears.
Routes 3 to 8 the call on arm activates.

A working signal now to test by indirect link test route.

[AndiS]

Route Indicator 16.jpg

Route Indicator code
Order for arm sequence
__123456

This works.
The issues I see is in free roam the the right arm needs a crossing changed to get the arm to activate.
I think because its behind the 3 way crossing its not seeing the switch to activate it.
Needs more links to pick up the change of the 3 way crossing.
You can change the arm order with the route token numbers.
This feature had me scratching the head for a bit, then the penny dropped.

I think you first need a wrapper around the whole 1-to-8 fork. It may work without one in some cases, but this is against the book. A single link signal is not prepared to do all the track occupation management that a junction (signal or wrapper) does.

Independently of that, I am mildly worried about three-way switches since we had these issues with the diamond crossing that confuse my signals by not sending "path broken", or rather sending it at the same time as "path set" for the new route. I forgot the details but I remember they upset me.
I may worry too much in this case, though, because it is still facing switches, if much condensed.

[Auscgu]

Andis,
Funny you should mention that problem.
The Bournemouth West Test build with in direct links.

I have all the signals working but you have to force them by changing the double slip 23/25.
The test route will not work in scenario mode anymore.

The route codes for the main arm, route indicator and arm 2 right arm are not passing through the double slip.
It was working but has now become funky.
The signal and route indicator still work once forced.

I could reduce the links by only wrapping converging routes.
Just to confirm all diverging routes don't need the wrapper link.
Only converging routes must have a link in the direction of travel.
The exception is diamond crossing and double slips?

[Auscgu]

The BWS02 Test signal working.

The link method for BWS02

The wrapper to platform 1 & 2

[AndiS]

$matches[2]

On the straight track (down mainline), there seems to be an extra link:

Going from the signal, there is one beyond the track convergence at the double slip, fine.
Then there is one a bit down the road, besides disk 14, which puzzles me.
Then there is a third one beyond the convergence of the crossover from the left, which is fine.

The middle one does nothing as far as I can tell. Could it have migrated from somewhere? And does it have its - in the route letter?

Always sad to hear that anything goes funky, at least for signals, that is not the way it should be.