Interlocking Towers

coop2

Member
I made a path using Interlocking Towers and everything worked fine in one direction. Now I want the trains to reverse and go back to their starting points. When I try to design a pathway for the reverse path it makes the path only in the forward direction. Do I have to delete the first route in the session commands and then make a new route.
 
Do I have to delete the first route in the session commands and then make a new route.

I have yet to try ITs/EITs in TRS19 but that has not been my experience in TANE. All the reverse path requires is the right starting signal.

I would set up a simple test track in a new one baseboard route and test it there to see if it could be a bug or not.
 
All paths start at an entry signal which is the first signal in the paths direction of travel. So a simple one track would need two paths set up. Path 1 from signal A to signal B and path 2 from signal B to Signal A.
 
I tried to write a path in the reverse direction but the path kept defaulting in the forward direction.
 
Has the consist cleared the forward path? We can only assume the problem as we don't know the layout of the tracks and signals you have.
 
Dig into it. I just started using them last week. Now I added in mission codes and I have trains and paths going everywhere and doing different things. With the mission codes you can have the trains share a common path even if they are performing a different task. It's all really cool once you nail it down. And no more head on standoffs, no need to babysit your ai just drop in for a visit and watch how great they are working. Just jump in and plan on trashing the sessions you create in the beginning because you'll get much more efficient at working with this. To answer your specific question, yes you need a return path, just lay it down right over the first one going the other way. :)

LouP
 
When you define a path in the reverse direction, be sure that the entry signal is facing the direction of travel - i.e. you cannot use the back of a signal as the entry signal. If necessary, place an additional signal (can be invisible if you wish) to define the start of the reverse path.
 
Things become so easy when someone with a little more experience shows you how. I just checked my route and sure enough I didn't place signals facing for the reverse direction! Thank you for the help. I'll go right now and set it up.
 
I added my reverse path as a sub command to the forward path. Made sure all end Track Markers where after the end signals and the train cleared the end signal. It seems to be working OK. I don't know if making one path a sub command to a path command is the correct way to this. To me it make logical sense for the reverse path not to be used or seen by the program until the forward path has been completed.
 
Remember, you're just using this path to get to a destination. Once you're loco has cleared the path it will continue on to where you told it to drive or navigate to. The path doesn't need to go all the way, just far enough to prevent any confusion and/or collisions on a single track.

LouP
 
So now that some time has passed, I am understanding this whole thing much better. I am using mission codes to assign the various paths and tasks to the trains and all the ai seem to be automatically selecting the correct paths and managing to avoid conflicts with each other. What is still confusing to me is that even though I have assigned mission codes to the active player train, the correct path needs to be selected manually and is not being assigned automatically as with the ai. When the path selection window pops open for the active player, all paths are listed, even those not assigned to the active player via the mission codes. It's as if the mission codes are not even assigned to the active player (they are). I have the proper active player mission code assigned via a drive command right when the session starts. How do I get the active player to automatically pick up his paths as the ai are doing perfectly without having to select them in the pop up window.

LouP
 
So now that some time has passed, I am understanding this whole thing much better. I am using mission codes to assign the various paths and tasks to the trains and all the ai seem to be automatically selecting the correct paths and managing to avoid conflicts with each other. What is still confusing to me is that even though I have assigned mission codes to the active player train, the correct path needs to be selected manually and is not being assigned automatically as with the ai. When the path selection window pops open for the active player, all paths are listed, even those not assigned to the active player via the mission codes. It's as if the mission codes are not even assigned to the active player (they are). I have the proper active player mission code assigned via a drive command right when the session starts. How do I get the active player to automatically pick up his paths as the ai are doing perfectly without having to select them in the pop up window.

LouP

Hi LouP.

To have the active player automatically pick up his paths using EITs and MCM without any specific driver command, you need :

1 - to have the paths enabled for automatic path assignment at the path level. On the edit path page, you should have the path Assignment option set to either "Automatic" for paths being used for both AI and player train or "Automatic (AI only)" for paths being used only by AI train or "Automatic (player only)" for paths being used only by player trains. The assignment option should not be set to "Manual" which disables automatic path assignment for the current path and is reserved for sessions wanting to use only ITSetPath, or PathTrigger or Follow path methods as path assignment selection method.

1bis - at the tower level, I would also advise to have the tower yellow disc option set to "display yellow disc disabled", as you will no longer use the yellow disc option and associated selection box. I would also advise to suppress from the default rules the Interlocking Tower Path Selection UI rule which is the rule displaying the default N3V path selection box, which is no longer needed when using MCM. With this rule suppressed from your session, the display selection box can no longer be displayed in your session and will not interfere with your automatic path selection using MCM.
Of course this advise do not apply if you are using a mixed configuration with MCM being used for only some trains and the standard N3V selection box being used for some other trains with no mission codes (outside MCM).

2 - At MCM level (when you edit MCM rule), on the towers tab (the second tab from left) displaying the list of all available towers, you need to have Auto path assignment mode set to "Auto assignment on entry signal approach is enabled". If the option is set to disabled, it prevents automatic path selection on signal approach (setting reserved for session wanting to use only ITSetPath or PathTriggers or Follow Path assignment methods).

With these options correctly set, MCM should select one of the paths eligible for your train mission code when a train with an active mission code approaches an entry signal (at a distance of 0.5 mile) , but you can anticipate this automatic selection via MCM by running earlier an ITMCAssignNextPath driver command at any time (at less than 10 km from the next entry signal) or using pathtrigger defined in MCM rule for firing the automatic path selection process by MCM when your train reaches the path trigger.
Take care that if no paths are eligible for the train mission code, the train will remain stucked at the entry signal, until you add using the run time monitor a valid eligible path for the current train mission code.

If you have some trains with mission code stucked at an entry signal for an unknown reason, just open the MCM run time monitor and switch to the requests tab (should be last tab displayed only under the run time monitor not under surveyor). The requests tab should list all the requests made by MCM for the current train, with the request status and a short diagnosis if for any reason the request was not successfully processed or is delayed for any reason.

You can have also a look to the EIT Demo route - UK1 - Full session with MCM ( <kuid2:61392:8402:6> ) available on DLS that has its paths and MCM configured this way.

Hope this helps. If you need more help just ask.

Regards.
Pierre.
 
Thank you Pierre,

It worked out great. Turns out you need to remove the N3V rule for the manual selection box completely from the session. Simply unchecking the box in the rule doesn't cut it. It was so nice to have the path selected for you as you move along. One observation though, I saw some stuttering as the the paths were being selected and released that I did not notice in manual mode. Is there any way to alleviate that? I have a pretty hefty machine with an i7 8700K running at 4.5 gig, an evga gtx 1080 ftw, and 64 gig of memory. Also, TANE is fully running off a SSD and W10 is on it's own separate SSD. I was wondering if any of the other selections may be causing the stutter.

Thanks for all your help,
LouP
 
Hi LouP.

Difficult to give you an advice without looking to all your interlocking towers and paths configuration. I
can just give you a few tricks to enhance performance :

- keep your towers local and your paths short. For performance it is better to have more local scope towers with short paths than a few large scope tower with a lot of too long paths.

- keep your path short : when activating all path objects need to be loaded ; if your path is quite long it may need objects streaming to request loading of path objects currently unloaded.

- prefer static ownership to dynamic ownership when it is possible for towers. With static ownership, a tower initialisation takes longer time (it will take ownership of all of its path objects) but will be more efficient with less script code when a path needs to be activated. Dynamic ownership may be useful in yards and for situations where some path objects needs to be included in several paths belonging to distinct towers.

- in MCM, path eligibility is stored as an array of paths with for each path an array of eligible mission codes. And trains can have several mission codes active simultaneously. Performance are better using multi local mission codes assigned to a train, keeping path eligibility array with only a few mission codes than having one distinct mission code for each train, with path eligibility array with numerous entries.

- avoid PathTrigger when they are not needed ; PathTrigger adds a lot of script processing when used with some auto select processing done several times instead of being done once on entry signal approach. But if you need a PathTrigger to change the distance for path selection, use it ... but only when needed ...

To go further, as usual I need a cdp with a copy of your route and session with all dependencies not available on dls. After reloading your route, session and dependencies, I will first check that on my configuration (i7-6820HK 2.70 GHz 64 GB memory GPU GTX1070 8GB) if I also have some stuttering ; then using some internal tools I will check the sequence of MCM and EITs requests to check any anomalies and try to find the stuttering cause. I will also have a look to your EITs and MCM configuration to see if it can be optimized. Optimisation is mainly looking to avoid extra MCM or EIT requests not needed consuming some script cpu time.

Regards.
Pierre.
 
Last edited:
Hi Pierre,

I think you answered my question right off the bat. The session is utilizing one tower with many paths, some are long as they need to stretch the length of the single track.

The route is JRs Coal County which is also pretty demanding.

Still learning I guess :)

LouP
 
Back
Top