MSTS Anti slip may not be realistic but was a handy tool. I would use it on a second engine when running two steam locos. Adding sand only worked on the player engine. I don't know if slippage occurs in multiple diesel lash ups, I guessing it does, but with steam engines you can see it happen visually.
So does ORTS stop the slippage on all units or just the player?
Wheelslip does happen to individual engines in a diesel lashup. AFAIK for diesel units, as long as they all have the statement they should all react to wheelslip individually if they are all set up as drivable.
Steam is different, it has its own wheelslip system.
Beer is not a matter of life or death, it is much more serious than that.
After reading all the posts about the MSTS Antislip parameter ( and some independent research ) I've come to the conclusion that it definitely does not belong in the OR include files for engine. The ORTS Throttle Down parameters - Wheelslip & Emergency - belong in the Engine section of the include eng file, where appropriate for the type of locomotive.
I think I need to do some testing with the ORTS Wheelslip Throttle Down and the ORTSAdhesion ( ORTSSlipWarningThreshold ( 70 ) ) parameter to try to discover if they have some sort of relationship. I think the default for the threshold parameter is 70, but I've never tried other numbers to see what effect they have. Up to this point all I thought the threshold parameter did was engage a hud display of wheelslip.
Cheers, Gerry
"A mind is like a parachute. It doesn't work if it is not open." Frank Zappa
It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.
Forever, ridin' drag in railroad knowledge. Audi, Vide, Tace, Si Vis Vivere In Pace
ORTS Wheelslip Throttle Down may work correctly for modern locos but what about older units like SD40-2 etc. How is the wheel slip controlled on multiple units?
I guess all of this begs the question: Is anyone working on 'more realistic' physics for freight cars and/or diesels????? I'll let someone else bring up the question about electric and steam.
In Message #21 there was a reference to include ( "..\\..\\Common.Std\\Engines\\Std_Eng_BrakesTS.inc " ), would it be possible to know what that looks like and how did you arrive at that set of code values?
I am figuring it out as I go along and found I had been making some assumptions that were not correct. Your code snippets were of great help in that area along with a search of the source code. I don't understand all of it quite yet but I am getting there. I see FCalc can provide some of the values for the friction but is the ORTSAdhesion ( ORTSCurtius_Kniffler ( 7.5 44 0.161 0.7 ) ) pretty much a constant across the board for both engines and freight cars?
In Message #21 there was a reference to include ( "..\\..\\Common.Std\\Engines\\Std_Eng_BrakesTS.inc " ), would it be possible to know what that looks like and how did you arrive at that set of code values?
I am figuring it out as I go along and found I had been making some assumptions that were not correct. Your code snippets were of great help in that area along with a search of the source code. I don't understand all of it quite yet but I am getting there. I see FCalc can provide some of the values for the friction but is the ORTSAdhesion ( ORTSCurtius_Kniffler ( 7.5 44 0.161 0.7 ) ) pretty much a constant across the board for both engines and freight cars?
Greg Davies
AFAIK the Curtius Kniffler numbers are empirical, derived from many tests and experiments over the years. Just search Curtius Kniffler on the web and you'll find test papers written up. There probably is no benefit from adjusting these numbers, although I'm sure people will try.
I did so and then saw the curves that resulted from my new numbers, the new curves did not come anywhere near the expected results. I think it is best to leave them as they are.
The brake parameters are derived from TS [SLI] brake sections. They are definitely not prototypical. Mine are a little faster and please my tastes for now, I'm constantly tinkering with them. If folks actually had to wait for a modern freight consist (mile long) to charge the brakes, they would complain. The values are a compromise between reality and enjoyable simulation. There has been a constant discussion in the threads (especially over at ET ) about slow brakes and some changes have been made to the code, other changes are waiting for priority or a coder to work them.
After all the palaver here they are:
Cheers, Gerry
"A mind is like a parachute. It doesn't work if it is not open." Frank Zappa
It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.
Forever, ridin' drag in railroad knowledge. Audi, Vide, Tace, Si Vis Vivere In Pace
Perfect Mr. Steele. Thanks you. That is exactly what I was looking for....a place to start or just stay for a while. I realize this "hobby" we are in is called a simulator and as such it simulates the real world not duplicate. I too find it difficult to wait for the air to come up as it would in real life and do short cuts to speed the process. I also would not wait 2 to 3 hours for the track to clear so I can proceed. I just want to get to what I enjoy. But on the other hand, I do want the simulation to be somewhat accurate and for what you have done, it suits my purposes perfectly.
comment ( 28.5t empty, 118t full )
Mass ( 122t-us )
The load is actually given in US units - metric weight of 110.7 was used to compute Davis numbers.
Although I don't give the question of weight too much weight...the user can always adjust to suit their ideas or experience.
Word of warning to all - be careful what you assume. Just because the Mass is stated to be in US Tons does not mean OR makes that conversion from US Tons to Metric Tonnes. In many cases OR takes the numeric value and then defaults that value to what MSTS was using it as, Metric Tonnes or Kilograms. Many of the unit conversions have not yet been implemented due to time and priority issues.
To be on the safe side, use the units that MSTS used. One of the major premises that OR used was to make OR work like MSTS and weight is important. Just because TS/SLI used it in their Wagon files does not make it so.
I only bring this up as testing coupler strengths is based on weight. If the weight is incorrect, your conclusions will also be incorrect. Otherwise, if the weight of the car is not that important then leave it as is and move on to more important matters.
In reference to the 2 problems Geepster presented in Message #1. The problem with the different behaviors involving a Save and Resume I will not address, but I will address the coupler issue. First off, I followed Gerry's examples and cleaned the engine codes for all three units with ORTS and set the MaxPower at the correct 4000hp setting of 2982.7992kW. Then cleaned up the tank cars and added appropriate ORTS code and changed the coupler setting. I then proceeded to test the train under various situations.
I found one interesting issue with OR. In the HUD using the shift F5, I found the reported weight of the tank cars was in excess of what I had entered in the Mass(), by almost 10%! I calculated the Gross Weight of the car by adding the Light Weight (car empty) together with the Load Limit Weight (maximum weight of the cargo the car can carry). Both of these added together equals the Gross Weight or fully loaded weight of the car. For a 30k tank car the LtWt is about 66,000lbs and the LdLmt is about 197,000lbs for a total of 263,000lbs. I like to take these values right off of the actual car for accuracy. Calculating the Metric Tons the Gross Weight is about 120 metric tons. This is the value I entered in the Mass() yet the HUD was showing 133 metric tons.
It is interesting to note that the HUD was showing 133 as the car weight. If the units of that value were US tons, then that would be about right BUT we should be dealing with Metric Tons as originally used in MSTS. (Remember, a lot of MSTS was written in England.) The HUD is only visual indications of what is going on inside OR so I have to assume the weight of the cars is being calculated incorrectly. I reduced the Mass() value by approximately 10% until the value shown in the HUD was 120.
The next thing I did was to increase the Break() values of the couplers to 2150kN each. At that point I could start the train from a stop on an 0.8% grade without breaking any couplers using reasonable throttle control. Word of warning, don't forget the covered hopper idler car. In my testing this was the car that took the most abuse so lower the weight of the car and set the same coupler values as the Tank cars.
Is all of this correct? I have no idea. The engine max power is correct for those units. I have no reason to believe other wise. The rest of it will take more research but atleast the train is moving.......on my computer.
Greg, it is puzzling why the various HUDs are a mixture of metric and US units. I suppose there was a reason for it, maybe discussed in the threads or the developers private forum. Never did make sense to me, if the input data (from the eng or wag file was metric, and most are) then the HUD should also be metric, why the need to convert for the display? Gerry
Cheers, Gerry
"A mind is like a parachute. It doesn't work if it is not open." Frank Zappa
It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.
Forever, ridin' drag in railroad knowledge. Audi, Vide, Tace, Si Vis Vivere In Pace
I have a test car set up as 100t-us mass. In the HUD the weight shown is 89.3 ltn which is a correct conversion from the US short ton to the Imperial long ton. This tallies with my choice of display units on the Options/General tab.
Beer is not a matter of life or death, it is much more serious than that.
Greg, it is puzzling why the various HUDs are a mixture of metric and US units. I suppose there was a reason for it, maybe discussed in the threads or the developers private forum. Never did make sense to me, if the input data (from the eng or wag file was metric, and most are) then the HUD should also be metric, why the need to convert for the display? Gerry
It is puzzling but understandable to a certain extent. Most programmers in the US have little knowledge of Metric measurements of any kind. The MSTS community has been forced into it because of overseas development. Programmers in the US tend to take the path of least resistance and think in terms of US measurements, everyone else Metric. It is easy to get confused and make assumptions.
What puzzles me even more is what units of measure are being used within OR that we can't see. Almost all characteristics of physics involve weight. Is the weight calculated correctly if the units were changed? Are the units being taken correctly to begin with? Can you tell me if there has been a document that describes the assumptions being made when data is being read from our files? Is the weight being read into OR as Metric Tons, US Tons, or some other unit of weight like kilograms? Inquiring minds want to know.
My biggest fear is that what we see in the HUD is not what is going on behind the scenes. All I know is the weight being displayed, whatever unit of measure that is, can be manipulated by changing the Mass() value in the HUD. Beyond that, I have no clue. All I know is that the changes I made now allow the train to work as one would expect.......at least on my machine.
I guess it is time to dust off my Visual C# compiler and run the code in debug mode to see what is going on inside. That is going to take some quality time of which I have little.
On the other side of the coin, I applaud the work that the OR group has done. We have a much better platform to run our trains on with room to grow. I gave up MSTS years ago and have been exclusively ORTS ever since. Even with the problems, OR is so much better than MSTS I really do not understand why some people continue to use MSTS. But they do and they have their reasons. So be it. I can live with that.
I have a test car set up as 100t-us mass. In the HUD the weight shown is 89.3 ltn which is a correct conversion from the US short ton to the Imperial long ton. This tallies with my choice of display units on the Options/General tab.
I stand corrected. I just looked at the Options/General tab and found the setting. So much for reading the manual. On my machine it is set to the default which is Player's Location. That means all of the weight measurements need to be in US Tons. The OR application will then convert to a standard weight to be used within the program. That makes a lot of sense. I wish I had known that earlier but I know it now and thanks for bringing that to my attention. Now I need to rethink whether to convert my files to Mass( US Tons ) or leave as Metric and then change the setting that Options / General tab setting. I need to spend some time with the manual, that is for sure, and back to the drawing board with the testing.
My appologies to everyone for misstating the now obvious.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, personalize advertising, and to analyze site activity. We do not share information about our users with anyone. For additional details, refer to our Privacy Policy.
By clicking "I UNDERSTAND" below, you consent to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Comment