[C490]

James Ross, on 28 August 2018 - 09:11 AM, said:

I've looked at the code and it looks like the following .env file options are supported when you select "MSTS environments" in the Experimental Options:

• World water layers (height and 1st texture only)
  
• World sky layers (texture and uvtiles only)
  
• World sky satellites (1st and 2nd texture as sun and moon, respectively, only)

I've not checked, but that probably leaves loads of .env file features out, unfortunately. One of the problems is that for much of OR's development, we've built our own environment and this was added on later.

Thanks James for your explanation.
But if so , can we have the "date of the year" as an initial variable instead of the fixed date being hard coded for each season.
I believe then program can calculate the correct sun position.

Thank you

[James Ross]

C490, on 24 September 2018 - 05:15 AM, said:

Thanks James for your explanation.
But if so , can we have the "date of the year" as an initial variable instead of the fixed date being hard coded for each season.
I believe then program can calculate the correct sun position.

There's no dates in the .env files, are there? They do have the sun rise and set times, though, which we could use: the satellite with world_sky_satellite_light ( 1 ) is the sun, and it has world_sky_satellite_rise_time and world_sky_satellite_set_time.

[Genma Saotome]

In the ideal any date that is used to determine the sun's location relative to the earth's annual journey should be a new parameter brought in with each activity.

[C490]

Genma Saotome, on 26 September 2018 - 02:51 PM, said:

In the ideal any date that is used to determine the sun's location relative to the earth's annual journey should be a new parameter brought in with each activity.

It depends on how sophisticated the current sun position calculation.
(For example my case i have gps coordinate difference between msts and orts. Not big but it is there)

As i see right now date it is derived from season setting (getting day of the year then convert into month, then sets 21th day of that month)
I know there is no date only season setting in the activity file (i guess that is why the decision was like this at that time)

mstsskyseasonType = (int)MSTSSkyViewer.Simulator.Season;
date.ordinalDate = mstsskylatitude >= 0 ? 82 + mstsskyseasonType * 91 : (82 + (mstsskyseasonType + 2) * 91) % 365;
// TODO: Set the following three externally from ORTS route files (future)
date.month = 1 + date.ordinalDate / 30;
date.day = 21;
date.year = 2017;

So my recommendation:
- get the date of windows date
- set it somewhere in the program UI
- set the parameter somewhere else (activity file, route file)

Once we sorted the sun's position. As second step we need to move forward the sky and environment&ambient coloring at sunset/sunrise that was also env file feature in msts (maybe it is shader or program issue)

[C490]

James Ross, on 26 September 2018 - 12:27 PM, said:

There's no dates in the .env files, are there? They do have the sun rise and set times, though, which we could use: the satellite with world_sky_satellite_light ( 1 ) is the sun, and it has world_sky_satellite_rise_time and world_sky_satellite_set_time.

For me it like downgrading the sun position calculation (if it's really sophisticated , but limited to fixed date)
I think we need to focus on "how to get date" instead of implement alternative calculations. We should aim to be better than msts not going back to Msts.
Also i do not want to see duplicate alternative coding, but improvement the current code instead.

So current big issue is with openrails environment:

- Fixed date sun position calculation (still do not know how good and "sophisticated" is because it is fixed), previously managed by env file in msts
- Sun position has no effect on ambient light coloring (only shadow position), no idea if it's shader issue or else. Previously it was also env.file feature

During msts times i shared "daily.env" file with my community. Correct sunrise/sunset and weather (sky texture) according to daily forecast and proper ambient coloring (dark night, blue/orange hour).
I'd like to see at least that ,preferably better control in Openrails.

[James Ross]

C490, on 27 September 2018 - 02:24 AM, said:

- Fixed date sun position calculation (still do not know how good and "sophisticated" is because it is fixed), previously managed by env file in msts

The .env files set a sun rise and set time, which I am saying we could implement in Open Rails as well.

C490, on 27 September 2018 - 02:24 AM, said:

- Sun position has no effect on ambient light coloring (only shadow position), no idea if it's shader issue or else. Previously it was also env.file feature

We could also read these values from the .env files (e.g. "world_sky_satellite_dir_rise_colour").

C490, on 27 September 2018 - 02:24 AM, said:

During msts times i shared "daily.env" file with my community. Correct sunrise/sunset and weather (sky texture) according to daily forecast and proper ambient coloring (dark night, blue/orange hour).

I'd like to see at least that ,preferably better control in Openrails.

I am confused about this. You seem to be saying you want at least what MSTS can do in .env files, but you don't want Open Rails to use the .env files for it? I think you're going to have to be more precise about what you want, as I am not understanding you right now.

[C490]

James Ross, on 30 September 2018 - 05:29 AM, said:

The .env files set a sun rise and set time, which I am saying we could implement in Open Rails as well.


We could also read these values from the .env files (e.g. "world_sky_satellite_dir_rise_colour").


I am confused about this. You seem to be saying you want at least what MSTS can do in .env files, but you don't want Open Rails to use the .env files for it? I think you're going to have to be more precise about what you want, as I am not understanding you right now.

Hi James

Sorry i am not being programmer by myself, just "power user". I'd be happy to see an improvement regardless the way :)
For coding perspective i am not sure which one is easier or more futureproof. Provide legacy support for env. files or improve the current code.
I am very familiar with .env files so if we can get those values read by orts sounds good to me :)
But for end user perspective fiddling with "color codes" and env file parameters, i am not sure about :)

So as a summary :)
- I'd like to control sunrise/sunset (does not matter if it's env file ,or code, or derived from some date)
- Better sky coloring during sunrise/sunset (does not matter if it's env file ,or code, or coming from shaders)
- Better environment/ambient coloring during sunrise/sunset (does not matter if it's env file , or coming from shaders)

What do you think ? I think those things are a way behind the msts.

Cheers

[C490]

Hi James

Is there any progress considering environments improvements ? Sunrise / sunset especially.

[SP 0-6-0]

I am wondering the same thing???

I'd also like to have moving skies like MSTS had and the ability to use the Kosmos Environments in ORTS.

Robert

[dforrest]

SP 0-6-0, on 08 February 2019 - 11:21 PM, said:

I am wondering the same thing???

I'd also like to have moving skies like MSTS had and the ability to use the Kosmos Environments in ORTS.

Robert

This sort of comment confuses me. Surely is you set an environment file (.env file) from Kosmos as the environment to be used for a particular "season" in your route .trk file and them run Open Rails with the "MSTS Environments" option chosen, theis will be used. Am I wrong?