G'Day!
Signal behaviour is governed by the scripts which control them. From the outset,
please understand that I do not write the scripts myself - lua scripting is still something I have not gotten my head around properly
However, I
have become reasonably proficient in editing signal blueprints, and attaching other people's scripts to run them.
For decent realism, I have at various times employed scripts by
Mark Brinton, and laterly
AndiS - the "default" Kuju signal scripts are, in comparison, pretty awful and simplistic, particularly with signals clearing automatically behind a train when passed in a reverse direction, something which just
wouldn't usually happen in the real world on UK railways. The Brinton and AndiS scripting systems are both very excellent, however my current preference is to use AndiS's scripts, as he has included a very flexible method of linking his "universal" main script with just about
any arrangement of signal arms one could think of. He also provides a system of track objects (called "Movement Predictors") for use in scenarios to control the detailed behaviour of signals, such as what to do if a train requires to reverse, or to trigger calling-on aspects. Using the AndiS system requires the negotiating of a pretty steep learning curve initially, but the effort is well worth it. My mission is to try and ease that learning curve for as many interested folk as possible
So, a couple of comments about your loop situation:
Firstly, signal scripts interact with one another by passing "messages" back and forth, to let each other know how their states are changing as a scenario progresses. This system of passing messages between signals is complex (and the exact detail is currently beyond my own understanding!); furthermore, the logic employed by the script writers tends to be a bit individual, each to their own - for that reason, signals powered by
different families of scripts won't generally work if mixed together. As a rule of thumb, a route builder needs to choose one system of signal scripting, and stick to it.
So far, I have
never seen signals working successfully in a loop like yours - my guess is that the scripting logic assumes that the afore-mentioned signal messages are intended to be passed back and forth in a
linear fashion. I tried to signal a circular track myself once, but ended up with the signals all "locked up" - nothing would work until I cut the loop and went back to working linearly! (Mark/Andi - if you're reading this, any comment?) Sadly, I am actually not surprised that your circular-track signals do not work properly - I am guessing that signal messages are perhaps ending up back at their points of origin in some fashion, and that this is somehow causing a bit of a "feedback loop" and confusing the script's logic
Just guessing, I'm afraid.
If your stop signals are based on Anthony Brailsford's LNW set, then you are almost certainly using Mark Brinton scripts. I think I am right in saying that Brinton-scripted signals will only clear at the very start of a scenario when a train actually begins to move towards them. Furthermore, a signal needs to "detect" the approach of a train before it will respond at the very start of a scenario, and by default with Brinton signals I believe this doesn't happen until the train is actually moving towards, and is within 100m. With the AndiS system, this "detection distance" can be varied more widely through the signal's configuration on a route.
Distant signals are not set up as "stop" signals, so are not usually displayed on the 2D diagram or HUD. By my understanding, not seeing the distant signal on the 2D/HUD is perfectly normal.
Understanding signalling in TS requires a lot of study and experimentation. I'll do my best to help out where I can, although I won't be able to fix problems with the actual script code directly - that bit is a little above my pay grade!
Best wishes,