[Genma Saotome]

disc, on 04 May 2016 - 08:54 AM, said:

I thought friction is already calculated with mass.

No. You need to use Fcalc and compute something yourself.


IMO Fcalc should be depreciated as a tool, it's formulas moved into the OR code, and the parameters and their values that one enters into fcalc moved into .engs and .wags (some of which are already present, such as whether the axle bearings are solid or roller).



Once the code can compute rolling resistance (by any name) you can expand into calculating MaxBreakForce(), MaxHandbreakForce(), and a few others, perhaps not used by OR, as all have values that are all mathematically dependent on the value of Mass(). Right now all of them are computed by a person and recorded manually in .eng and .wag files.

As an example, IMO it would be better for .eng and .wag to hold MaxBrakeForcePCT(nn.nnn, nn.nnn)* and MaxHandBrakeForcePCT(nn.nnn) (values being a real number representing the percentage of empty car weight used when constructing and caring for the brake rigging on real cars) and use both with MassEmpty() and let the program compute the maxbrakeforce and maxhandbreak force values used in-game.

* Default is both values are identical; for those cars with empty/load devices the second value should be about 10 percentage points higher and it should be used when the car lading exceeds MassEmpty() by more than 3 or 4X.

[steamer_ctn]

Genma Saotome, on 03 May 2016 - 10:41 PM, said:

No, not that, please.

Capture the parameters that you punch into fcalc and compute the result and get rid of that A, B, C stuff.

The A, B, C stuff is what allows users the ability to customise their settings, so even if OR internally calculated the default values for these input parameters, the A, B, C values should still remain for customisation purposes.

In the future, a special parameter input process with appropriate GUI, could be added to OR to make it "easier" for users to configure stock. Perhaps this is where the types of changes suggested could be incorporated.

Genma Saotome, on 03 May 2016 - 10:41 PM, said:

For mass() you need Mass_Empty() and MassLading() where the later may be fixed (a load of lumber) or something that varies such as passengers, coal, whatever. When attention is finally turned to making a modern AE you can add events that change the value of MassLading() by some fixed amount and use a different one that changes by some rate.

In the long term MassLading() belongs outside of the .wag file, either in consist or somewhere in one of the activity files (maybe a new one). That way you have one and only one .wag for a mess and it's animation mesh.

For loads that have already been defined as variable under the current freight animation functionality (eg coal, water, etc) the total full weight can be defined for each of these commodities within the freight animation parameters of the WAG file. If the freight animation commodity types are extended then different lading weights could be included in a similar fashion in the WAG file.

In terms of loading, there appears to be two types of scenarios currently being catered for:
i) Dynamic Loading - where the load varies during the simulation (or activity). This is fixed by those commodity types that are currently defined in the loading and unloading points. The types of commodities could potentially be extended, especially for loads in boxcars, but the need to co-ordinate the visual representation of the loads is not a trivial task. Thus for the time being, the means of specifying dynamic loads appears to be catered for in the existing freight animation
ii) Static Load - where load does not vary during the simulation. This is currently catered for by the definition of appropriate WAG files with relevant model shapes, and physics parameters defined.

Genma Saotome, on 03 May 2016 - 10:41 PM, said:

What you've got above is (1) not fixing the friction code and (2) locking in a value of Mass() for the lading that can never change. No loading of coal, no unloading of coal, no variable passenger count, no reduction in weight on account of using or replenishing fuel.

As you have suggested the future holds many different possibilities as to how loading could be handled within OR. These will require a reasonable degree of effort to scope the requirements, design and implement the code changes necessary to support the functionality.

The blueprint is considered a low effort proposal to align the physics parameters dependent upon the Mass to the actual current Mass of the stock. It was proposed to consider the effects of water and coal usage, etc on the weight of the locomotive and tender. These changes were to be within the static and dynamic loading capabilities currently defined within OR, and it was not intended to extend the scope beyond this (apart from allowing for the definition of the necessary additional parameters proposed).

I believe that this blueprint is consistent with the things that have been suggested, however if the community feels that there is little or no value in implementing the blueprint as currently proposed, then the blueprint can be "parked", until another developer, has the time and is able to explore an expanded scope.

[Genma Saotome]

No, the A, B, and C stuff isn't there as an aid to users to customize their friction, it is there to avoid having to code the Davis formulas, which would have been the correct thing to do in the first place.

When somebody builds a model of a car or locomotive they know the values of everything the Davis formula needs as inputs. Given that there should be parameters available for them to hold those values. Once entered by the modeler they're most likely fixed for all time, much in the same way most other .wag and .eng parameters are permanent.

Having ignored creating those parameters and instead using the product of fcalc the end user trying to "modernize" his files has to jot down on paper the input values to Davis, use fcalc, AND jot down the output which is then transcribed into those A, B, and C parameters. Isn't it more sensible for them to simply enter the input values into the .wags? Once there the program can compute the relevant A, B, C values so nothing has to change "downstream" where rolling resistance is actually applied.

Doing that also means that anything that changes the total mass value can be used to re-calculate the current rolling resistance. You cannot do that now.

The more code you pile on top of that A, B, C stuff the more work it will be for somebody else to come along and do the right thing with it. Why make more work for them? Better to fix it now.

[steamer_ctn]

Most of the resistance values are determined by testing and plotting points on a graph. A quadratic formula of in the form of - R = A + B * V + C * V^2 is then developed to suit the points.

Samples of these types of formulae can be found in the fcalc documentation, and also on this page in the table headed "Comparison of Specific Train Rolling Resistance Formula from Several Countries". Other examples could also be turned up with a bit of Google searching.

The one thing ALL that these formula have in common is that they are in the above format, ie A, B, C values. In studying the formula from the above examples it can be seen that the derivation of these ABC values varies greatly just across the formulae, so to provide the necessary input values to the ABC values to allow OR to calculate all possible permutations is probably not able to be guaranteed with 100% accuracy, and attempt to even do so would require a huge number of "user input variables" to cover the different combinations. So the question would always still come up, how do I input the "special" resistance value that I have found for my rolling stock?

It appears that the the proposed blueprint is not of sufficient value to proceed with, so I will cease work on it, and allow another developer to take on some of the expanded scope suggestions provided.

Thanks for the feedback.