Tågets egentliga hastighet i MSTS samt bättre fps

[avslutat_konto]

Jag satt och skummade igenom det amerikanska forumet inatt, hittade då detta inlägg:
----------------------------------------------------------------------
It was discovered recently by several people that MSTS runs "fast", meaning that it takes less time to cover a given distance than it should based on the speedometer reading. This was initially discussed in this thread:

http://www.train-sim.com/dcforum/DCForumID6/4705.html

I personally discovered this problem about a month after I got MSTS(I purchased MSTS in June, 2001). While I was testing my fcalc friction modification prior to uploading it, I realized that the trains covered distances faster than they should. I used the distance to next signal in the track monitor for my testing, not the mile markers since these can be arbitrarily laid out. I didn't scientifically analyze the problem at the time since I was more interested in testing my friction modification.

After reading the latest discussions of the subject both here and at UK Train Sim I decided to take a closer look at it. I had recently modified the timestep in order to increase the frame rate. The timestep can be modified in the default.wag file which is found in the Train Simulator\Trainset\Default folder. There are two entries for the timestep. One is for the AI trains and is set to 30 ms(I left this one alone). The other is for the player's train and is set to 10 ms by default. The timestep is the period used by the sim for calculating how much the train moves. In this case, the sim will calculate the positions of each of the train cars at 10ms(or 0.01 sec) intervals. A higher value for the timestep means fewer calculations but less accuracy, while a lower value means more accurary at the expense of computation time. I originally changed the timestep to 15 ms in order to make long freight trains run smoother. I was unaware of any other effects of changing it.

By a stroke of luck I noticed that my normal runs on the NEC with passenger equipment seemed to be somewhat faster than before, but I didn't think to analyze anything until I read the latest thread on the subject. Here are the results of my detailed analysis(I used an HHP-8 with 8 Amfleet coaches for the tests):

The first figure is the timestep, the second figure is the measured speed at 60.0 mph indicated, and the third figure is the acceleration time(minutes:seconds) from a standing start to 125 mph at full throttle.

1.0 ms 60.7 mph 3:21
2.5 ms 61.8 mph 3:19
5.0 ms 64.0 mph 3:15
10 ms 68.0 mph 3:06
15 ms 76.0 mph 2:57
20 ms 73.0 mph 2:49
30 ms 75.8 mph 2:42

As you can see, the discrepancy between the indicated and measured speeds increases as the timestep grows larger. The acceleration times decrease as well, though not in the same proportion as the speed errors. Another interesting result was that for a given timestep, a longer train has less error(all measurements here were done with a 2.5 ms timestep):

60.4 mph (14-coach train)
61.8 mph (8-coach train)
63.5 mph (locomotive only)

The solution is therefore very simple-set the timestep as low as you can. At some point, the frame rates will be affected. This will occur sooner for a longer train. On my PII-450(slow by today's standards) I needed to set the timestep to 15 ms for a 70-car freight train to get tolerable frame rates, but could comfortably run 12-coach passenger trains with a 2 ms timestep. You will need to adjust the values accordingly for your machine, and naturally a faster machine can tolerate smaller values, even for long freights. On most machines you should be able to set the value low enough to give you only a few percent or less error, which is better than the default error of ~10% or more.

Incidentally, the timestep is also responsible for the broken coupler bug. Since the calculated distances traveled are too long by maybe about 10%, then on occasion the couplers are stretched by more than they would actually be in real life, and therefore break more easily as a result. Thus, lowering the timestep should mitigate that problem