[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

[markus_GE]

Robert,

the lines "comment( xx t empty, xx t full)" to me seem to just be regular comments. AFAIK, there are also some other parameters in the default .eng files that don´t actually change anything in the locos in-game behavior, so I suppose if these lines were there to indicate different masses, they would have a proper name and be just ignored by MSTS, as other lines in .eng files are.

Cheers, Markus

[conductorchris]

I would love to see nice environmental files integrated into openrails in the way this discussion has suggested. Neither batch files nor the separate steps of kosmos are userfriendly. It should be an option on par with seasons or it should be automatic, loading route environmental files without the user even needing to set an option unless they want. I think the effects of better environment files would be worth the program weight. In my opinion a larger program is not a problem, the issue is the weight of what it actually has to load in terms of it's impact on frame rates and memory usage.
Christopher

[BB25187]

Hi all,

Well, if the v1.0 aims at providing a compatibility with MSTS content, it should probably support the environmental files as MSTS did. The question to have Kosmos features implemented inside or outside OR is a "detail" (from the user POV, for sure not for the developers!), just because Kosmos is nothing but an "assembler" of elementary parts of environmental files + a user interface to control which of those parts must be used used at load time.
As for the next versions (higher than 1.0), the question seems pretty opened. None of the modern simulators I know do make use of a static environment files. They usually use a panel to set weather conditions before starting or during the game (types and height of clouds, type and strength of the précipitations, direction and speed of the wind, fog density, ... ) and many other parameters. Most of them can also connect to the internet to retrieve the actual weather at a given location all over the world and reproduce the same conditions ingame. Most of them can update those conditions dynamically during the game, either manually or automatically. So, for future versions, the environment files seem to be a pretty out dated paradigm!

Regards

[rdamurphy]

Very basic "support" of environmental files is now available, right now, only day, night, and moon textures work, it's very much a work in progress. I'm modifying the current sky code (duplicated into a new class) and still trying to get a grip on both the code and the .env files. But, yes, you do get the sky textures right now.

Robert

[rdamurphy]

Check out what I found:

Position of the Sun at 11:00 UT on 1997 August 7th

1. Find the days before J2000.0 (d) from the table

   d = 11/24 + 212 + 7 - 1096.5 = -877.04167

2. Find the Mean Longitude (L) of the Sun

   L = 280.461 + 0.9856474 * d
     = -583.99284 + 720  
    (add multiples of 360 to bring in range 0 to 360)
     = 136.00716

3. Find the Mean anomaly (g) of the Sun

   g = 357.528 + 0.9856003 * d
     = -506.88453 + 720
     = 213.11547

4. Find the ecliptic longitude (lambda) of the sun

   lambda = L + 1.915 * sin(g) + 0.020 * sin(2*g)
          = 134.97925

   (note that the sin(g) and sin(2*g) terms constitute an 
    approximation to the 'equation of centre' for the orbit 
    of the Sun)

   beta = 0 (by definition as the Sun's orbit defines the
             ecliptic plane. This results in a simplification
             of the formulas below)

5. Find the obliquity of the ecliptic plane (epsilon)

   epsilon = 23.439 - 0.0000004 * d
           = 23.439351

6. Find the Right Ascension (alpha) and Declination (delta) of
   the Sun

   Y = cos(epsilon) * sin(lambda)
   X = cos(lambda)

   a = arctan(Y/X)

   If X < 0 then alpha = a + 180
   If Y < 0 and X > 0 then alpha = a + 360
   else alpha = a

   Y =  0.6489924
   X = -0.7068507

   a = -42.556485
   alpha = -42.556485 + 180 = 137.44352 (degrees)
   
   delta = arcsin(sin(epsilon)*sin(lambda))
         = 16.342193 degrees

Final result

   Right ascension is usually given in hours of time, and both
   figures need to be rounded to a sensible number of decimal
   places. 


   alpha =   9.163 hrs      or   9h 09m 46s
   delta = +16.34 degrees   or +16d 20' 32"

   The Interactive Computer Ephemeris gives

   alpha =   9h 09m 45.347s and
   delta = +16d 20' 30.89"  

Even comes with Source Code! In QBasic...

Robert