John Yelland (BR(WR) Distant)

[Carinthia]

I have been trying to get in touch with John Yelland by email concerning the scripting of a specific signal of his - I have tried two email addresses I had but one is dead and the other unanswered. I am hoping I might find him on this forum?

If not, and anybody knows how to get in touch I am interested. He may of course have left the hobby, in which case I might discuss the issue I am experiencing here and beg for help.

Thanks in advance on all counts.

John

[AndiS]

John, this starts to become a depressing hobby. Last post by John on UKTS was occasioned by the parting of another John. Scary.

In the worst case, I sure could make a few guesses about his scripts.

[Carinthia]

John, this starts to become a depressing hobby. Last post by John on UKTS was occasioned by the parting of another John. Scary.

In the worst case, I sure could make a few guesses about his scripts.

Let's hope for the best and that things are OK with John. I've been away from the hobby quite a while for various reasons but am still here . . .

I suppose the first thing I should ask is whether an update has been issued which I haven't found. The problem I am experiencing is with his BR(WR) lower quadrant series, which I think is UKTS file 34040. I can't see any updates anywhere. These are Kuju-style scripts, of course, and not your advanced ones.

The signal concerned is the (independent) distant signal arm which I believe has been accidentally scripted as a stop signal. There are three reasons I believe this to be the case:

1. When a player train is following an AI train, the signal at the entry to a block section clears as soon as the AI train passes clear of the distant signal for the next signal box
2. If an AI train is standing ahead of a signal box's home signal (e.g. at a station platform), which will be at danger, the distant signal will show "clear".
3. The distant signals display on the F3/F4 moving display, which they wouldn't normally.

I hope the above makes sense. The route I have particularly noticed this on is the Wycombe Railway and Joint Line from Steam Sounds Supreme, but I have them on other routes too.

Of course an AI train will obey any stop signal regardless of the actual look of it, but my concerns are with player trains following AI trains. If it is possible to replace some code, I would like to do that. The alternative is to go through the entire (large) route and replace all the signals concerned with his GWR ones, which would be very time consuming but not impossible.

Any thoughts or suggestions would be welcome,

John

[AndiS]

This sounds a bit like a problem with the .bin file of the signal, more than like a script issue. But it seems to be two issues combined.

The easy thing is to ensure that in the .bin = .xml file of the signal, at isStoppingSignal or so (actually the only occurrence of stopping in the file, as far as I remember) you got eFalse and not eTrue. With eFalse, it should not show on the map.

The not so easy thing is to find out if the script referred to in the .bin file is a script for a distant signal. This distant clearly feels like a block signal as far as scripting is concerned. I have a vague memory about some default signal in the first release of the game doing that but I have not heard about the issue in a decade. So I guess there has been some fix around Railworks 1 or 2 era.

If you give me the name of the script, I can do a bit of digging around, provided this PC holds old enough stuff. Alternatively, you could drop the whole script into a post, using the Code button or else the BB software destroys the indentation.

[Carinthia]

Thanks very much for that. I'm in danger of stepping outside my knowledge zone, so I am going to tread carefully.

The BIN file concerned is \Steam\steamapps\common\Railworks\Assets\Yelland\Addon\RailNetwork\Signals\UK Semaphore\BR(WR)_Arms\BR(WR)4ft Dist.bin . I have opened this file in TS-Tools and the entry for <_script> makes the following reference:

Code: Select all

<Name d:type="cDeltaString">Yelland\Addon\RailNetwork\Signals\UK Semaphore\Sem_HomeSig</Name>

Amongst the many scripts there are lua files:
Sem_HomeSig.lua
Sem_DistantSig.lua
also similar names:
Sem_DistantSig.lua.tgt etc
Sem_DistantSig.out etc

Could the fundamental issue really be resolved by swapping one out for the other in the reference? Or am I being too simplistic?

Noted your point, of course, about <Stopping d:type="cDeltaString">eTrue</Stopping> which I can easily change too.

Best regards,

John

[AndiS]

In the line you show, change Sem_HomeSig to Sem_DistantSig and cross your fingers with all the positive energy you can scrap up.

Things like that have happened it the past, to many people on many occasions. But don't relax before you are really sure it was just that.

[Carinthia]

In the line you show, change Sem_HomeSig to Sem_DistantSig and cross your fingers with all the positive energy you can scrap up.

Things like that have happened it the past, to many people on many occasions. But don't relax before you are really sure it was just that.

Ha ha, I love that. I will try this when I get a moment - probably tomorrow.

I shall let you know how things go.

John

[Carinthia]

All good! The signal is working properly now.

Thanks so much for steering me through this, really appreciated.

John

[AndiS]

Now the only open issue is whether John's health is twice as hard to fix or ten times as hard.

[Carinthia]

I thought I had tested this thoroughly but have just discovered that whilst checking it did the things it didn't do before, I didn't check what it DID do before! I found that the signal arm itself was sticking resolutely in the "caution" position.

With a little poking around I found that by changing the entry for the Child Object from:

Code: Select all

<ChildName d:type="cDeltaString">Main Home Arm</ChildName>

to

Code: Select all

<ChildName d:type="cDeltaString">Main Dist Arm</ChildName>

resolved that and I believe it is working 100% now.

I just thought it worth mentioning here in case anybody is using this discussion for reference. (I have also improved the subject line for that reason).

Meanwhile, I do hope John is OK. He has done a few things for me in the past, including creating a couple of special signals. I owe him a lot.

Best regards,

John