Signalling with AndiS Scripts

Re: Signalling with AndiS Scripts

Postby oldoakcom » Sat Oct 28, 2017 7:19 am

Hi should say hello and introduce myself im oldoakcom Name Comes from the ´Depot i used to work at as secondman and a Driver in the 80s

I am a AndiS script convert and must really say i wouldnt go back, ok on the routes that are allready signalled with the defoult scripts ok, but once youve seen Andi´s scripts working those arms, you just sort of cringe when you see them in a non Andi´s scripted route.

Widewanderer I know exactly what you mean by not Feeling right, as someone who went down to exeter on normal and summer Specials, was so glad to have worked under Semaphore from westbury westwards also on the newline as they Drivers used to say at OOC

I have joined up with Auscgu and somewhere on here (sorry bit new to remeber where on here) he has started a post aboout our plans.

But glad to help anyone whos promozes the use of those (mutts nuts) scripts

oldoakcom
oldoakcom
General Shed Duties
 
Posts: 20
Joined: Wed Oct 25, 2017 12:45 pm
Location: England
Has thanked: 0 time
Been thanked: 0 time

Re: Signalling with AndiS Scripts

Postby AndiS » Sat Oct 28, 2017 8:42 am

Welcome! Auscgu posts about work in progress in the Members Only Chat.
AndiS
Top Link Driver!
 
Posts: 736
Joined: Wed Apr 09, 2014 5:48 pm
Has thanked: 268 times
Been thanked: 308 times

Re: Signalling with AndiS Scripts

Postby AndiS » Mon Nov 06, 2017 12:20 am

I attach this file here. It contains the scenery with the detail level fixed at 10 plus some variants of the disks.
Please extract the ZIP in railworks\Assets\AusWorks\FP_JYelland.

And please get rid of the stupid files listed below. I generated 1T variants for distants, which is total nonsense.

BR(WR)4ft Dist.xml
BRS_CL Sig_d.xml
BRS_CL Sig_dstriped.xml
BRS_TU Sig_d.xml
BRS_TU Sig_Gnty_Sub_d.xml
GNR_20ft Concrete_Sig_d.xml
GNR_25ft_Concrete_Sig_d.xml
GNR_25ft_Concrete_Sig_fd.xml
GNR_20ft_Lattice_Sig_d.xml
GNR_25ft_Lattice_Sig_d.xml
GNR_25ft_Lattice_Sig_fd.xml
GNR_GNTY_Sig_Sub_d.xml
GNR_GNTY_Sig_Sub_fd.xml
GNR_20ft_Wooden_Sig_d.xml
GNR_25ft_Wooden_Sig_d.xml
GNR_25ft_Wooden_Sig_fd.xml
GWR(PSL) Sig_d.xml
GWR 5ft Dist.xml
GWR4ft CB Dist.xml

Edit: Please forget the file I attached yesterday. No testing does no good! The version you see now, with "Fix 1" in the filename should be more sane.
Attachments
Signals Part 2, Fix 1.zip
(302.62 KiB) Downloaded 446 times
AndiS
Top Link Driver!
 
Posts: 736
Joined: Wed Apr 09, 2014 5:48 pm
Has thanked: 268 times
Been thanked: 308 times

Re: Signalling with AndiS Scripts

Postby AndiS » Tue Nov 07, 2017 11:54 pm

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.

5-arm-slave.jpg


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. :)
AndiS
Top Link Driver!
 
Posts: 736
Joined: Wed Apr 09, 2014 5:48 pm
Has thanked: 268 times
Been thanked: 308 times

Re: Signalling with AndiS Scripts

Postby Rockdoc2174 » Wed Nov 08, 2017 7:27 am

This is one of those occasions when I can see that the language is English and that there are well-formed sentences with a conventional structure but I can't understand a word!! :-) I look forward to seeing this in game on The Friargate Line, Andi!

Keith
Rockdoc2174
Driver
 
Posts: 466
Joined: Mon Apr 14, 2014 10:52 am
Has thanked: 137 times
Been thanked: 213 times

Re: Signalling with AndiS Scripts

Postby oldoakcom » Wed Nov 08, 2017 7:45 am

LOL to the last comment

When I scrolled down it hit me, this is a Problem I had at Annesley there are many ocasions of this all over the Network.
I shall be following closly as this should be fun, this really put a smile on my face and am now going back to cracking Kingswear

Cannot wait to try this out

oldoakcom
oldoakcom
General Shed Duties
 
Posts: 20
Joined: Wed Oct 25, 2017 12:45 pm
Location: England
Has thanked: 0 time
Been thanked: 0 time

Re: Signalling with AndiS Scripts

Postby oldoakcom » Wed Nov 08, 2017 7:56 am

sorry to double post but another bolt of lightning just hit me Andi, the disk at Kingswear is a collacted disk I made refeencing the old FP External Disk.out but with another Name to avoid confusion.
Looking at what you wrote at (Point 2) maybe putting C after the 3 and 4 in the the box willl cure the Problem of it coming of as a callon or maybe not but ist somthing to try of cause using the new collacted.lua

oh well off to find out another excuse to find more time to Play

oldoakcom

by the way i like those fancy red bricks
oldoakcom
General Shed Duties
 
Posts: 20
Joined: Wed Oct 25, 2017 12:45 pm
Location: England
Has thanked: 0 time
Been thanked: 0 time

Re: Signalling with AndiS Scripts

Postby AndiS » Wed Nov 08, 2017 11:09 am

oldoakcom, I guess you simply must forget putting anything like an ID into the collocated disk. The collocated disk is not a signal proper. It is an adjunct to the "real" signal, like a route indicator.

Therefore, the ID field is abused for configuration. You simply enter 34 there if you want the disk to behave like arms 3 and 4 of the real signal.

I believe C must come first, if you use it. And if you don't want call-on functionality, just leave the C out.

That said, using the old "FP External Disk.lua" from Assets\AndiS\FPKuju is the way to go. It is the same file that now is "collocated.lua" in Assets\AusWorks\FP_JYelland\Signals\scripts.


Keith, please send your protests to DTG and light a candle that they do/did better for TSW. All these tiny bits going a long way to pretend they were controlled by a signal box really are a pain.


I guess the above rant can be summarised like this:

  • Is it a proper, stand-alone signal that happens to be a disk? Then use case 1 - "normal".
  • Is it just an extra arm of a signal nearby that never acts on its own? Then use case 2 - "collocated". (see Note 1)
  • Would you have case 1 but you do not want AI to stop their and treat the disk like a normal stop signal? Then use case 3 - "dependent". (see Note 2)
  • Would you use case 2 but you have more than one disk or arm in the model that forms the adjunct? Then use case 4 with a normal signal instead of the virtual signal and a single link version of the External Arm object.
  • Do several tracks share the same signal and there is no place beyond a convergence where you can more link 0 to? Then use case 4 a virtual signals in each track and one External Arm object with multiple links.

(Note 1) Consider the fact that any 3 ft arm that sits on an extra bracket at the post of some signal makes a perfect use case for "collocated disk".

In all cases of "collocated disk", you would have the option to integrate the disk into the model of the main signal if you would want to do that. This is what really distinguishes the case.

(Note 2) Historically, the dependet signal could do tricks with route numbers that the normal signals could not. But then the latter closed up, so currently there is not too much need for dependent disks.

The main point really is that at a dependent disk, you don't want AI to stop for the track ahead to clear. You want AI to stop at the main signal in approach to the disk. Then you certainly need a dependent disk.
AndiS
Top Link Driver!
 
Posts: 736
Joined: Wed Apr 09, 2014 5:48 pm
Has thanked: 268 times
Been thanked: 308 times

Re: Signalling with AndiS Scripts

Postby Widewanderer » Thu Nov 09, 2017 11:41 am

Hello Andi,

A million-and-one thanks for your little gems of wisdom about configuring External discs/PLS above - I had no idea that I could have both "C" and route digits combined in the same ID, to get, say, white lights to show for both specified routes and for calling-on in the same signal. That's something which is quite crucial for the colour light I want at the Minehead station throat on the WSR Members' Edition, where I need calling-on for the main platforms, and white lights always for entering the sidings and loco shed. I was about to accept that I could not do both at the same time, and to resort to using a scenario-specific calling-on MP for shunting moves into the shed and sidings...

Brilliant, Andi - keep those little gems coming, eh? :D

Best wishes,
Rob :-D

Saul Junction, Glos.
User avatar
Widewanderer
Fit for Firing Duties
 
Posts: 43
Images: 32
Joined: Sun Nov 02, 2014 5:09 pm
Location: Saul Junction, Glos.
Has thanked: 20 times
Been thanked: 11 times

Re: Signalling with AndiS Scripts

Postby Widewanderer » Fri Nov 10, 2017 7:51 pm

Andi -

Do you happen to have a little snippet of code lying about that could be used for a PERMANENT AWS RAMP?

I have your script for the normal AWS ramp, however my latest project could do with some Permanent AWS ramps in advance of distants. These are for fixed distant signals, which, for operational reasons in the sim, actually need to be working signals buried beneath the ground; I would like to avoid the odd occasion when the hidden working signal decides to clear, giving the driver an odd AWS bell in the cab, instead of the horn.

The reason for all this is that I observed some very odd stop signal behaviour in one passing loop situation when I tried to "fix" all the distants with $E in the ID. I've no idea why this occurred, but suffices to say that when the "$E"s were removed again, everything went back to working normally. I've spent several days investigating this, but have given up the search for a lucky signal configuration involving the "$E"s, as it was starting to give me headaches! The suitable work-around is available, so I think I'll stick with that ;)

Thanks as always :)
Last edited by Widewanderer on Sat Nov 11, 2017 9:19 am, edited 1 time in total.
Rob :-D

Saul Junction, Glos.
User avatar
Widewanderer
Fit for Firing Duties
 
Posts: 43
Images: 32
Joined: Sun Nov 02, 2014 5:09 pm
Location: Saul Junction, Glos.
Has thanked: 20 times
Been thanked: 11 times

PreviousNext

Return to Route Creation

Who is online

Users browsing this forum: No registered users and 2 guests

cron