environment settings saved in session succesfully, but disappear when exporting to .cdp

[este21]

When I make changes to a session's Environment Settings (in TRS19 SP3 for Mac - build 111956), they are saved perfectly fine. They are exactly as I set them when opened in Driver, and stay that way through many instances of making any other changes to the session.

However, when I export the session to .cdp and load that into another instance of Trainz (be it another data folder of TRS19 SP3, TRS19 SP5 or TRS22 SP2), the environment settings are lost. The other instances of Trainz load a different sky, completely different light/colours, etc..

Looking at the session's Config file, indeed I don't spot any reference to environment settings. Not even to the sky file is listed as a dependancy. Surely at least that should be listed in the config?

(To be clear: otherwise the session works fine in those other instances of Trainz. It's only the environment settings that get lost.)

Any ideas what I might be doing wrong?

TIA

 

[pware]

It could be that you are not considering the order of priority that applies to the Environment settings.

With the exception of the Word Origin settings, each setting can be applied to the Route, to the Session or to both. World Origin settings are only applied to the Route. All other settings are saved with the Route, or the Session or to both.

The order of priority is Session Environmental settings first, Route Environmental settings second, then the "default" Environmental settings third.

So, for example, you set a particular sky settings in the Route only. It will be saved in the Route but not in the Session. All Sessions that use that Route will inherit that sky settings from the Route.

If you save a particular sky settings in a specific Session and a different sky in the Route then only that Session will see that particular sky. All other Sessions based on that Route will see the sky saved with the Route.

If you do not set and save a particular sky at all then the Route and all its Sessions will see the "default" sky.

So I would suspect that your settings have been saved in the Route and not in the Session so they are not being transferred in the .cdp file.

A better example of this is the date setting which sets the season of the year. By setting the date in the Route only, all sessions will inherit that date and season If you set a different date in one specific Session then that date and season will be used by that Session only and all other Sessions will use the date and season saved in the Route. If you do not save a date at all (not in the Route and not in the Session) then all Sessions will use the "default" which is today's date and the current season.

See the Trainz Wiki Page at How_to_Use_Environment_Tools#Location for a (possibly) more coherent explanation.

 

[este21]

Thanks. I know. I'm not saving the route. The route is not mine. I'm 'just' building a session for it. I would be very aware if I'd be accidentally creating my own copy of the route by saving the environment settings there.

Every time I drive or edit the session in my 'development install', it shows the correct environment settings. Given that they are not store as part of the route, that means they must be stored as part of the session, right? However, when exporting that session to .cdp and then importing that into another instance of Trainz, the environment settings are not there.

Upon looking into this, I was then further surprised to find that the .cdp doesn't even contain a reference to the kuid of the sky that I have defined. Yet my development install in fact does always show that sky. Surely the only possible explanation is that Trainz stored that information somewhere that is neither the route nor the session file…?

Where? Why? How make it not to? (I mean, I found a workaround in just adding a reference to the sky's kuid to the session's config file. But as long as I don't know what the original problem is, I cannot entirely trust the workaround…)

 

[G.M.]

Hi Este, it could be the Sky is stored in the route (that you do not save or alter)
and other environment things are stored in session.

So maybe check if your development route and the one you test in have the same Sky (kuid)
good luck solving this puzzle

 

[este21]

The route is not a variable here. It is the one constant. The route is by someone else. It lists its own specific sky kuid as a dependency.I installed that exact same route in several installs of Trainz.

In one of those installs, my "development install", I create my session, including environment settings, which includes a completely different sky then the route's. From then on, my development install correctly shows 'my' sky. But when exporting my session to .cdp and importing that into the other installs, they do not. (Which makes sense, given that the .cdp doesn't even list my sky's kuid.)

But when, in my dev install, I add my sky's kuid to the kuid table of my session's config file, and then export to .cdp, the other installs do list it as a dependency, and in fact correctly render it when opening the session, both in Driver and Surveyor.

 

[MasterTracklayer]

You have me wondering something. Is it possible that your sky settings are in neither the Route nor the Session, but have been set (possibly by accident) as the default sky on your development system only? If so, finding another route and session that does not specify the sky in either place would show your custom sky on your development system but not on your play system. Any chance you could check for this?

 

[pware]

The environmental settings are not saved in a configuration.txt file but in one of the mysterious and non readable data files that populate the Route and Session

 

[este21]

You have me wondering something. Is it possible that your sky settings are in neither the Route nor the Session, but have been set (possibly by accident) as the default sky on your development system only? If so, finding another route and session that does not specify the sky in either place would show your custom sky on your development system but not on your play system. Any chance you could check for this?

Good thought. I'm not aware of there being an explicit method to set a default sky per Trainz data folder though. Maybe I overlooked something? FWIW, when I create a new route on my dev install, it is set to use "No Cloud 01", which is not the sky I'm referring to in this thread. Is "No Cloud 01" the sky that Trainz is supposed to use by default?

As per your suggestion, I've looked at a dozen or so routes and sessions. Mainly ones that were distributed by N3VGames themselves, on the assumption that those would be the most reliable ones. I also looked at a few third party ones, and a few of my own simple test routes and sessions for which I never bothered to define a sky. Out of all of those, some are set to"No Cloud 01". Most routes have defined a different sky, and yet another one in their sessions. None of them show 'my' sky. So I would think this makes it reasonably unlikely that I have accidentally, somehow, changed my dev install's default sky.

 

[este21]

The environmental settings are not saved in a configuration.txt file but in one of the mysterious and non readable data files that populate the Route and Session

Yes, it would seem so. None of N3VGames' own routes and sessions that I've looked at show any reference to a sky in their config files. And when I have Content Manager list their dependencies, the sky that is configured in that route or session is not listed as a dependency. Which then begs the question how Trainz can possibly know which sky it needs to fetch from the DLS…

Might it actually be that Trainz' mechanism for showing correct skies relies entirely on the assumption that the sky asset is already installed? If that is the actual underlying issue, it would explain why adding a sky's kuid to a config file's kuid table actually solves the problem. It would also make me confident that this workaround is reliable.


Btw, by now I think that probably my question is only about the sky file; that the other environment settings always were in fact saved and exported correctly. I probably got confused initially, because seeing a wrong enough sky can easily affect the overall 'look'; gives the impresssion that all colours are wrong, even when they aren't. Now that I managed to force different installs to show the correct sky, they all appear to also show all my other environment settings correctly. So let's assume all this is only about the sky file.

 

[MasterTracklayer]

So I would think this makes it reasonably unlikely that I have accidentally, somehow, changed my dev install's default sky.

I would tend to agree. At least it was worth eliminating as a possibility.

So let's assume all this is only about the sky file.

Makes sense. At this point, my "expertise" is failing to come up with an alternate test, so I`ll bow out until & unless something else comes to me. Good luck.