[Genma Saotome]

Csantucci, on 01 February 2014 - 01:41 AM, said:

I like the idea of Robert, however I ask for an addition, that is that - in addition to the ENVFILES folder of every route - there is also at the general OR level an ENVFILES folder.

From an Architectural perspective it would be good if the OR Team would simply build in the means to handle an ever finer specification of lots of things*, not just the .env files... meaning global as default but allowing for a route level over-ride which in turn allows for an activity based override. The alternative -- one could simply require everything to be in the activity -- would mean a whole lot of repetitive specifications. Having an app that aids the Activity Design to copy from would help... but then simply considering each subsequent level as purely optional might do just as well.

*A different example is car weight. Let the empty weight be required in the the .wag (or equivalent) and making lading and lading weight in the .wag a default with values optional replaced in the Activity file. One outcome: No more need for one .wag for empty cars and n .wags for various loads; A different outcome: the loaded coal hopper gets all it's data values defined just once.

[rdamurphy]

Dave, NOTHING is ever final... It's a very good starting point, and people are familiar with it. Yes, eventually, it would make a lot of sense to improve on it, and there's a lot of things that can be cleaned up and fixed. For instance some of the strange quirks in the MSTS files, including a lot of settings that they never quite actually connected to anything.

For example, if you look in the default .wag files you'll find: [code] comment( 29.971t empty, 98.163t full ) [code]

Was that a set of values that they commented out because they didn't use them? I can't think of any other reason to add them. Was that supposed to be an option in the .con files to configure the car as empty or loaded? Easy enough for us to do...

OR how about [code] NumberOfHandbrakeLeverSteps( 100 ) [code]

My reaction to that was "huh?".

Not to be critical of the Kuju team, after all, they were in it to make money, and MSTS wanted it out the door, so I'm sure there's a lot of things they wanted to do but never got a chance to. Which is why George was able to enable so many things in .bin, he didn't add any new code, he couldn't, only enable things that were already in there but never "turned on."

And they didn't have the advantage of a few dozen testers who were willing to look at each and every build and offer constructive criticism and suggestions, like we do. Big advantage for us!

Robert

[rdamurphy]

I committed a very experimental option today to use MSTS Environments. Not really stable yet, but it works. Biggest issue so far is the transition between day sky and night sky. For some really odd reason, MSTS didn't tile the day sky, but did tile the night sky... Still working out how to make that work transition. I'm assuming that's what MSTS used the lowsky texture for, seems to make sense.

Robert

[DRelyea]

Hi,

MSTS will tile the day sky, it depends on what the environment (env) file is set up for.

The Skylow was used as an assist in creating the "fog" that blended the sky texture into the horizon fog.

The US1Skylow is actually a tga based file, which permits occasional views of the clouds on the upper "sky" layer.

MSTS has the capability of multiple sky levels, which will render as long as the lower sky textures are tga with transparent areas.

I've had as many as 4 sky levels, with a bmp based blue as the uppermost. It would be cool to retain the ability to add multiple sky levels.

Doug Relyea

[rdamurphy]

Walter Conklin, on 01 February 2014 - 04:44 PM, said:

Hello Robert,

Thank you for giving OR the ability to use environments created for MSTS.

Just curious - How does OR know which environment to use?

I don't know. Yet. Still working on that.

DRelyea said:

MSTS has the capability of multiple sky levels, which will render as long as the lower sky textures are tga with transparent areas.

I've had as many as 4 sky levels, with a bmp based blue as the uppermost. It would be cool to retain the ability to add multiple sky levels.

Doug Relyea

Multiple sky layers would be easy to do, since I reused the water parser for the file reader, how do I know how they're set up that way in the .env file? Do you have any examples?

Robert

[steamer_ctn]

Hi Robert,

I have just updated to 1986 in my development environment, and when I try to rebuild the program, I get the following error messages:

\openrails\Source\Menu\MSTS\ENVFile.cs' could not be opened ('Unspecified error ')
\openrails\Source\RunActivity\Viewer3D\MSTSSky.cs' could not be opened ('Unspecified error ')
\openrails\Source\RunActivity\MSTS\ENVFile.cs' could not be opened ('Unspecified error ')

I have had a look in the repository and can't see them there. Are these files associated with your work, and should they be in the repository?

Thanks

Peter.

[James Ross]

Yeah, I do believe these files are missing. My automatic builds have reported the same errors:

CSC : error CS2001: Source file 'MSTS\ENVFile.cs' could not be found
CSC : error CS2001: Source file 'Viewer3D\MSTSSky.cs' could not be found

[James Ross]

rdamurphy, on 01 February 2014 - 07:07 PM, said:

I don't know. Yet. Still working on that.

The TRK file specifies an 'Environment' section which lists the 12 combinations of season + weather and which ENV file to read. I am pretty sure that's all set up and working in OR though, as there are some routes which have incorrect filenames in some entries. :pleasantry:

[Csantucci]

Hi Robert,
only to say that George added new binary code to MSTS and modified the existing code. Remember e.g. what he did to enable rear cabs. He first choose one solution, then another solution for implementation of them in the .cvf file. So these were his choices, and not something he already found in MSTS.

[Csantucci]

Just tried the option with the Bernina route. Distant mountains are cut down at the height of the observer, see picture