I just found out more issues with these disks.
1) At least on my installation, BR(WR)-triple-grnd-sig-post.geoPcDx has disappeared. This causes the triple disks to become invisible, too.
2) I created single-link dependent disk assets. These are useless. Please delete.
From various conversations, I learnt that the question of disks is a thorny one. Since I fail to find time for the missing primer, let me spell it out in plain words here. In contrast to the reference manual, I use the frequency of use to order them here.
1) The disk as a
normal home signal. The asset refers to H.lua or HH.lua etc. Stopping is eTrue. I call this independent disk but this may be confusing. Just see it as totally normal signal that happens to be small.
You use this where you could use a full size home signal, albeit with smaller arm and maybe a circle on the arm. The most frequent use cases are siding exits and reversing crossovers. The GWR has a full size backing signal in some places. It is just customary to have disks or miniature arms on ground signals for backing movements and in yards where they want to save money, or space is restricted.
2) The disk is
just an arm of the signal next to it. The asset name has collocated in it. You link to script collocated.lua. Stopping is eFalse. You place the single track link in advance of link 0 of the main signal.
This is just an extension of the other signal. It was called external disk originally.
The ID field does not take an ID but instead the routes for which this signal clears. 23 means this disk feels like arms 2 and 3 of the main signal. A leading C means it feels like the Call-On arm, too. C alone is possible.
If you want two disks in such a case, place two assets side by side, or stack them. The present script (FP External Disk.out) can only handle one disk. You will note that collocated.lua just has two plain variables for clear and stop animation, no array of arms.
3)
Wrappers that animate disks as a side business. I call these dependent disks, but this is unlucky because this term is used in the prototype in a way that does not at all relate to what we have here. My dependent signals are called such because they depend on the home signal in approach to them.
Their original name was facing disks, because you mostly need them when a disk faces a running movement. This is the main difference to case 1. These dependent disks here are the rare case where you are not in a siding and you do not look against the normal direction of travel.
In terms of implementation, these are like wrappers. Like them, they will send any digit you enter as a route character to the main signal, to influence which arm is cleared.
For very complex cases, there is a table in the manual how to control disk assignment and route character at the same time. This only comes into view if there is more than one disk on the signal.
Both asset name and script have "dependent" or "dep" in their names. The script links to FP Facing Disks.out in the require statement. The gArmTable lacks one dimension. This means you leave out the [ARM_HOME] compared to "normal" signals.
Note that if the animation is part of the main geometry file, then the child name is the empty string:
gArmTable[1][SEM_CHILD_NAME] = ""
This has no logical connection to disks, but the situation mostly occurs with single disk models.
4) If you are still feeling fine after all you read, I am glad to inform you that we are going to change that now. I put all blame on Keith (the RockDoc) and the GNR.
The GNR has a habit of using a single semaphore for more than one track. These typically are parallel sidings where there is no danger of two engines being there at the same time.
We know that RW signals can only have one link 0, so all you could do is move the single link 0 forward to beyond the convergence of these parallel sidings.
But then came Keith and tied my heart to the ley line between Derby and Nottingham which sounds bad enough. What is worse is that there are two places on Keith's route where there is no single convergence to stick that link 0.
One place is quite prominent -- Basford North aka Basford & Bulwell. There are two sidings that lead to 5 different tracks via a crossover with diamond. So there is no chance to put a single link 0 anywhere. There is also no chance to say "use two single disks and forget it" because the thing there is a five-arm 30ft lattice post signal.
Keith even caused Nick and John to get him such a thing, so I had to forget my oats to not complicate my scripts anymore. The net result is even more confusion on the disk front, because now we have an asset that is a bit like several collocated disks.
More precisely, I created Virtual Signals, which is a big name for a bog standard semaphore with no arms. It is linked to these fancy red bracks. Please do not confuse them with AI-only signals, though they too are invisible stop signals.
You place their link 0 where you want AI to stop, one in each of the track to which our shared signal belongs to.
Then I created a new, quite perverse asset that is something like a route indicator that listens on more than one track. It has as many links as there are virtual signals. Link 0 is just the same as link 1. Each of these links is placed in advance of one virtual signal, just like you would place external disks.
I had to call this
external arms to distinguish it from external disks, which are called collocated nowadays.
The bad news in terms of clarity is this: Since the virtual signal is nothing special, any normal signal could drive such an external arm asset. And that asset does not mind if its links just number one. And it never made a difference whether the arms are disk-shaped.
The net result is that you can use an "external arms" object in those cases where you want stacked disks at the foot of a semaphore.
The drawback of this new thing is that I did not provide any configurability. Arm 1 is cleared for route 1 and nothing else. But nothing stops you from creating a script for it that only has arm 2 and 3. Place it next a single arm home signal and the external disks/arms will clear for routes 2 and 3.
(I forgot to mention that the script looks like that of a dependent disk, except for linking to FP External Arms.out instead of FP Facing Disks.out.)
I need to sort the files apart before actually publishing that because right now I made a real mess with half of the files in the original Yelland folder and half under AusWorks. And the practical need at the moment is not too pressing. I just wanted to score in the Derby Extension progress department, because I need to.