[railguy]

OpenRails has never been particularly accurate in reflecting dusk and dawn times in routes, but I have noticed some significant differences of late--MG version R147 being the latest example. On several routes, it seems that dusk comes 1-2 hours later in the same activity than it did in some earlier MG versions and dawn also comes much earlier in the same activity. As an example, I run one activity that starts at 10 PM on Surfliner 2.3. I have never modified that start time in the activity. When I last ran it some months ago, the activity would start in near complete nighttime darkness. When I run it now in R147, the sun has barely set. If one assumes that OR is "clocked" in "local" standard time, then the former 10 PM darkness would be prototypical. I wonder if the latest MG revisions are reading the longitude and latitude of routes correctly when calculating dusk and dawn time. Any thoughts appreciated.

[charland]

That's interesting, I'll have to check that. I've been complaining about this for years. I built a route for here in Brockville Ontario where the CP comes down and switches local industries in the evening. In real life, during the summer months they arrived in daylight and the sun was going down around the time the departed around 9 PM. In earlier OR and ORNYMG versions it was dark by 7:30... in the middle of the summer? I provided photos taken at 8:20 in the evening and OR screenshots taken at the same time that was just black with stars. I set aside the route, maybe I need to take another look at it.

Paul :-)

[railguy]

My suspicion is an incorrect calculation in sunrise/sunset times in latitude and/or longitude in MG. Of course, latitude affects the sunrise/sunset time, as one moves away from the equator. As one moves away from the equator, daylight hours increase more quickly after the Winter Solstice and decrease more quickly after the Summer Solstice. So, for example, the number of daylight hours in summer will be significantly more in Fargo, ND compared to Dallas/Fort Worth, TX, which are at approximately the same longitude and are in the same Time Zone. Longitude's relation to Time Zone is a bit trickier, since it affects sunrise/sunset times, depending on where one is located in a particular time zone. This can create some interesting anomalies if one lives near or at the edge of a Time Zone. Pierre/Ft. Pierre, South Dakota (for those unfamiliar with South Dakota, it is pronounced "Peer" there, by the way) is a great example. The Missouri River divides Ft. Pierre from Pierre, and is also the dividing line between the Mountain Time Zone and the Central Time Zone. So, in the space of less than a mile, clock sunrise or sunset time will be one hour different. Sunset at 8 PM in Ft. Pierre will be at 9 PM in Pierre. My surmise is that OR computes sunrise/sunset time based on middle of a season, middle of a Time Zone, and approximate latitude of the route. There is also the issue of Daylight Savings Time. OR does use(and should use) Standard Time, as Daylight Savings Time is not universal, even within the U.S. Arizona, for example, does not use Daylight Savings Time at all. So, on a route such as Seligman, which runs in California (briefly) on Pacific Time and Arizona on Mountain Time, clock time on the route would be the same in California and Arizona during Daylight Savings time, with California being one hour earlier than Arizona on Standard Time. As noted in another post that I've seen, the OR sunrise/sunset calculation algorithm really does need a review and modification.

[James Ross]

railguy, on 17 November 2023 - 05:07 PM, said:

OpenRails has never been particularly accurate in reflecting dusk and dawn times in routes, but I have noticed some significant differences of late--MG version R147 being the latest example.

I can't speak about the MG version, but for the official Open Rails versions there are two different sunrise/sunset calculations depending on which version you have:

• Versions before 2023-04-01 use the latitude/longitude and season to calculate an approximate sunrise/sunset times
  
• Versions after 2023-04-01 use the sunrise/sunset times specified in the season- and weather-specific "ENV" (environment) files (if the data/files do not exist it uses the previous method)

[Csantucci]

ORNYMG does the same.

[Genma Saotome]

James Ross, on 21 November 2023 - 03:47 PM, said:

• Versions before 2023-04-01 use the latitude/longitude and season to calculate an approximate sunrise/sunset times
  
• Versions after 2023-04-01 use the sunrise/sunset times specified in the season- and weather-specific "ENV" (environment) files (if the data/files do not exist it uses the previous method)

.env files? I guess I must have missed that. I checked the index of the OR Manual I have, dated 20Dec22, and the .env files are not included in the index, probably meaning they are not anywhere. Whatever portion of the .env files that are used by OR should be in an appendix of the manual.

Curious, in the manual I also looked up the string ESD; There is an entry in the index but little is explained. With that in mind I did a grep in the .sd files for a couple of routes and found these ESD commands in the payware WP 3rd sub route:

Quote

ESD_Alternative_Texture ( n )

ESD_Detail_Level ( n )

ESD_No_Visual_Obstruction ()

ESD_Bounding_Box ( -1.51 0.5 -0.4468 1.51 4.52 145.633 )

ESD_SubObj ( )

ESD_Complex ( 1

ESD_Complex_Box (

0.0 0.0 0.0
0.00572002 1.76021 1.90735e-006
-2.36928 -1.75571 -25.0
2.36928 1.75571 25.0

)

)

ESD_Tunnel ( 25 8 6 10 10 )

I know the value range of ESD_Detail_Level() and some of the codes for ESD_Alternative_Texture but the rest are a mystery to me. I'll guess they are a mystery to most everybody and that some (all?) are not implemented in OR.

FWIW I know there was something that prevented smoke from passing thru another object, such as a bridge above the rails. No idea if that is in the above list or not.

Maybe time for a "Crowd Answering" campaign? Some of them might get a definition.

[Weter]

Quote

something that prevented smoke from passing thru another object, such as a bridge above the rails

Re-inttroduction of this in ORTS would be very desirable.

[James Ross]

Genma Saotome, on 22 November 2023 - 02:52 PM, said:

.env files? I guess I must have missed that. I checked the index of the OR Manual I have, dated 20Dec22, and the .env files are not included in the index, probably meaning they are not anywhere. Whatever portion of the .env files that are used by OR should be in an appendix of the manual.

I can't find any other file usage documented in the manual, except for signal functions (which are a bit special). Can you point me at where other file usage is documented in the manual, and I'll add the ENV bits.

Genma Saotome, on 22 November 2023 - 02:52 PM, said:

Maybe time for a "Crowd Answering" campaign? Some of them might get a definition.

Sure. It would be useful to gather all the file format documentation in one place, too. I believe we have a bunch in code comments (in Source/Orts.Formats.Msts), probably scattered around in the manual, and likely elsewhere too.

[Genma Saotome]

James Ross, on 22 November 2023 - 05:39 PM, said:

I can't find any other file usage documented in the manual, except for signal functions (which are a bit special). Can you point me at where other file usage is documented in the manual, and I'll add the ENV bits.

The only thing i found was this:

ESD_Alternative_Texture, 322
ESD_ORTSBellAnimationFPS, 186
ESD_ORTSSoundFileName, 338

James Ross, on 22 November 2023 - 05:39 PM, said:

It would be useful to gather all the file format documentation in one place, too. I believe we have a bunch in code comments (in Source/Orts.Formats.Msts), probably scattered around in the manual, and likely elsewhere too.

I did find a model using the ESD Complex Box / ESD bounding box references. Here is a picture: taken in shapeviewer:

I suppose the idea was to let the camera pass thru the area above the shorter box. IIRC OR doesn't bother with camera collisions. Dunno that we really lost anything... but then I build, not run.

[Laci1959]

Hello.

ESD_Bounding_Box ( -X -Y -Z X Y Z ) was primarily needed to connect vehicles to each other in MSTS. Secondly, for the connection between vehicles and the environment. A typical example is that if the size of the opening was specified in the tunnel entrance, it was taken into account. If the size of the opening was smaller than the size of the vehicle, it did not fit.
I like that the smoke from the trains passing under the bridges avoids the bridge.
It doesn't really belong here, but the TunnelShape ( ) entry in the TSection.dat file served a similar purpose. Sometimes it really bothers me when it snows in a hall like it does outside. Even though I made special elements to which I added the TunnelShape ( ) line, it didn't work. Then I gave up.

Sincerely, Laci1959