Enhanced Interlocking Towers not saving the "Try Requery" option. Bug?

[Smileyman]

I wanted to enable this option just to test it out, but even after I've saved the route and the session, if I exit to main menu and load it back in, the option is set to the default "Do Not Requery" option.
This is true in both the tower and in the Enhanced Tower Manager.

Does anyone use the Requery option, and does it keep the settings when you come back?
Oh, and Google AI said to check the EIT monitor, which it said was a green RT (?) to see if there was an active path, which would stop the option from saving.
I don't know what monitor it's talking about.

Cheers.

 

[johnarran]

I wanted to enable this option just to test it out, but even after I've saved the route and the session, if I exit to main menu and load it back in, the option is set to the default "Do Not Requery" option.
This is true in both the tower and in the Enhanced Tower Manager.

Does anyone use the Requery option, and does it keep the settings when you come back?
Oh, and Google AI said to check the EIT monitor, which it said was a green RT (?) to see if there was an active path, which would stop the option from saving.
I don't know what monitor it's talking about.

Cheers.

I've not used the "Do not Requery" option as the default works fine for me. Sorry, no help there.

The Run-Time monitor can be found under the Enhanced Interlocking Tower Manager Rule.

 

[Smileyman]

Thanks.

I found the run-time monitor (for me, it's accessed from the tools menu at the top of the screen when in Driver).

The default has worked for me too, for weeks, since I started using EITs, but the other day I found two trains in a stand-off at a station, with plenty of platforms available for the train waiting to come in, and an easy path for the train wanting to leave, without the other train getting in the way, but neither took the path they should have, and just sat there.

From what I understand, in that situation, using the try requery option would allow the EIT to release all junction and paths, and try again, and would have probably sorted out the stand-off.

But, no matter what I do, setting the option to retry doesn't save with the session (I'm talking about a normal route session, not a driver session).
I'm wondering if it's a bug with the EITs, and it's gone unnoticed because (a) not many people use EITs because of their learning curve, and (b) those that do aren't using the retry option.

It's strange.
It saves the option to the session while you're in it in Surveyor (going straight back in to the tower shows this), but if you leave Surveyor and load the session to edit again, it's gone.

I wonder if pguy forgot to add the setting to the soup in Trainzscript.
He did after all forget to add an include in his TimeTable rule (and no-one noticed until I posted about it).

It seems like it could have been a useful feature to fall back on in complex situations to allow the EITs to fix themselves, but I guess I'll just have to do without it.
I don't think Pierre is developing the system any further.

Any chance you could see if the option saves for you, just so I know it's not my session?
Make sure to use a copy of your session.
I wouldn't want you to mess up your working session trying something for me.

Thanks again.

 

[johnarran]

Thanks.

I found the run-time monitor (for me, it's accessed from the tools menu at the top of the screen when in Driver).

The default has worked for me too, for weeks, since I started using EITs, but the other day I found two trains in a stand-off at a station, with plenty of platforms available for the train waiting to come in, and an easy path for the train wanting to leave, without the other train getting in the way, but neither took the path they should have, and just sat there.

From what I understand, in that situation, using the try requery option would allow the EIT to release all junction and paths, and try again, and would have probably sorted out the stand-off.

But, no matter what I do, setting the option to retry doesn't save with the session (I'm talking about a normal route session, not a driver session).
I'm wondering if it's a bug with the EITs, and it's gone unnoticed because (a) not many people use EITs because of their learning curve, and (b) those that do aren't using the retry option.

It's strange.
It saves the option to the session while you're in it in Surveyor (going straight back in to the tower shows this), but if you leave Surveyor and load the session to edit again, it's gone.

I wonder if pguy forgot to add the setting to the soup in Trainzscript.
He did after all forget to add an include in his TimeTable rule (and no-one noticed until I posted about it).

It seems like it could have been a useful feature to fall back on in complex situations to allow the EITs to fix themselves, but I guess I'll just have to do without it.
I don't think Pierre is developing the system any further.

Any chance you could see if the option saves for you, just so I know it's not my session?
Make sure to use a copy of your session.
I wouldn't want you to mess up your working session trying something for me.

Thanks again.

I just set up a test session and can confirm that changes to 'Try requery path' DO save. So, no bug.

Your problem with trains at deadlock may be a signalling issue or incorrect path set up.

 

[Smileyman]

Your problem with trains at deadlock may be a signalling issue or incorrect path set up.

Yeah, that was my thought when it happened, and I spent a good amount of time going through the paths again (and they've been gone through many times as I've built this area, so I was sure they were fine..and they were), and the signalling looked OK, in fact pretty simple.
It hadn't happened before, or since.
Very strange.

I just set up a test session and can confirm that changes to 'Try requery path' DO save. So, no bug.

Interesting!
Thanks for doing that mate.
That eliminates that.

Now I can delete the tower, replace it, and see how it goes.
I think I can copy&paste the paths from one tower to another using the tower manager (I hope I can).
I'll be saving the original session as a test session, so I don't destroy my original!

I wonder what corrupted the tower (or possibly session!).

Thanks again.

 

[Smileyman]

Well, having replaced the tower, tried it on a different layer, and many other things, nothing allows the option to 'try requery' to be saved and loaded in.
It's always set to 'do not requery'

So, I set up a test route like you did, and placed an EIT on the baseboard, changed it to 'do not' (because it defaults to 'retry'), saved, exited, reloaded, changed it to 'retry', saved, exited, reloaded, and sure enough, just like your test, it had saved the option.

I got to thinking that either my route or my session has been corrupted somehow (there's been no signs of this), or something else is stopping this setting from saving, either on purpose or in error.

Having tried deleting default rules and putting them back in, doing a save/load test in between each one to check, I then moved on to adding some of the rules that I use in my proper route and session.

No luck there, until....I added the MissionCode Manager.
The MissionCode Manager being added to the session stops the individual towers from saving the 'requery' option, setting it to 'do not' every time a session is run.
I have checked various settings in MCM, and so far, none of the options in there that I have toggled have stopped the MCM from setting all towers to 'do not requery'.

So, either there's an option I haven't tried yet that purposely changes all the towers to 'do not requery' or it's a bug, with MCM conflicting with the towers ability to save this one option.

And I'd like to get the 'requery' option working, because I was running a session earlier and 2 trains got stuck waiting to leave Newport.
One was on platform 2 and the freight train was on the freight lines between platforms 1&2, and all other trains had gone, and were well clear and out of sight.

So, when this happened, I thought I'd use Surveyor 2.0 to edit it in real-time and change the option to 'requery' and then resume the session.
I had already waited more than 5 minutes for them to depart before deciding to do this, and I really wanted to see if 'requery' was what I thought it was.
I changed the option, and resumed the session, and...both trains got the green light (they don't interfere with each other's path) and off they went immediately.

This shows that requery is definitely worth having set to on, but it seems I can't have that with MCM running.
But MCM runs the whole show, so I don't know.

Maybe I missed a setting in MCM that's doing this.
Fingers crossed.

 

[johnarran]

Well, having replaced the tower, tried it on a different layer, and many other things, nothing allows the option to 'try requery' to be saved and loaded in.
It's always set to 'do not requery'

So, I set up a test route like you did, and placed an EIT on the baseboard, changed it to 'do not' (because it defaults to 'retry'), saved, exited, reloaded, changed it to 'retry', saved, exited, reloaded, and sure enough, just like your test, it had saved the option.

I got to thinking that either my route or my session has been corrupted somehow (there's been no signs of this), or something else is stopping this setting from saving, either on purpose or in error.

Having tried deleting default rules and putting them back in, doing a save/load test in between each one to check, I then moved on to adding some of the rules that I use in my proper route and session.

No luck there, until....I added the MissionCode Manager.
The MissionCode Manager being added to the session stops the individual towers from saving the 'requery' option, setting it to 'do not' every time a session is run.
I have checked various settings in MCM, and so far, none of the options in there that I have toggled have stopped the MCM from setting all towers to 'do not requery'.

So, either there's an option I haven't tried yet that purposely changes all the towers to 'do not requery' or it's a bug, with MCM conflicting with the towers ability to save this one option.

And I'd like to get the 'requery' option working, because I was running a session earlier and 2 trains got stuck waiting to leave Newport.
One was on platform 2 and the freight train was on the freight lines between platforms 1&2, and all other trains had gone, and were well clear and out of sight.

So, when this happened, I thought I'd use Surveyor 2.0 to edit it in real-time and change the option to 'requery' and then resume the session.
I had already waited more than 5 minutes for them to depart before deciding to do this, and I really wanted to see if 'requery' was what I thought it was.
I changed the option, and resumed the session, and...both trains got the green light (they don't interfere with each other's path) and off they went immediately.

This shows that requery is definitely worth having set to on, but it seems I can't have that with MCM running.
But MCM runs the whole show, so I don't know.

Maybe I missed a setting in MCM that's doing this.
Fingers crossed.

I don't encounter the problems you are experiencing. Without appearing rude and no offence intended, I think you may need to look at MCM documentation again. Trains can be deadlocked if not set up correctly. Here is a snippit from the documentation...

When looking to available paths when a train reaches an entry signal, Mission code Manager uses a method similar to the standard Interlocking Tower QueryAutomaticPathAssignment method : it will look only to paths with the AI auto assign flag set are available for AI trains and only to paths with the Player auto assign flag set are available for players driven train. if no paths are available meeting these criteria, no path assignment is done and the train will be stuck when arriving at the entry signal. If you are using manual paths (paths with no AI auto assign flag set or Player auto assign path set ), you will need to use path trigger (explained later below ) to auto assign manual paths.

Also you have said in another post that you don't fully understand signalling. Signalling must be setup correctly for EITs and MCM to work as expected as they form the basis of Interlocking Tower path configuration. I would suggest having a read about block signalling concepts and try again. There was a guide - Trainz TC3 Signalling Tutorial.

Regards,

John

 

[Smileyman]

Oh, no offence.
As I said in the other thread, I know nothing but the basics of signalling, so the cause of any deadlocks could well be down to that.
I know a lot more about signals now than I did 24 hours ago thanks to links from people on here, and I will master them, but this is Trainz, and it doesn't always play ball.

But, as the title of this thread suggests, I'm more concerned about why MCM is stopping the requery option from being turned on.
Obviously a setting I haven't found yet, or a bug.
And as my example shows, the requery option can sort out a deadlock automatically by releasing signals and junctions when it's safe to do so, and trying to path again.

A deadlock can happen rarely to someone who knows how to set up signals, and more often to those like myself who don't, but the requery option is there for just such an occasion because it can happen.

If you were to add MCM to your test route, you would see that the requery option no longer saves the selected choice (or it does save and load it next session, but MCM is overwriting it for all towers immediately upon loading. It could be either).

I don't mind the occasional deadlock, this is 'Trainz' after all, but if there's a built-in way to try to resolve these situations, then I would like to use it.

The problem with bugs like this, if it is a bug (the unsaved option, not the deadlock), is that not that many people use EITs and MCM, probably because of a combination of EITs learning curve and Trainz unreliability, and so these things don't get reported and fixed.

There's very little info on EITs and MCM out there, beyond the basics, so it's very possible that Pierre wasn't even aware of a hidden 'bug' like this one, and I don't think he's developing it further (is he still active in the community).

I will press on!

 

[johnarran]

Oh, no offence.
As I said in the other thread, I know nothing but the basics of signalling, so the cause of any deadlocks could well be down to that.
I know a lot more about signals now than I did 24 hours ago thanks to links from people on here, and I will master them, but this is Trainz, and it doesn't always play ball.

But, as the title of this thread suggests, I'm more concerned about why MCM is stopping the requery option from being turned on.
Obviously a setting I haven't found yet, or a bug.
And as my example shows, the requery option can sort out a deadlock automatically by releasing signals and junctions when it's safe to do so, and trying to path again.

A deadlock can happen rarely to someone who knows how to set up signals, and more often to those like myself who don't, but the requery option is there for just such an occasion because it can happen.

If you were to add MCM to your test route, you would see that the requery option no longer saves the selected choice (or it does save and load it next session, but MCM is overwriting it for all towers immediately upon loading. It could be either).

I don't mind the occasional deadlock, this is 'Trainz' after all, but if there's a built-in way to try to resolve these situations, then I would like to use it.

The problem with bugs like this, if it is a bug (the unsaved option, not the deadlock), is that not that many people use EITs and MCM, probably because of a combination of EITs learning curve and Trainz unreliability, and so these things don't get reported and fixed.

There's very little info on EITs and MCM out there, beyond the basics, so it's very possible that Pierre wasn't even aware of a hidden 'bug' like this one, and I don't think he's developing it further (is he still active in the community).

I will press on!

This is not a bug. I think it is by design. Think about it. MCM activates the paths you have set up previously in EIT, using the codes you assign to the trains. If you then allow EITs to requery paths independently this could potentially cause a conflict and stop MCM working. The whole point of MCM is to set a clear path from A to B so that traffic flows without disruption. So I don't think it is a bug at all.

Signalling underpins everything.

I do not know how you have set up your track configuration but Newport is not straight forward is it.
So one thing to consider is the use of 'Exclusive Sets Membership'. Could this help at all in your scenario?
Here is a link, have a look. https://online.ts2009.com/mediaWiki/index.php/Enhanced_Interlocking_Tower_Tip_001

I use EITs, ESMs and MCM on all my sessions, without which complex setups and operation would be a nightmare. It is a godsend.

Pierre is still active and still supports EITs.

 

[pguy]

Trying to explain. There are two distinct requery mechanism, one in EIT and one in MCM rule. To avoid conflicts between thèse two mechanism, when MCM is active in a session, it will disable in all towers the path requery option, So when you are using MCM it is normal that the EIT requery option is enforced to disable.

WIth MCM you no longer can use EIT requery facilite, but it does not matter as you should benefit directly from the moré powerfull MCM requery integrated mechanism included in MCM scripts.

MCM requery facility is moré powerfull because it can use any éligible paths defined in MCM when requery is needed ; EIT requery mechanism will always try to activate the same initial path until the path is available.

IF you are not using MCM (rule not loaded in the session rules), you should be able to décide for each EIT if you activate or not local requery facility at the EIT level.

Hope this helps.
Regards.

 

[johnarran]

Pierre comments above confirm what I was trying to say. So no bug.

 

[Smileyman]

Hi Pierre.

Thanks for responding to my PM and for the clear explanation.
Very much appreciated.

It now makes perfect sense, and I can stop worrying that I'm missing out on the requery functions.

Now I just need to improve my signal knowledge and signalling (I'm working on it), and all will be well.

Thanks again, and hope to see you back in the Trainz community soon.

All the best,
Brian.