[Genma Saotome]

Not that I think this will make any difference but I do want to be on record, again, as strenuously objecting to the placement of the ORTSDavis parameters in .wags and .engs.

The data files should not be holding the product of some several formulas, they should be holding the input values to those formulas. In this very specific case the problem caused by ORTSDavis fields is it locks in the total weight of each .wag and .eng within those files.

.Wag and .eng mass() should reflect the empty weight. Final, loaded weight should be determined on an activity by activity basis (or if not there, in a modified consist file).

Including the ORTSDavis parameters in 1.0 anoints them as proper and encourages end users to put them into their files. You do that and it greatly impedes the ability to differentiate empty from loaded weight, managing both values where they should properly be managed.

AFAIK the ORTSDavis parameters were chosen simply because it was faster to code them that way. That's a piss-poor way to design features.

[Lindsayts]

Hmmmmmmmmmmmmm.....

The problem here is as I see it at the moment one actually cannot load a wagon in MSTS, loaded and unloaded actually having separate wag and in most cases shape files.

The only parameters that can be changed are weight and frontal area, both of these are taken up in MSTS by empty and laoded wagons being separate. If it every becomes possible in OR to actually load a wagon say at a silo then it will be time to consider doing something more constructuve , say such as two sets Davis parameters on for empty the other loaded.

As I understand it though the Davis parameters are ____OPTIONAL____ IF there not present OR calculates the data from parameters out of the wag file. The main reason why the Davis parameters are in the file is to allow the those few accuracy or exeprimenaty people out there a chance to tune the parameters.

Lindsay

[Genma Saotome]

There are two problems. First is whether the .wag file defines what occurs in the activity or the activity defines what occurs in the activity. Today if you want the same model to have a variety of weights -- load vs empty for instance -- you need to create a .wag for each one. The greater the variety of weights, the larger the number of .wags. The only difference would be those parameters that rely upon weight.

IF, OTOH you let the .wag describe the empty weight and put a new parameter for lading weight elsewhere -- consist or in an activity file -- you need only one .wag; How that car physics behaves in any given activity can then managed in the activity files where it belongs. And that can include other new parameters like LadingName() and possibly Consignee().

As for locomotives, steam locomotives especially , the tender weight changes over the run. It's weight, along with all parameters influenced by weight, should be periodically recomputed.

In addition to friction, MaxBreakForce() is also based on weight, specifically empty weight vs. loaded weight -- that's why there are empty/load valves on freight cars. Leaving the .wag to carry the mty weight and placing the lading weight as a new parameter elsewhere allows the software to compute MaxBreakForce() as well as all of the necessary products of the Davis Formula.

Besides, which makes more sense to the end user: Recorded FrontalArea() and LadingWeight() or fidling around with fcalc and transcribing those rather incomprehensible values?

[copperpen]

First of all, I think we are trying to be as close to MSTS as is possible and so the majority of the coding is towards that goal for the release of V1. What is being asked for here requires a rework in the way wag and other files are looked at and is probably best saved for use in future versions as more time can then be devoted to getting things right. As things stand right now, we do not have any facility in the MSTS AE to have varying weights at different points in the activity. We merely put together a consist and give it a location or path along with any required instruction. In this context using either the MSTS friction or the ORTSDavis on a per wag basis is correct.

When we have a working OR AE then this concept has merit. Even more if we develop load/unload facilities as well.

[Matej Pacha]

First of all, I don't think there will be a big difference between loaded and empty car in the friction formula. Based on the theory, the first the friction consists of rolling friction (wheel-rail and bearings) and air friction. The rolling friction acts at low speeds and can be affected by the car weight/load. The air resistance is given by the front area of the car, thus shape-dependent. But this part has a major impact on the friction in speeds let's say above 20 mph.
The main impact on the pulling force is always the weight - it is an input to the gravity force calculation and to the acceleration calculation. Loaded train is harder to start or run uphill than an empty train.
In ORTS, the friction is always calculated using Davis coefficients, being calculated based on the Friction data or read from the eng/wag directly.
Finally, there are no data that would fit a calculation of the friction for the range of empty to loaded car. I know that several railways have specific Davis coefficients for empty and for fully loaded trains, especially in Russia there are sets of coefficients available and valid for 2/4/6/8 axle cars, empty, loaded, box, flat, tanks, etc. for a very specific ranges of speeds and weights. There is no some sort of general expression.
And finally - there is a difference in the friction calculation for locomotives pulling or coasting. That could be implemented too, if somebody has the data available.

Matej

[Genma Saotome]

Ok... let me explain: The documentation is what set me off. I've no problem w/ the ORTSDavis parameters being used as a testbed for understanding how the Davis Formula will work in-game. Things like that should occur on various topics. I object to the recommendation that people implement it as "The Solution". As I tried to convey, it is the wrong solution long term and telling people to implement it will only get in the way of obtaining the better solution down the road. So leave it in the code so it doesn't bollix up 1.0 but don't encourage folks to apply it fleet-wide.

Second, yes, there is no data (or formula) available to fit an empty-to-loaded range of values. Instead we have to provide one set of values the refer to an empty car and a different set of values that apply to a loaded car. Right now that is done with multiple .wag files. I have more than a few examples of 1 mty and 6-8 loaded .wags, all for the same mesh. So the more loaded cars one has the greater number of .wag files. That alone is bad practice.

People who make car meshes should simply set up the .wag with an empty weight. One mesh, one weight, one .wag. Period. At some later time, either in the hands of an activity designer or your average end user, a decision is made to use that car in an activity where a loaded weight is desired. By finding a home for a new parameter called LadingWeight() whatever that decision is not applied to the .wag file but instead to the chosen Activity based file. So now, in the one .wag, there is EmptyWeight() and elsewhere is the are n different occurrences of LadingWeight() of which only one is relevant to the activity. The OR software adds the two, plugs the sum into the Davis Formula and spits out ORTSA(), ORTSB(), and ORTSC() for use elsewhere in the program. It can also now compute MaxBreakForce() because now it knows whether the correct thing to do by checking LadingWeight()=0 to mean an empty can and !=0 to mean a loaded car. That takes one parameter out of the .wags. The same is likely true for DerailForce() and DerailBufferForce() as values for both are also likely to determined by the total weight of the car.

If you want to add a lot of sophistication, open top cars could have the visible lading mesh chosen witht he activity file as well. One activity sees that flat car with a tractor and another sees it with three large wood boxes. But it is still one mesh, one empty weight, one .wag.