AI Path is drawn too far head -- Fleeting signals

[forevergone]

Hi everyone,

I have been playing around a lot with timetable mode and adding a lot of trains to my simulation.

I've been running into a little bit of an issue where the AI train path is drawn really far ahead of the actual location of the train.

As a result, this limits the moves in the same and opposite direction moves, is there a way to limit the length of signals drawn ahead to just read the next signal only ? My signals sometimes activate really far ahead of the train location as much as a few stations down.

Ideally, I would like for the path to be enabled as soon as the block clears rather than taking up a really long portion of the corridor.

Is this similar to Auto Node ?

Any info or help would be awesome on reducing the length of each path.

Thanks in advance.

[roeter]

If your signals clear too far ahead of the train, then check the value for SignalNumClearAhead in the sigcfg.dat file. That value sets how many signals are cleared ahead.
The value indicated the number of SIGNALHEADS (not signals!) which are cleared further down. It may be set to too high a value.
Please indicate which route this is - that defines the type of signal. You could also upload the sigcfg.dat file so I could have a look at it.

Regards,
Rob Roeterdink

[forevergone]

If your signals clear too far ahead of the train, then check the value for SignalNumClearAhead in the sigcfg.dat file. That value sets how many signals are cleared ahead.
The value indicated the number of SIGNALHEADS (not signals!) which are cleared further down. It may be set to too high a value.
Please indicate which route this is - that defines the type of signal. You could also upload the sigcfg.dat file so I could have a look at it.

Regards,
Rob Roeterdink

Hi Rob

The route is "GTA v1.5"

All of my signals have a value of SignalNumClearAhead ( 7 ) in sigcfg.dat file. I tried changing it to SignalNumClearAhead ( 1 ) and currently testing it. Results will be updated.

SIMISA@@@@@@@@@@JINX0G0t______

_Skip ( GO Project Sigs )

LightTextures ( 1
    LightTex ( "ltex" "SigLight.ace" 0 0 1 1 )
)

LightsTab ( 3
    LightsTabEntry (
        "Red Light"
        colour ( 255 255 40 40 )
    )
    LightsTabEntry (
        "Amber Light"
        colour ( 255 255 200 0 )
    )
    LightsTabEntry (
        "Green Light"
        colour ( 255 0 255 0 )
    )
)

SignalTypes ( 26

    SignalType ( "FixedRed"                        _Skip( Placement indication )

        SignalFnType ( NORMAL )
        SignalLightTex ( "ltex" )

        SignalLights ( 1
            SignalLight ( 0 "Red Light"
                Position ( 0 0 0.04 )
                Radius ( 1.0 )
            )
        )
        SignalDrawStates ( 1
            SignalDrawState ( 0
                "Red"
                DrawLights ( 1
                    DrawLight ( 0 )
                )
            )
        )
        SignalAspects ( 1
            SignalAspect ( STOP         "Red"         SpeedMPH( 0 ) )
        )
        SignalNumClearAhead ( 7 )
    )
    SignalType ( "TopAbsoluteJunction"                    _Skip ( Top Head Absolute for Junction )


) 

I have attached the sigcfg.dat file for reference, reduced in size due to character limit. Ideally I would like to have 1 signal block occupied to allow moves in the opposite direction much further ahead of the train to still take place.

Thanks in advance
-C

[kingk0214]

FYI setting the SignalNumClearAhead to 1 works fine if the routes signal's are far enough apart and the end of your train clears the last signal block. but if you have a cluster of signals and can't clear the previous block you will get stuck on a red and will not be granted permission to pass. I have set the signalNumClearAhead to 2 and haven't had any problems since. The orginal script was set at 6 and I only saw 2 ai trains out of 8 running long hauls end to end.

Hope this helps
KingK

[roeter]

FYI setting the SignalNumClearAhead to 1 works fine if the routes signal's are far enough apart and the end of your train clears the last signal block. but if you have a cluster of signals and can't clear the previous block you will get stuck on a red and will not be granted permission to pass.

The length of the train, and how many signal sections the train occupies, has nothing to do whatsoever with clearing the signals ahead.
And I should know this, as I created the logic. Signals do not look backward.
What can happen, though, with a cluster of signals, is that clearing a signal may depend on the state of the next signal ahead of it. And when clearing only one signal ahead, that next signal will never clear - and so one is stuck.

Regards,
Rob Roeterdink

[OTTODAD]

What can happen, though, with a cluster of signals, is that clearing a signal may depend on the state of the next signal ahead of it. And when clearing only one signal ahead, that next signal will never clear - and so one is stuck.

Hi Rob !

Signalling in train simulators has puzzled me for years, having extensively experimented using them in MSTS and then in Railworks.

The way I understand real world signalling to work is that all signals show RED by default or when a train is inside the block they are controlling.

A train allowed to drive into one unoccupied block sets its entry signal behind it to RED and the next block ahead entry signal to GREEN, unless it is occupied by another train.

And then there are Yellows, which I suspect warn a player that the next block is occupied before he actually reaches its RED ?

Is there anywhere one can study how the ORTS signalling logic works before thinking of creating activities for it which use AIs ?

[markus1996]

ORTS uses the sifcfg.dat and sigscr.dat files that also MSTS uses to define signalling rules on a per route basis, so signalling will differ from one route to another. In order to understand signalling for a route, thus you would have to study said files for your route.

Cheers, Markus

[forevergone]

The length of the train, and how many signal sections the train occupies, has nothing to do whatsoever with clearing the signals ahead.
And I should know this, as I created the logic. Signals do not look backward.
What can happen, though, with a cluster of signals, is that clearing a signal may depend on the state of the next signal ahead of it. And when clearing only one signal ahead, that next signal will never clear - and so one is stuck.

Regards,
Rob Roeterdink

Many thanks Rob, it is working very well now. I am using a different number for various signal types such as the dwarfs so the number of signals on my route is now between 2-3 in hopes that no one gets stuck.

I am also adding crossover items to prevent collisions in the main junction blocks.

I will post more progress as I go along but the help in this thread has been fantastic

[roeter]

[COLOR=#000000]Hi Rob !
The way I understand real world signalling to work is that all signals show RED by default or when a train is inside the block they are controlling.

Signal systems vary per country, per period and per system.
So a 'definitive' statement on how signals work in real world is impossible without knowing what country or system you are talking about.
Signals in UK differ from USA, which are different from those in Germany etc. etc.
Old 'mechanical' systems (semaphores) are completely different from modern systems.

As Markus stated, MSTS - and in its trail OR - uses sigcfg.dat files and related script files to define signals and their rules. Using those definitions one can get fairly close to what happens in real life - except, ofcourse, that the system will have to perform the role of the signalmen, and that is not always easy to do.

As for those AI's in activities : just try. If it's a single track route, make sure you set the paths in such a way that opposite trains can pass eachother through the loops. Start with 'fixed' paths, try the variable passing paths if you understand what is happening.
Use the F5 dispatcher HUD display or the dispatcher window to check on what is happening.
Start with one or two, and see how it goes. Just remember : it's all files only, you can't break anything!

Regards,
Rob Roeterdink

[seagoon]

The way I understand real world signalling to work is that all signals show RED by default .....

They show clear down here.