Bang!

[VictoryWorks]

And signalling items cannot be scenario-specific.

Yes they can

[AndiS]

Is that new in TS2014? Did I miss it in 2013?
Or do you mean signals that are always there and query the current scenario, somehow?

[VictoryWorks]

No idea if it's new, however I do know that if you list a signal as a signal then you're right that it doesn't show up to be added to a scenario. However if you list it in the Misc category, then you can

[AndiS]

Hurray! ... is all I can say.

Actually, what I did was setting ValidInScenarios to eTrue. Quite simple, looking back - as always, but I cannot say whether I tried it and when. Years ago, I lost countless hours with signals becoming scenery as I placed them in scenarios. Also, I cannot remember seeing this ScenarioNetworkProperties.bin in the scenario folder ever before. But that only means I never succeeded.

Anyway, big thanks, bigger than that little thumbs-up icon available here.

As a token of my appreciation, no: happiness, I turned on sound in this game (muting the loudspeaker whenever possible) to test my solution, which I hate to do (both testing and sound) .

Knocking up the script was the easy part, as you know.

Code: Select all

--------------------------------------------------------------------------------------
-- Detonator Signal
-- AndiS for Pete who told him about scenario-specific signals
--------------------------------------------------------------------------------------

--------------------------------------------------------------------------------------
-- INITIALISE
--
function Initialise ()
end

--------------------------------------------------------------------------------------
-- ON CONSIST PASS
--
function OnConsistPass ( prevFrontDist, prevBackDist, frontDist, backDist, linkIndex )

   -- if the consist is crossing the signal now
   if ( frontDist > 0 and backDist < 0 ) or ( frontDist < 0 and backDist > 0 ) then
      -- if the consist was previously before/after siganl then the crossing has just started
      if ( prevFrontDist < 0 and prevBackDist < 0 ) or ( prevFrontDist > 0 and prevBackDist > 0 ) then
         
         -- Request state of next signal            
         local nextSignalState = Call( "GetNextSignalState", "", 1, 1, 0 )
         Print("Next state is " .. nextSignalState)
         
         if (nextSignalState == BLOCKED) then      -- choose one, i.e., either bang on stop aspect only
--         if (nextSignalState ~= CLEAR) then         -- or on anything but clear
         
            -- Set sound controlling parameter, triggering the sound
            Call ("Sound:SetParameter", "SignalProgress", 1)
            Print("Detonator sound started")
         end
      end
      
   -- otherwise the consist is not crossing the signal now
   else   
      -- the the consist was previously crossing the signal, then it has just finished crossing
      if ( prevFrontDist < 0 and prevBackDist > 0 ) or ( prevFrontDist > 0 and prevBackDist < 0 ) then
      
         -- Reset sound controlling parameter - does not hurt to do it too often
         Call ("Sound:SetParameter", "SignalProgress", 0)
      end
   end
end

--------------------------------------------------------------------------------------
-- ON SIGNAL MESSAGE
--
function OnSignalMessage( message, parameter, direction, linkIndex )

   -- We could monitor SIGNAL_BLOCKED, SIGNAL_CLEARED etc. here to decide when to sound the bang,
   -- but GetNextSignalState works just fine and is simpler
   
   -- Forward each message
   if ( parameter ~= "DoNotForward" ) then
      
      Call( "SendSignalMessage", message, parameter, -direction, 1, linkIndex )
      
   end
end

-- States
CLEAR = 0
WARNING = 1
BLOCKED = 2

The stupid testing part, did not get me to the bottom of things, but I must stop playing trains now.

The bits are these:

• I cloned the AWS .bin file and changed name and script reference and ValidInScenarios.
• The signal has a child Sound, so Sound must be before the colon in Sound:SetParameter. That child entry in the blueprint refers to Audio\RailNetwork\Signals\Semaphore.xml. Default semaphores have ControlSound there, but Logmate shows an error for that, so Sound is right.
• I changed ValidInScenarios in Audio\RailNetwork\Signals\Semaphore.xml to eTrue but that did not change a thing.
• Audio\RailNetwork\Signals\Semaphore.xml refers to Kuju\RailSimulator\Audio\RailNetwork\Signals\SemaphoreAudioControl.
• This later file specifies the sound name as Sound again (although I am not sure how much that matters); and it says that ControllerName is SignalProgress, which is the second parameter in the system call to start the sound.
• In the lines following that, TriggerValue and TriggerType say the sound is played as the value moves past 0.5, which is the case when you set it to 1 and also when you reset it to 0, so this ought to be changed.

Given all that, I still hear no sound. This can be a matter of the sound itself as I do not succeed getting it from the lattice signal ahead either.

I have no experience in sounds at all, so this clearly is all new grounds and someone else might easily spot the mistake.

If anyone makes a model, I can happily adapt the code. I guess you would just show or hide the shape representing the detonators, as the placing process is normally done by a fog man, and those cannot be animated properly. But there are also some mechanic detonator placers, operated from the signal box. I have no detail information though.

[Nobkins]

I am away at the moment but I could knock up a simple large letter D for detonator. It is easy to make it a editor only object so it is hidden when playing.