Interlocking Tower problems

Dweezle

New member
I have made a small test route with a main line and a passing siding (loop). Tower paths can either take the main route or use the siding. If I place a stationary train on the main, like a passenger train stopped at a station, and then run an AI train on autodrive up to the signal, the signal just stays red even though there is a path available. If I drive the train, I am able to choose the route, but both paths are shown as clear even though there is another train right past the switch.

So the train occupying the block isn't seen, and the AI won't choose a path. This is on build 82718 with a fresh test route.

Also any way to get rid of the yellow symbols? Can't see the signals.
 
Last things first:). There should be a toggle (under tools menu, I think) for Navigation symbols. This will turn off the yellow discs in Driver, but will also turn off other Nav points such as turnout, stop, couple here, etc. that you might want in your session. A more permanent solution is in Surveyor. You need to add the Interlocking Tower Configure Path rule and set all paths for all ITs to disable automatic path assignment for both player and AI trains. That may or may not be desirable since you will then have to allocate all paths via triggered rules (player) or driver commands (AI).

So to your main query, and I should make clear that I am only going by what I have experienced or picked up from others far more knowledgeable than I am. Assuming that your test set up has the IT making automatic path assignments, you need to supply one or more 'anchor' points to get the right path selection for any AI train that approaches the IT section. To my knowledge, Autodrive will merely try to follow the path set in front of it which, in the absence of any other navigation marks, will likely be the 'Priority 1' path in the IT.

In your example, try placing a track mark after the loop. Then issue a driver command 'Navigate to track mark'. The IT should allocate the siding path, since the main line is occupied. However, there is a chance this may not work if the stationary train was placed there at the start of the session (linked to your second observation). I recall some discussion a while ago regarding the ability to un-couple from / couple to consists within IT paths; it may well be that a hitherto undriven train is considered as a consist that would not block access to its associated path. The easy way to test this would be to have the first train drive to a track mark / station on the main line, before commanding the second train to navigate to the track mark beyond the loop.

Finally, take a look at pguy's new MissionControl Manager (there's a thread on the Freeware Announcements forum). Although I have not yet tried it, MCM looks to give you the option of giving AI drivers alternate paths to follow, in case the primary path is blocked, and would seem to be a good solution for passing loops.

Hope this helps.
John
 
Thanks for the reply Vostrail!

You can turn off help in the quick drive section under session rules in surveyor. Also the junction overlays can be turned off under the Additional Tools menu in Driver. I have done this and the yellow disks are still there.

Maybe I was under the mistaken impression that a free path would be assigned to an AI driver automatically no matter if it was assigned a 'Navigate' or "Autodrive" command. I'm trying to see whether an AI controlled train will automatically use the free block to go around an occupied track without using a 'Navigate Via" or "to" command (I don't usually use these commands).

When I drive the train manually the both path choices are shown as clear even though there is a train occupying the block. I've tried it with both trains moving and it still shows clear. Under manual control my train will go through signal, which is green and stop behind the train occupying the block.

MissionControl Manager crashes 99% of the time I try to assign a mission to a train, so I think there is something messed up somewhere in my install or the latest upgrade. See pguy's post and replies in the Freeware Announcements section.

Steve
 
Thanks for the reply Vostrail!

...

MissionControl Manager crashes 99% of the time I try to assign a mission to a train, so I think there is something messed up somewhere in my install or the latest upgrade. See pguy's post and replies in the Freeware Announcements section.

Steve

Hi Steve.

MissionControl Manager is a new recently developed rule, so it may still have some remaining bugs to be fixed. But in order I fix the remaining bugs, it is important that you explain either by posting on this forum or by sending me a private message what type of problems you are currently encountering.

At least, if you can take a screenshot of the script error information (the detailed one with the list of calls with line numbers), it is often sufficient in 80% of the cases to find the bug origin. In more difficult case, I may need you send me via cdp a copy of your route and session so that I reproduce the problem on my configuration to find the cause and fix it.

There is currently a bug that appears only on some specific configurations with a script error of ER_NATIVECALL_ERROR in GameObject::Sniff routine. It will be fixed in next version currently under beta testing. If the error you encounter is this one, I have a temporary fix that I can send to you (this temporary fix suppress the error, but in case you couple or decouple a train, its mission code may be lost in the operation and you will need after any coupling/decoupling operation to set again the train mission code to avoid any problems).

If you are interested, contact me by PM giving me an email address to send you the temporary fix cdp.

There is also a new version of MissionCode Manager with some added functionalities which is currently under final beta testing, and I hope if there are no problems this new version to be uploaded on DLS in about two to three weeks from now.

Regards.
Pierre.
 
Thanks Pierre,

My main concern in this post is whether or not the IT should identify that there is a train, moving or otherwise, in a block. The choose path pop up dialog under manual control will show both routes clear even though there is a train visible right past the switch. Also I'd like to get rid of the yellow shields. (I have junction overlays and help turned off).

I left a 'me too' post in your freeware announcement post, I'll give you more details there.

Steve
 
@Dweezle.
Apologies Steve, I was mistaken regarding the Nav point visibility toggle. It is actually buried in the Trainz Control settings, just above the toggle for Metric / Imperial. On my system, it is mapped to Alt Ctrl N but I can't remember if that is the default or if I re-mapped it (I'm on a Mac).

Your issue regarding the occupied track is a strange one. Is the occupying train definitely still within the IT path? If the rear has passed the exit signal, then the IT path will show as clear. One other thing to look at; is your path entry signal configured to be Automatic or (the default) Proceed in the IT path configuration. I always try to ensure mine are changed to Automatic as I frequently encounter random issues with it set to Proceed. I could foresee, for example, that if you had a short path from entry signal across a junction to an exit (back) signal, and a stationary train was after the exit signal, then you would be reliant on the path entry signal to indicate the occupied track state. If it is not set to Automatic, it may well not indicate the correct status.

If your occupying train is indeed within the IT path, then I am at a loss since I have not come across an occupied path showing as 'clear' before. Perhaps there is indeed something wrong with your installation?

John
 
John,

Pguy answered the question in the other thread. Sort of odd or maybe incomplete behavior, but I guess I can live with it. Thanks for the info about the shields.

Steve
 
Back
Top