ATLS change affects custom crossing layout. Suggestions?

ctclark1

Member
This isn't a show-stopper by any means, but on a prototypical level has some effects, and I'm assuming it has to do with the change to the "stream" style and elimination of the invisible trains.

This is a proto route I'm working on where there's two main railroads (separate operators) running about 150ft apart from each other for a section, involving 4 road crossings. Prototypically these crossings are interconnected in such a way that, in the image, if the top crossing is activated, both of its gates will close as well as the "outer" gate on the bottom crossing, and vice-versa. This works fine and dandy. I even have it set up such that if, while the top track is activated, a train approaches on the bottom track, the "inner" gate on the bottom will close as it should. The problem now, and one which would work correctly using the invisible trains in the past but no longer works with the "streaming" slaves, is that when this happens, whichever train clears the crossing first cancels all of its associated gates/stoppers leaving only the "inner" one of the train still in the crossing active.

As I said, this layout (using the old school controller/slaves) used to work with the invisible train method and I assume it has to do with the way the new "streaming" works. Without knowing details of the scripting, I presume there's basically an "activate" and "clear" command sent over the "wire" track and the devices just pay attention to this, which gets cleared, but it's not an "active monitoring" of the track like the invisible train was. I was wondering if maybe boat or someone else might have some insight as to whether I might be able to keep this working? Or is my only option to just set everything to one channel and have all the gates close at once?



EY9LDqX.jpg
 
Hi CT,

I think I can see what's happening. (I hadn't thought of this way to set it up!)

I see you are using 2 Channels to control the same 2 crossing assets.

With the old invisible train Slave, when the crossing becomes active, the invisible train is created. It stays there till the crossing is deactivated.
Therefore, since you are waiting for 2 Channels to clear, there will always be a minimum of 1 invisible train in existance if either Channel is active. That single invisble train is enough to keep all assets it's connected to active.

However, with the Slave Trigger it's different. This sends out a single 'activate' command when your visible train arrives. When that train clears it's first Channel, the Slave sends out a single 'de-activate' command. Since you have it looking forward to both assets, the first clear will de-activate both assets. When the second Channel clears it just send out a second de-activate. But you won't notice since it's already been de-activated.

You will have to go back to the Slave(TF) with the invisible train. The latest version which I've just updated is still OK for streaming.
The issue with the invisible train is that it uses a lot of resorces. (Think sledge hammer and wallnut!). I know N3V always look at ways to speed up scripts and methods everytime they produce a new version of Trainz. So I worry thet one day invisible trains may become obsolete.... but unless Stagecoach can think of something, you don't have a choice!

Hope that helps,

Boat

PS - There is also a newly updated ATLS Trigger, kuid2:76656:500016:15. Plaese update that too!
 
Last edited:
I thought maybe that was how the scripts worked.

On one of the crossings I tried adding a third ATLS channel to control the "common" gates with another complete set of triggers in the exact same locations as the originals (which is a lot of triggers - in reality the "top" crossing has three tracks and both rail lines have switches near the crossing that I triggered as well... I believe I have 17 triggers on that channel alone, plus 17 more triggers then distributed among the other two channels... ) -- It works, but that's a lot of triggers to manage though, so I probably won't be doing that with the other 3 crossings on this section of line, sounds like the invisible train is the easier option unless, as you said, Stagecoach comes up with a different idea.

And yes, it's been updated! ;)
 
Had a look at different ways but as boat said only a single command is sent. What needs to happen is for an asset to get commands and add them up and only activate when the count returns to zero. So a slave sends a +1 command to the assets which adds it up. The slave then sends -1 command so deducts it. Two channels will have sent 2 commands and if 1 channel sends a -1 command the asset will not activate until the second channel sends a -1.
 
I have just contacted BOAT about this and a possible solution. I am not a script writer but hopefully boat will be able to work magic with my suggestion.
 
I think the Slave with invisible train is your best bet for now. I'm in the middle of updating ASB Turnout at the moment. I'm afraid that will keep me busy for some time.

All the best,

Boat
 
Bug #2. I figured I didn't need to create a new thread since this one is mine and also is another side-effect of the changes made to ATLS for "streaming"

I noticed when setting up a quad gate crossing that the new streaming control method bypasses certain settings set in crossing objects, in particular the Gate Delay. See this video: https://youtu.be/SzOtc4zr2Lc (Warning- lots of bells!)

The group of gates on the left are controlled with the new streaming track-object slave. The group on the right are controlled with the older "invisible train" scenery object slave. Within those groups, settings are identical between their respective counterparts - the 2 scenery gates on the "right" side of where the road would be are set to the normal 5 flash delay (times .75 second - 3.75 seconds), the scenery gates on the "left" side of where the road would be, as well as the full crossings in the back, are set for a 20 flash delay (15 seconds). As you can see, all the gates in the left group drop immediately while those in the right group wait their appropriate times.

The crossing objects are, from front to back, <kuid2:321936:101446:1> RR Crossing 12x24M ST by ryanstrains, <kuid:39134:102483> Grade Xing NRC 4L Gated by bnsf50, and <kuid2:39134:101145:3> Grade Xing US 07 2L 2T LED by bnsf50. Obviously the common denominator in all of this is the script by Andi06, which sadly means that part will probably not be fixed unless someone has the ability/permission to modify his scripts. I'm more curious using the streaming method if this can be fixed on the ATLS side to maintain compatibility, or is this another instance where the invisible train method will have to hang on for as long as N3V allows it, until they don't anymore?


PS, I've also run into some issues using gates in a non-LCM mode (full intersection setup), where the gates will activate for a short time and then go back up before they should, but I don't believe that's entirely tied to this streaming method because it seems to happen with both the new and old style slaves... I'm still testing on that.
 
Back
Top