[James Ross]

So I'm not sure if this is a known weirdness of MSTS, or if I've found something unexpected, but while testing some other changes with MSTS and OR side-by-side I noticed something odd:

I need to go about 1.2 to 1.3 times faster in OR than MSTS to keep them level according to the scenery. But, at any given point, both MSTS and OR show the same distance to e.g. the next station or signal.

I then created a test track, just a 2km straight with markers at 0.9km and 1.9km and timed things.

• MSTS took 168 seconds to travel 1000 meters at (displayed) 17 km/h. 1000/168 = 5.95 m/s which is 21.42 km/h, a difference of 1.26 from expected.
  
• OR took 136 seconds to travel 1000 meters at (displayed) 26-27 km/h (it varied a bit). 1000/136 = 7.35 m/s which is 26.46 km/h, no difference from expected.

Anyone seen this before? Is it a known issue in MSTS? This is with MSTS patch 1.4, no MSTSBin.

[Csantucci]

Yes, this is known.

[copperpen]

It is one of the reasons that MSTS activities run differently in OR.

[Genma Saotome]

It's a consequence of the Goode-Homosoline projection (uses a parallelogram, parallel top and bottom). IIRC in the new world distance measured on a NE-SW axis are compressed when skewed into a square tile and stretched when measured on a NW-SE angle. In the old world it is the opposite because the G-H parallelogram is opposite.

The G-H corners each have a unique longitude; I don't know what KUJU did with that when the skewed the GIS data in to a square but IIRC that was how somebody figured out something was very fishy about time and distance.

[vince]

There was also a problem calculating distance that was uncovered when the MSTS Bin patch was used.
The HUD display has a field for measuring distance I called the Bin-O-Meter that seemed to depend on the TimeStep parameter
This is in the default.wag file:

"0			# On-track solver: 0=euler 1=rungekutta"
 		"1ms		# On-track solver timestep"
 		"0			# Off-track solver"
 		"10ms 	# Off-track timestep"
 		"0			# Reposition colliding objects: 0=no 1=yes"

Basically what I measured using 100 meter track sections on a six mile straight run from Whitepot Junction on the LIRR MAIN in Rego Park down the hill and across the 5 mile long Jamaica Bay Trestle in Queens County New York was each Km recorded on the Bin-O-Meter in the MSTS Bin HUD worked out to about 780 meters.

My notes also say over a 12 kilometer run measured by a straight run of track the Bin-O-Meter showed 9.422km.
This was with the default 10ms timestep in default.wag. I had heard it was the Bin meter was closer to actual if the timestep was set to 1ms but I never tried it as it was pretty much moot due to the Goode-Homosoline distortion mentioned by Dave.
My notes have a date of 4 April 2007. I did write this up in the forums at that time. I'll see if I can find the posts.
Ah! I found the post
Here: >>>===> http://www.trainsim....goto=nextnewest

regards,
vince

What exactly that means in the present discussion is unclear to me but here I on;y offer some data that may have a bearing on the problem.

[James Ross]

 Genma Saotome, on 02 January 2016 - 10:54 AM, said:

It's a consequence of the Goode-Homosoline projection (uses a parallelogram, parallel top and bottom). IIRC in the new world distance measured on a NE-SW axis are compressed when skewed into a square tile and stretched when measured on a NW-SE angle. In the old world it is the opposite because the G-H parallelogram is opposite.

I know what the skewing and distortion caused by the G-H projection looks like, but this seems to be a simple scaling (either of speed or distance). I just ran a test Westbound (my earlier test was Northbound) and it took exactly the same time to travel the same distance at the same speed (168s for 1km at 17km/h). It is possible this scaling is a bug in MSTS or it could have been an attempt to rectify the G-H weirdness or maybe something else entirely.

 vince, on 02 January 2016 - 01:07 PM, said:

Here: >>>===> http://www.trainsim....goto=nextnewest

Cool, glad someone else found the same thing with data. I'm surprised I haven't come across this rather larger error before. :)

[Coolhand101]

 James Ross, on 03 January 2016 - 07:19 AM, said:

Cool, glad someone else found the same thing with data. I'm surprised I haven't come across this rather larger error before. :)

It was all down to computer specs when MSTS was first release. The 1ms time step, took quite a bit of processor power and the FPS, was almost unplayable on a very long freight train. This also caused a lot of broken couplers.

IIRC Running at 60 mph, i was timing 1600 meters in around 54 seconds at 10ms. At 1ms it was 60 seconds.

At 1ms, the MT Greater Eastern route length from london to Norwich, was exactly 115 miles as the real route.
At 1ms, the Dorset coast route from London to Weymouh was around 20 miles longer than the actual route of 143 miles. At 10ms, it was around the actual length of 143 miles.

Thanks

[James Ross]

 Coolhand101, on 03 January 2016 - 08:33 AM, said:

It was all down to computer specs when MSTS was first release. The 1ms time step, took quite a bit of processor power and the FPS, was almost unplayable on a very long freight train. This also caused a lot of broken couplers.

I totally understand the time step vs computer specs side, but I didn't see the mention of its effect on this MSTS bug - it was hiding on page 2 of the linked thread. :)

Anyway, this seems like an out-right physics bug in MSTS at this point so I'll just recommend people use 1ms if they're comparing anything with OR.