Bits and pieces about signals and AI

[malkymackay]

I can report that I have just successfully tested this & witnessed permissive working with 2 units at Kings Cross.

[AndiS]

Simulating TAB pressing for all trains (including AI)

The following was tested with JT signals by Rob (Widewanderer) with success. It sends a message indicating that TAB was pressed and the game agreed the signal ahead. This is supposed to cause some call-on aspect to show there, fully depending on the implementation of that other signal.

Code: Select all

--------------------------------------------------------------------------------------
-- Do nothing but sending message REQUEST_TO_PASS_DANGER to the signal ahead
-- under the condition that that signal is closed.
-- AndiS, 30 Dec 2014
-- Place this in approach to a signal with a some call-on indication showing when you press TAB
-- Warning: Of course, this depends on the code of the main signal.
-- All it does is simulating the TAB press.
--------------------------------------------------------------------------------------

function Initialise ()
end

function Update(time)
end

function OnConsistPass ( prevFrontDist, prevBackDist, frontDist, backDist, linkIndex )
   if frontDist <= 0 and prevFrontDist > 0 then   -- front passed link 0 proper
      if 2 == Call( "GetNextSignalState", "", 1, 1, 0 ) then
         Call( "SendSignalMessage", 4, "", 1, 1, 0)
      end
   end
end

function OnSignalMessage( message, parameter, direction, linkIndex )

   -- Forward each message except for RESET_SIGNAL_STATE
   if ( parameter ~= "DoNotForward" and message ~= 0) then
      Call( "SendSignalMessage", message, parameter, -direction, 1, linkIndex )
   end
end

function GetSignalState( )
   return Call( "GetNextSignalState", "", 1, 1, 0 )
end

The signal object linking to this code should have

Code: Select all

<Stopping d:type="cDeltaString">eFalse</Stopping>

for a perfect solution. It would work with eTrue, but then, that object would show up in HUD and case AI to stop there.

Thanks go to Rob for persistence and improvement suggestions.

[newbouy]

Hello Andis theres some really usefull info in this thread you have created here.Im currently in the process of rewriting the signal script for my Portable AWS Magnet in my Civil Engineers & Platelayers pack.When I released the pack way back then I just pointed the signal blueprint to use the Kuju permanent AWS script which I now know isn't really the right script for the job.On looking at your "Simulating TAB pressing" above is there any chance of you explaining the "function GetSignalState ( ) section and what its used for.I notice its not called from within the script so is it called from the game core and does it have to be present in every signal script.Also on this script is there a reason why you have a function Update (time) section , im just thinking like every signal signal script has to have certain functions like Initialize , OnConsistPass and OnSignalMessage ect.Thanks for your help.

Newbouy

[AndiS]

Off the top of my head, I cannot clearly remember whether GetSignalState was required or not. The safe assumption always has been that each signal should have it and do something reasonable in it. You are supposed to return the signal state value. Best look at the old Kuju signals for a nice illustration. The have some gState (I believe) that contains values like SIGNAL_BLOCKED, SIGNAL_WARNING, SIGNAL_CLEAR, so when the signal is closed, showing red, the return value will be "blocked".

There is a function GetNextSignalState or similar. If that is called, most likely GetSignalState of the next signal is called, or so I seem to remember.

Update is important for animations. The game core calls it many times per second. The argument time is the seconds since the last call (typically 0.15 or so). When you play a signal arm animation, you add this value to the animation's state. If you flash some light, you turn in on and off after so and so many seconds (adding the time argument to keep time). There are also delays in some stuff like gates and other nice stuff. But nothing related to AWS.

[newbouy]

Thanks for the reply , I did have a look through quite a few Kuju scripts and all of them had the function GetSignalState ( ) section and like you say most of them return their current signal state.Again there was no call to this function from within the script itself so it has to be called from the game core surely? I havnt had a lot of time to experiment but I did add this function to my script and added a line to print out to logmate but I got nothing on running the script.But there again im wondering you proberbly wouldn't get a print out to logmate as the script is not calling the function only the game core.

Thanks Newbouy

[AndiS]

Two afterthoughts on this:

First, it will not be called for non-stopping signals. There is this "is stopping" flag in the blueprint. If that is true, then the game sees this as a block signal and it would be very reasonable to only call this function for such "stop signals". AWS should have it as false. Distants too, but for some reason some Kuju signals have it on true, maybe just because their AWS does use GetNextSignalState -- or did at some point in the past.

Second, the HUD showed the next signal state in Rail Simulator and maybe early versions of Rail Works. It was removed as not being prototypical. You would need a very old version of the game to see if it did call GetSignalState back then. But who would care?

The old scripts also show traces of design changes during script writing, so it could just as well be that GetSignalState already became redundant before initial release.

But then again it could be that it is still important! I do remember that someone asked which values to return for the various more complex signal state that relate to the German LZB. A cab with this in-cab signal display certainly needs to know the state of the signals ahead and GetSignalState would be my first guess for how to get such information.