Signal Issues with AndiS Scripts

[Auscgu]

The discussion started in the thread, Setting up a 3 aspect semaphore signal using AndiS.

Signal Blueprint issues.
The work on Glorious Devon 1958 has revealed some issues with the blueprints used to create signals.
The route has used John Yelland, Anthony Brailsford and a limited number of Mark Brinton signals.

I would like to state up front that the issues found with the signal is a point of discussion to improve the signals.
No disrespect is projected or intended to the asset creators.
They have all added to train simulator and I am sure we appreciate their efforts.

The issue was the JY GWR signal are very slow to respond and once the complexity of the signal installation is increased they are not reliable.
The JY BR signals work very reliably and can handle very complex signal installations.
Work well with the a route indicator.

This was discussed and I quote.

AndiS,
I agree it was a lot of info for Joe.
I have shared my work with Joe and have been helping him.
Wrapper are great and allow so much flexibility for the signals.
My preference is multi link signals and Oldoakcom and I sent a year playing with wrappers on GD
Test build.
The location was Newton Abbot which is very complex from a signal perspective.
We found large concentrations of wrapper slowed the signals to a crawl.
Have since found out the the JY GWR signals have a problem.
They where created as an animated scenery blueprint.
The later JY BR signals where created by a signal blueprint and work more efficiently.
We have had to swap out the GWR arms to BR arms to work with route indicators.
We re signaled the same location with multi link signal and the signals worked with very little
delay.
One you use call on arms you need multi link signal.
The biggest issue is what I call signals in signals which is easy with mechanical signals.
Not easy with AndiS signals but I have found a way.
I have spoken to Joe and he agrees it was a huge amount of info.
But also excited about the potential.
Ausc

AndiS reply

I was worried about this at a time. So I made some tests and found it was not too bad. But that
was just a test route.
In principle, I fully agree. Every wrapper is a signal on its own and messages are passed from
signal to signal, so when there are 3 wrappers between two signals, the game will call all three
to see if they have something to say about the message. Sometimes they have and this is the
crucial point but most times they just pass them through. I have no idea how fast Lua is
processed and how much overhead per signal the game performs. Basically the scripts never do
any big computation, except on start-up when there is baroque message passing to help find
possible flaws with link placement. Also digesting all the stuff in the config string takes time.
I am not sure I can follow here. When an arm or whatever is animated, you need this place in
the blueprint where you reference the animation and only blueprints with animation in the
name have that.
If you have a static post and still use an animated blueprint, maybe the game goes nuts over
that? I never tried that. There are these animated scenery items like diggers. So maybe the
game tries to run such an animation on your signal post and finding no animation maybe writes a
message to some log or otherwise spends time on recovery. There have been various reports on
flawed assets eating up time.
Was that because of the different type of blueprint? I don't have them at hand but I should be
surprised about a difference? But what do I know, it's a few years since I worked with them.
I love biggest issues. Maybe we should open a new thread on them instead of hijacking Joe's.

[Auscgu]

I believe the wrapper problem signal response are related.
To compare the signal blueprints

JY GWR Arms use <cAnimProceduralSceneryBlueprint> for the .geo to signal animation.
The JY GWR arm as a signal uses a <cSignalBlueprint>

JY BR Arms use <cAnimSignalBlueprint> for the .geo to signal animation.
The BR arm as a signal uses a <cSignalBlueprint>

My thoughts are the transition from AnimProceduralSceneryBlueprint to SignalBlueprint may be the issue.
The solution was to create GWR signals using the GWR Post and BR arms for critical signal and to work with the route indicators. You get the look of the timber posts and most of the time you don't notice the BR arms.
A good working solution.

[AndiS]

<cAnimProceduralSceneryBlueprint> is what the original Kuju signals use. I mocked about it shortly in 2007 and then we all forgot about it. I rummaged in some of my old lists and there is a certain trend towards <cAnimSignalBlueprint> in the freeware scene, whereas WearValleyRailway by RSderek and Woodhead by RSC have the arms still as <cAnimProceduralSceneryBlueprint>. These two routes also have signal heads as AnimatedScenery (sans Procedural) without an animation, so may not be the best reference source.

The Digger also uses <cAnimProceduralSceneryBlueprint>, so there could be a point in avoiding this one.

But then again, I found that the game only gives the root/parent blueprint the special treatment according to its type and not the children. E.g. a signal blueprint that is child of something else does not have track links. Last time someone tried to combine milepost and signal was not so long ago and I have not heard of success there.


I believe that the wrappers cannot have anything to do with it.

First of all, they use <cSignalBlueprint> with a <cEditorShapeBlueprint> child.

Secondly, I can imagine that if you really go to the extreme in fragmenting the trackwork of a complex station, there will be a lot of message passing/forwarding. As I said, I was worried at a time and I did some tests and they were not too worrying. But I do not remember any hard facts.

Some people say that it matters whether you have welded joins of plain track between the links. Some say that it is bad for game performance to have many track ribbons that you laid in different directions. There is much unclear in this game and I gave up getting to the bottom of this some five years ago.

[Auscgu]

Andis,

I cant say either way as the primary cause just what we experienced during the process.
This will be given a second visit as Newton Abbot is to be tackled in the the next update for GD1958.
The track from Newton Abott to Exeter the middle section of the Kingswear Bch still need converting to AndiS signal.

The JY GWR signals are very early assets and a lot has changed when the BR signals where created.
Also spent quite a bit of time working with Paul on the North Wales Coastal LMS route.
I have been converting ALGB signal to JY scripts to have a common script.
Adding lots of custom assets and seeing a good result with the signals.
Also work with the JY LMS signal which are very recent assets.
They used the same method as the GWR signal and have similar issues.
Not conclusive but a common theme.

The track cutting theory.
I am a big fan of cut track to improve the track crossing timbers and I have seen signal issues resolved by cutting.
Track direction is generally one direction as I like to offset all the main tracks and add the crossing.
Main track generally in one direction but certainly both used.
Crossing will generally be one direction but heaps of both directions as well.
Always cut and weld except auto formed complex crossing which cant be modified.

Not seeing any negative with cutting with over 400 miles of track for GD1958.
Also the cut track theory.
Why does a different signal arm animation applied to the exact same track with the exact same install method.
One works the other is so funky and unreliable not a usable solution.
I think this point to the difference in the signal arm animation theory.

End of the day I am going down the AnimSignalBlueprint path and this is my reasons why.
Time will tell if I am right or wrong.

I don't think this is a major issue just something to be aware of and make your own choice.

Multi Link vs Single link and Wrappers
Both work and have there place.

From my experience you need to analyse the signal install and what your trying to achieve.
Lots of location Single link is the only option on a main or single line where no crossings are near or involved.

Complex junctions will need to be analyse as to how all the other signal relate for the best installation.
My first preference is always Multi link.
If a multi link cant be used then wrappers are the next choice and give great results.
The combination of both is used in a high percentage of crossings.

This is determined by the prototype and how the signals are intended to work.
The next issue to work through is how TS works with the signals in scenarios.
Great results can be achieved and having wrappers and the ability to transmit the codes is just amazing.

WearValleyRailway is a great example to investigate and operate with AndiS Signal Scripts installed.

[Auscgu]

AndiS

The most complex issue is what I call a signal in signal install.
AndiS you will remember the time we spent working at Kingswear.
Our starting point for your signal conversion for the GD1958 Test Route.

The logic was start on the single line section of GD which will be a lot easier to learn the process.
How wrong can you be?

Kingswear burnt so much time and effort by AndiS, Oldoakcom and Ausc.
Oldoakcom move on and continued up the line to Newton Abbot.
I spent a considerable amount of time working on Kingswear and after a year we still did not have a fully working solution.

This is how I cut my teeth in the AndiS signal conversion process.
Thanks to the patients and time of both parties I manged to get my feet and move on.
Solution come with time and experience.
I now have a working Kingswear with Route indicators.

[Auscgu]

To explain the principle of signal in signal.

This is Kingskerswell Stn on the Kingswear Bch.
Typical GWR signal installation with lots of ground discs with lead to signal in signal in a simple form.
One of the solutions is to use the combination of signals and wrapper.
Multi Link signals are first prority.

Kingskerswell Signals looking east

Signal Diagram for these signals.

Basic signal in signal
Ground Disc8 (GD 08) has two paths to Up Main or Siding.
GD 08 clears to GD11 which has two paths to Dn Main and Up main.
Reverse direction for the Up Main.
Signal Arm 16 (Hm 16) controls to signal GD 08 and beyond.
Mechanically GD 11 is a signal in signal in the simple form.

[Auscgu]

A solution for these signals.
Multi Link signals as priority and Wrappers to complete.

Signal GD 08 named KWL08
KWL is the abbreviation for Kingskerswell
KWL08 has two signal links.
Code is f or Home Signal for Up Main Reverse.
Code is a or inner distant or Section signal for siding.

GD 11 names KWL11 has 3 signal links
Link 1 to Dn Main code a (section)
Link 2 to Up Main Rev code f (Home)
Link 3 is and inner link to monitor crossing direction, code -

Refer Reference Manual 1.0 page 52

GD 08 give route to GD 11 and then final routes.
Closed by GD 13 on the Dn Main
Closed by Hm 16 on the Up Main
Closed by GD10 on the Siding.

[Auscgu]

A solution for the reverse direction.

KWL16 is the Up home for Kingskerwell and controls access to the platform.
To stop signal conflict and the close the signal arm you have passed it is best to treat his as two signal installations.
Signal KWL16 is closed by signal KWL11.

To complete the signals in the Up direction wrapper KWL12A completes the signals to KWL08.
The wrapper is a signal with out the visible object and transfer the signals info.

Simple and easy solution and works.
You could do this with other signal assets, but I like this simple reliable approach.
We will get to the problem but enough time for today.

[AndiS]

I am a big fan of cut track to improve the signal timber

You lost me with this statement.

Mechanically GD 11 is a signal in signal in the simple form.

Now I understand what you mean. I would use after instead of in because that sounds less frightening.
I was worried about signals inside the span of signal links of another signal which, as you know, is a big no-no.

At KWL11, I would drop link 3. You only need the - links where there is a convergence in approach to them, to monitor for reversing engines.

It looks like KWL13 has such a link, too.


One thing I forgot in out discussion about wrappers is this: For every track link and every train within 2 km from that link, OnConstistPass is called many times a second and at each of these links, you need to decide whether the train has just crossed it or not.

That means that not the number of wrappers can be a problem, but the number of track links. At the same time, we are not placing them for nothing. Many inner links (with the minus) are just necessary to follow shunting moves and clear the signal for the next train. Default signals often fail here. But maybe DTG are not just saving time in placing less links but also improving performance at the cost of choices for scenario creators.


I think that the scene shown is a great textbook example because it shows how seemingly simple locations contain quite some complexity, but not because the scripts are so complex but because the prototype is.

In the down direction, we have no choice but to have two ground signals, blame GWR. 8 clearly is a home signal (independent disk in terms of my scripts), 11 could be a dependent disk if you like, or just the same as 8.

The wrapper is nice case for do as you please. You could span KWL16 and 13 to beyond switch 9, but then you would need an inner link for each beyond switch 12 or we might miss some very short light engine that reverses at 12 without touching the signal links beyond link 9. So it is just the same total number of track links, whether you use a wrapper or not. Also whether you prefer to have the wrapper depends on whether you easily get the links right or not there. If link 0 does not follow all the numbered links there, you have a hard to detect problem.

I am puzzled by the two track links that show to the extreme left of the last picture where you show the properties of KWL12A. See the green vertical lines left and right the black sign. One is from the ground disk, but the other, seemingly emanating from the middle of the track?

[Auscgu]

AndiS

The crossing timber statement.

The track cutting theory.
I am a big fan of cut track to improve the track crossing timbers and I have seen signal issues resolved by cutting.

This correction will help, I messed up what I was trying to say.

The 3 link for signals KWL11 & KWL13.
This is a belt and braces approach and a hang over from route indicators and complex signals.
At this location I am getting a weird track feed which changes the disc to green on the opposite track.
Could be a UK signals as the stations beyond have not been converted.
I find you get a few odd feeds through the filters.
The first distance arm will not always react.
Not an issues as aware of the problem and when the other stations are converted the problem will be resolved.

I have highlight both KWL11 & KWL13 and you can see both have a link3.
I am aware of the inner links for reversing.
They are also used to confirm the crossing change for route indicators.
This was chasing the disc feed error.

The extra links

These crossing have hidden speed signs as the location does not have speed signs in the pictures.
A lot of speed changes for railways are covered by regulations and you see very little speeds signs on railways.
Speed signs are require to show the speed change in the Hud so you don't have blind speed changes.
I always put them inside the signal links so you don't affect the signal link info transfer.
This method see to be reliable and follows your principle of nothing inside the signal links.