Setting up a 3 aspect semaphore signal using AndiS

[Auscgu]

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]

We found large concentrations of wrapper slowed the signals to a crawl.

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.

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.

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.

We have had to swap out the GWR arms to BR arms to work with route indicators.

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.

The biggest issue is what I call signals in signals which is easy with mechanical signals.

I love biggest issues. Maybe we should open a new thread on them instead of hijacking Joe's.