Notice to all visitors and members of the Train-Sim.Com message forums: If you plan on using a signature banner in your posts, we would like to remind you that there is a maximum size for banners. That maximum is 450 pixels wide by 120 pixels high, and not to exceed 25k. Your compliance is appreciated. FORUM RULES Problems? There are two common reasons for problems with logging in and posting messages. The first is that you are running a firewall that prevents your messages from being sent to the server. The other is that you have cookies disabled; the DCForum software requires cookies to work properly.
I have recently been doing some steam locomotive performance tests and in looking at the data, the average speed off the mileposts was always a lot higher than the speeds in the HUD indicated they should be.After looking for ways to correct this in the .eng file and searching the various forums, the only references I could come up with were that there is a tile size error.I have the advantage of being a navigator, so decided to test on a 33 mile stretch of the NEC recording Time, HUD speed Latitude and Longitude at each mile post. Then calculating actual distance geographically and from this the geographical speed. (one mile intervals were used to minimize the curvature effect)Navigational calculations give results in nautical miles, not land miles.The end result of all this was that there are two errors:1) The geographical mileage was 35.66, the milepost mileage was 33.6, there is a 5.78% error in the tile size. This has been demonstrated elsewhere.2) The HUD speed appears to draw from the route mileage, however in mph it makes no sense, however if converted to knots ( nautical miles per hour ) the two results are only off by 0.43%.It is fairly clear that what you see as 125 mph on the HUD or speedometer is in fact 125 knots and is equivilant to 144 mph in reality.I think this goes back to the origin in M$ Flight Simulator where knots are used.For those working in metric, since flight sim is understood to allow kph as a speed, then the metric speed on Trainsim should be close to reality although this has not been tested.
First of all, the only accurate measure is the distance to next signal. The mileposts can be arbitrarily placed.Second, the error has nothing to do with using knots instead of mph. Rather, it is due to the default timestep of 10 ms used by the sim. This produces a speed about 15% higher than indicated(actually the percent error varies by train length). It is always smaller for longer, heavier trains. By setting it to 2 ms(if your machine is fast enough since a smaller timestep=more calculations per second), the error is 2% or less. You can change the value by opening the default.wag file located in the Program Files\Microsoft Games\Train Simulator\TRAINS\TRAINSET\DEFAULT folder with Wordpad and looking for the following line:"10ms # On-track solver timestep"Change the 10ms to something lower. If you have a 1 GHz machine, try 2.5 ms. For a faster machine, try 2 ms. For a slower machine, maybe 3 or 4 ms. You will notice that the actual speed over the route is now much closer to the indicated speed. Keep lowering it until the frame rates with trains you normally use start to become unacceptable, and then bump it back up a bit. Short passenger trains can use lower timestep values than long freight trains before the framerates become unacceptable.
Thanks for the input Joe,I redid the test using kph instead of mph and the error is similar.The fact that the error was almost spot on for knots to mph mislead me, however it was a useful excercise and for users of slower machines will still be a valid correction.As far as the individual mile posts being out, I was aware of this and made the run of 33 milepost miles checked against external data to average this out.
You're quite welcome I thought something similar when I first discovered this problem. I initially thought they were using nautical miles instead of statute miles, but once I saw that different length trains had different amounts of error, I knew it was something else. Eventually I found the file that contained the timestep parameter, and thought that this was probably it. Turns out it was, and if you have a fast enough machine you can reduce the error to nil by setting the timestep at something like 0.5 ms. However, I would imagine you would need a 5 GHz machine in order to be able to run long trains, although my machine(1.57 GHz) will happily run passenger trains with that timestep. However, I ultimately chose 2 ms as a good compromise value because I can run long freights at decent frame rates, the error is <2%, even for very short trains, and the error is practically nil for longer trains. Much better than the default error of 15 to 20%, which I consider completely unacceptable if you're trying to run trains on a schedule.