Applying Andis's Signal Scripts

[PaulH]

Hi Andis,

I have just done two timetabled scenario runs from end to end and back again - all signals work well - almost!!

I say "almost" as I seem to have two glitches of a similar nature - with no other trains running and the roads correctly set, at two block post locations and only in one direction all signals through that block post seem to be on approach control but this has not been selected in the signal head drop down box. In one instance, the signal controls entry into the main platform or a diverging bay road. Approach control is being applied in the case of the former but not the latter.

I repeat that the roads are correctly set and no other traffic is anywhere in the area. The approach control is consistently applied and I can live with it but would like to understand why this is happening.

Any ideas??

Paul

[AndiS]

Most likely, the last signal before the buffer stops needs an a as a route character in the table of the signal properties (right-hand fly-out) (under the icon showing an A).
Maybe there is an a for the link/route where you get no approach control and an f or nothing for the one where you get approach control.

An alternative explanation would be that you use a signal with one stop arm. In that case, the second line needs digit 1 in the route character to tell it to use doll/arm 1 for link 2, too.

A variation of the first paragraph is that you sink distant signals near the buffer stops. Maybe you did, but one of them went missing in a track rework or you forgot that one or something along these lines.

If you have approach control at one signal, you get it on all signals of the same box (in approach to this signal). That is what rule 39 says. But you can up the approach speed by entering a number in the table of a junction signal or by appending $~20 to the signal ID (to clear the signal when the train is slower than 20 mph, just as an example). I theorise that this is what signallers did in practice, creative interpretation of "near stop".

[PaulH]

This subject gets more arcane the further one gets in.

You are right in your assertion that all signals through the errant block posts are unwanted approach control. I have checked and the distant signal I sunk before the buffer-stops is still there and linked. It is orientated such that the yellow face of the distant is pointing away from the buffer-stops and hence the link arrow towards the buffer-stops. Is this the correct orientation? There are some trailing points between the sunk distant and the buffer-stops - would this make any difference? Also I have added a letter "a" to the A column table of signal properties for the last signal before the buffer-stops.

The approach control is still being applied.

I admit now that I do not fully understand what the table signal properties drop down box is applied or what it stands for - I have always left them blank. Can you explain simply how to use them?

I haven't added any signal IDs either - what format should they take? Would simply an area code and a sequential number suffice? Logically, your reference to "..appending $~20 to the signal ID..." implies that this ID is more than just an identifier and also has an impact on signal performance and operation. Can you help me here as well.

I know this is a big ask, so please humour me - I am indebted to you for your help.

Paul

[AndiS]

I have checked and the distant signal I sunk before the buffer-stops is still there and linked. It is orientated such that the yellow face of the distant is pointing away from the buffer-stops and hence the link arrow towards the buffer-stops. Is this the correct orientation?

Yes, correct.

There are some trailing points between the sunk distant and the buffer-stops - would this make any difference?

Yes indeed! If there is not suitable signal that can have its numbered link placed beyond the last trailing switch (as seen from the arriving train), then you need one or more 1T wrappers. There must not be any switches that are not wrapped between link 0 and a numbered link of either a signal or a wrapper, in the direction of the arriving train.

Also I have added a letter "a" to the A column table of signal properties for the last signal before the buffer-stops.

The approach control is still being applied.

The 'a' is right although it should not be necessary given that you have the distant sunk at the buffer stops. I hope that we can put all the blame on unwrapped trailing switches.

I admit now that I do not fully understand what the table signal properties drop down box is applied or what it stands for - I have always left them blank. Can you explain simply how to use them?

Leaving it blank is a great idea. Assuming that it works as for the Kuju signals is a bad idea. So you are on the right track when you leave it empty.

A simple use case is this 'a' that you put in for those track links where you want it. If you have no distant signals at the buffer stops and a 2T signal with 2 arms leads up to two dead end tracks and you put in an 'a' in line 1 of the table, then you are spared of the approach control ritual for link 1 of the signal but not for link 2 (because you put nothing in line 2 of the table).

The last page of the reference manual has a cheat sheet summarising the stuff that can be done but for each one who puts it to good use, you find two who get confused or scared, or both. I tried my best to save you from worrying about it all, as long as you do not model complex station layouts.

I haven't added any signal IDs either - what format should they take? Would simply an area code and a sequential number suffice? Logically, your reference to "..appending $~20 to the signal ID..." implies that this ID is more than just an identifier and also has an impact on signal performance and operation. Can you help me here as well.

You do not need a signal ID, but some signals have plates that only show something if you enter something in these fields.
Among computer nerds, nothing is quite something, also called a string of characters of length zero. So technically, if you have no signal ID, you append $~20 to nothing which result in just $~20 being the sole content of either of the signal ID fields. (The game simply concatenates them and the script cannot even tell in which field you entered these characters.

The $ separates the signal ID proper (which can be nothing) from the magic characters that I introduced. Again, the last manual page is your friend or foe.

~ defines the limit speed for approach control in mph. If the train is slower, the signal is cleared.

Again, I hope that you do not need any of this. The real problem is the broken communication path between the signals because of the unwrapped switches (I hope). Once you got that out of the way, you need no 'a' and no $~20, it just works out of the box.

Footnote: The letters in the ID are forced to uppercase. Therefore, your 'a' becomes an 'A' in the signal ID which adds to the confusion.

[PaulH]

I have shuffled the signals and links about as advised but still seem to be getting approach control on the signals approaching the terminus. They do at least clear so I can work the scenario but it would be nice to work out why it's doing this. When I complete the scenario, I am informed that I have committed a SPAD but I'm sure I haven't - I don't know what this means??

The fields in the properties box for the signal ID has two boxes - can you explain why there are 2. I did try to experiment to ascertain the effect on the appearance of signals with number plates on but whatever I put in these boxes, the signal number plate just displays the line speeds.

So, if I put "$~40" in the signal ID box on the properties for the first signal to apply approach control, does this mean it will clear if I'm doing less than 40 mph?

[AndiS]

The fields in the properties box for the signal ID has two boxes - can you explain why there are 2. I did try to experiment to ascertain the effect on the appearance of signals with number plates on but whatever I put in these boxes, the signal number plate just displays the line speeds.

There are two purposes of these fields.

1) The signal script gets both of them in one string. That is, the signal script does not know which field you used. It get the content of the left field plus the content of the right-hand field all in one string of characters.

2) The content of the first field controls the first line on the signal plate. The second field controls the second line. I forgot the rest and if you don't design signals yourself, you don't care. Most public domain signals do not seem to have signal plates that are controlled by these fields, if I remember that right. But I may be wrong.

So, if I put "$~40" in the signal ID box on the properties for the first signal to apply approach control, does this mean it will clear if I'm doing less than 40 mph?

Yes. But by default this is only evaluated if you are within 200 m or so from the signal. If you use $~40=400 you tell the signal to clear if you are under 40 mph within 400 m from the signal. You will want to play around with those numbers a bit to make it "feel right".

[PaulH]

Thanks Andis.

There are 3 signals that this unwanted approach control was applied as I approached Blaenau terminus. I tried shuffling links as you intimated in posts previous to no avail so I added an "$~40" to the otherwise blank ID boxes for each.

Eureka!!

The first signal protects a gated road crossing and clears well in advance as I approach at a reasonable speed whereas before it cleared when I was at walking pace about 10m away. This is suitably prototypical for a busy road crossing protected by signals. The other two pegs clear before they become visible and this suits me fine.

This seems to be too simple a solution - is there some downside of which I am unaware??

I have looked through all of the documents I have both software and hardcopy and cannot find the manual you refer to. Years ago I had some early Rail Simulator Development Docs but these seem to have gone astray in one of my many house moves. Can you advise?

Paul

[AndiS]

In the download, there are three PDFs. One of them is titled Reference Manual. That is the one I always cite. Since I felt that it was to terse, like all reference manuals, I wrote a User Manual which was to terse, I heard. I also wrote a third PDF titled Introduction which is a wall of text that should have been named "Andis last words to the afterworld" or something like that. Don't expect to get help in there.

After closure of UKTS, this site here might be the only place to still get this 9+ years old stuff.
https://www.trainsimdev.com/forum/downl ... &df_id=141

[PaulH]

Thanks again AndiS.

The demise of UKTS is a sad loss.