Signals not holding their settings in TS19

neilsmith749

Active member
Ok - this may entirely be OPERATOR-ERROR, but I've never had this problem in the last 20 years or so of Trainz. I'm using NS37's Vader-type programmable signals on the UMR. When I load the Base Session from TANE into the TS19 version of the route (making all the necessary changes in the config), it loads fine, and the signal settings are there. Then once I save it, either as just the session, or the route AND session, upon reloading, the signals have all lost their settings.

Is there a way to have the signal settings saved to the route, instead of the session? That way they'd always be there. I've noticed the industry settings are saved to the route, so it seems like it should be possible to save signal settings as well.

Not sure if something has changed, or if I'm doing something incorrectly in the properties box of the signals ("layer" and "bound" settings (?)), but I haven't had this problem before. Am I losing what's left of my mind????
 
Neil
I am having the same issue. I have tried to set them up in a base session but they are not holding their settings. i am using justinroth signals and the beta version of 2019
 
I've tried setting them up in a session, and to no avail. It always worked in previous versions - not sure what the difference is here. Thanks for the confirmation Hemler - I'm glad I'm not the only one that's having this problem. I'm hoping it's just my own incompetence, and not a major problem with TS19.
 
Maybe the quickest way to get an answer is to contact the help desk. It may indeed be a bug, but maybe something has changed in TRS2019 as the way to save these settings. Send them the asset kuid with a description of the issue and see how they respond. I have always had good experiences with the help desk.

i say this because when I imported several of my routes from TANE several of my passenger stations seemed to have lost their settings for things like number of passengers on platform, etc. I didn’t pursue it further because I simple reset the parameters in TRS2019 and they seemed to hold. In one case I simply swapped out one station with another and moved on. So something may be slightly different in saving parameters.
 
I had a problem with the signals remaining red in the Drive session and to correct it I was instructed to go to the Dev settings, Compatibility, Maximize Compatibility. That fixed the signals. Maybe it will work for you.

John
 
I've submitted a ticket to the help-desk to see if there is anything they can re-create. Thanks for the suggestion Paul!
 
They should make them where they automatically save in the Route Layer and not the Session Layer. I want to be able to program them once and then have them do what they're supposed to do for every session.
 
I have an issue with that too. Especially when I'm in AI mode and when I have trains running for a long distance. I have to take the trains off of AI and then manually drive them past the red signals.
 
In my case I have found that where permission to proceed is thwarted by a signal then there is a problem further up the line.

In any case I have not and do not mess with any settings.

I utilise the program TRS2019 SP1 as installed.
 
Sounds like the temporary reds I get. N3V said, after a bug report, that the red signals are a result of the AI software needing time to re-scan the network/routes.
 
They should make them where they automatically save in the Route Layer and not the Session Layer. I want to be able to program them once and then have them do what they're supposed to do for every session.

And what if you need to have the signals set differently in different sessions? Ever since Sessions appeared in Trainz (TS2004 or 2006??) the session is where all asset variable properties (industry and consist loadings, switch states, weather conditions, time of day, IT settings, etc, etc) have been stored. Why change this just for signals?

Sorry, but my vote is to keep all programmable settings in the session, not the route.

Old Curmudgeon.:n:
 
And what if you need to have the signals set differently in different sessions? Ever since Sessions appeared in Trainz (TS2004 or 2006??) the session is where all asset variable properties (industry and consist loadings, switch states, weather conditions, time of day, IT settings, etc, etc) have been stored. Why change this just for signals?

Sorry, but my vote is to keep all programmable settings in the session, not the route.

Old Curmudgeon.:n:

Absolutely, but the problem is there's a bit of inconsistency here between versions. What worked before by configuring things in the route, now requires that this be done in the session. With this change, many, many routes are broken and require revisiting all the signals and other things requiring configuration all over again. This has occurred time and time again between Trainz versions and even between service packs.

We also have an interface issue which really, really needs to be addressed with both the route building and session editing working exactly the same. Session editing, while it could be in a similar interface, should disable certain aspects that are only available in the route-editor such as adjusting track, placing track-objects, and other things that should only be done in the route. These changes would definitely help the disparity we have between routes, sessions, route-layers, and session-layers.

Over the past several years since layers were introduced, we have spent countless hours sorting out and resolving layer-related and session versus route problems. It's about time that this issue is addressed.
 
We also have an interface issue which really, really needs to be addressed with both the route building and session editing working exactly the same. Session editing, while it could be in a similar interface, should disable certain aspects that are only available in the route-editor such as adjusting track, placing track-objects, and other things that should only be done in the route. These changes would definitely help the disparity we have between routes, sessions, route-layers, and session-layers.

Over the past several years since layers were introduced, we have spent countless hours sorting out and resolving layer-related and session versus route problems. It's about time that this issue is addressed.

Good points but we must be careful not to make things more difficult while attempting to eliminate the current confusion. The often requested but simple (to my mind) step of naming the active layer in the menu bar would solve some of these issues. The Layers Tool flyout does have a button that will lock all route layers and more use should be made of this - perhaps it should be locked by default when you load a session into Surveyor and that will still leave you with the ability to unlock it if needed.

I can see many complaints coming if you can only edit the route layers if you load a route without loading one of its sessions.
 
Good points but we must be careful not to make things more difficult while attempting to eliminate the current confusion. The often requested but simple (to my mind) step of naming the active layer in the menu bar would solve some of these issues. The Layers Tool flyout does have a button that will lock all route layers and more use should be made of this - perhaps it should be locked by default when you load a session into Surveyor and that will still leave you with the ability to unlock it if needed.

I can see many complaints coming if you can only edit the route layers if you load a route without loading one of its sessions.

Good point made as well. I can see if things are unavailable, that might get people into a snit. If I recall, meaning digging out the dust bunnies and pulling cobwebs from neurons, layers in TS12 even where the route layer was locked while in the session editor.

We do need some kind of indicator. I'm testing a route for a fellow Trainzer and the session and route layers are messy and causing all kinds of issues like missing junction levers, track bits, etc. I've spent a couple of days untangling the mess. He had the right idea setting up various layers for things, but for some reason these categories ended up in the session portion. I found out, just recently, by the way, that these sub-layers can be dragged between session and route and rearranged too. This helped move a gazillion items from the session to the route and now it's all about picking up the stragglers.

If there was a big red or green button at the top saying ROUTE LAYER or SESSION LAYER (yes in caps), this would go a long way to where it should be, and situations like the one I mentioned wouldn't have, or shouldn't have occurred.
 
I've spent a couple of days untangling the mess. He had the right idea setting up various layers for things, but for some reason these categories ended up in the session portion. I found out, just recently, by the way, that these sub-layers can be dragged between session and route and rearranged too. This helped move a gazillion items from the session to the route and now it's all about picking up the stragglers.

There is also the ability to merge one layer into another. I play with one session per route. I put everything into the Route Layers. I Select Route; Select Session; Edit Session. This starts me off in the Session Layer. The First thing I do is Make the Route Layer the default. If I forget, frequently, as soon as I remember I merge the Session Layer into the Route Layer.

If there was a big red or green button at the top saying ROUTE LAYER or SESSION LAYER (yes in caps), this would go a long way to where it should be, and situations like the one I mentioned wouldn't have, or shouldn't have occurred.

There have been many, many threads where users expressed the need for something like this on the menu bar:
Clinchfield, Route, Buildings Layer (Locked)
-or-
Tampa Port, Session, Trees Layer (UnLocked)

Instead, N3V used valuable, and apparently scarce, programming time to give us animated engineer faces and eliminate single-click icons for QuickDrive and Search Filter. I have never seen a post where a user thought we needed animated driver faces.
 
Sounds like the temporary reds I get. N3V said, after a bug report, that the red signals are a result of the AI software needing time to re-scan the network/routes.


Since everything I do is in AI, I've seen trains sit at red signals for several minutes even though there is no apparent train coming in the opposite direction. However, running the exact same scenario over and pressing the Shift Key the time until green is greatly reduced. This makes me question N3V's rationale of needing time to rescan. It's more indicative of the AI waiting for some far distant actions to resolve.
 
Since everything I do is in AI, I've seen trains sit at red signals for several minutes even though there is no apparent train coming in the opposite direction. However, running the exact same scenario over and pressing the Shift Key the time until green is greatly reduced. This makes me question N3V's rationale of needing time to rescan. It's more indicative of the AI waiting for some far distant actions to resolve.

There's a stuck thread issue where the AI will stop driving after sometime as well as the signals remaining red even though hovering over the signal shows no train approaching, or some other condition such as a direction marker facing the wrong way. Pressing pause and resuming "resets" the system, and the AI carry on, however, as you know there are some implications in this.

As time goes on, the process gets steadily worse and eventually everything grinds to a halt. In my case, this occurred after about one hour, maybe a bit less depending upon the number of drivers, signals, and complexity of the route. Saving the session periodically while driving, and then restoring the session helps to a point after quitting completely. The AI will come back to life and the signals may or may not, meaning the AI will be careening around the route, ignoring signals, track marks, and speed limits, while the signals remain red or sometimes display nothing. Then suddenly, everything is back to normal, but by this time it's time to save and start that awful routine again of saving, exiting, and starting up again.

I reported this to the QA Team, and it was confirmed as a bug. When this gets fixed? Who knows!
 
Back
Top