[Matej Pacha]

Finally, I've found the information and I have some basic solution ready to committ. Now I'm adding an option to enable/disable a train speeed dependency, as it can affect activities (more tractive force will be needed at low speeds in curves).

Matej

[jtr1962]

Genma Saotome, on 03 February 2014 - 08:31 AM, said:

Mervyn, the difference between an amateur coder and a professional coder is not found in the technical sophistication of their code -- amateurs can and do write brilliant stuff (any many are employed as coders); the difference is in how well the code is suited to long term support and adaptability. If you put into the .wags the elemental data and into the OR code the list of formulas that Joe has documented in his spreadsheets then not only is there nothing to worry about WRT the status of FCalc2 but you have the bonus aspect of later on redefining the meaning of the parameter "tons" in the .wag file as the default weight (so it now means the empty weight) and adding to the consist file lading weight such that the sum of the two is used the OR program... a fairly trivial change. One can also add yet another variation of the formula to the code. OTOH if you put the product of those elemental data into A, B, and C and locate them in the .wag, later on it becomes much more difficult to use the consist file to describe activity based lading. Sure, you could move A, B, and C there but by then EVERYBODY has to go and re-calculate them in order to use the new feature. I think both coders and end users would prefer to just do a lookup (perhaps w/. the aid of a GUI) and and find Lumber, 32t and add that to the consist entry and go back to the .wag and enter a value for empty weight. And what does one do with a new variant of Davis? Hope Joe shows up?

I've read your concerns here and I agree the best long term approach is to incorporate all the Davis variants into the OR source code so there are no issues in the future about the status of FCalc2. For my part I'm fine if any portion of my source code is used. In fact, I've said from day one that the FCalc source code can be freely reused as part of another program.

I also agree with your long-term vision except I think we should retain the ability to use customized A, B, and C coefficients, especially for rolling stock where the mass isn't likely to change in the course of an activity. Whether those coefficients should go in the .wag file or elsewhere I don't have a good answer to. For cases where custom coefficients aren't present Open Rails would default to calculating its own values based on the wagon type, weight, and length, as well as the location within a consist (i.e. trailing locomotives have lower aerodynamic resistance than lead locomotives). One thing we might consider is directly using the shape files to obtain cross-sectional area and length rather than relying on data in the .wag files (which is often incorrect).

In the long term it's important that this project go on regardless of the status of individual contributors. Try as I might to keep on top of things, life gets in the way, and my involvement for the last year or so has been sparse. I'm sure it's the same with others. Moving forward, we need to gradually reduce our reliance on any non-open source software. If possible, the best approach is to get the developer's permission to incorporate some or all of their source code into Open Rails.

[Genma Saotome]

Thanks for your agreement Joe.

WRT your comment about the circumstances where mass doesn't change per the activity, IMO mass should always be determined by the Activity's Consist file, not by the mesh file. It makes no sense to me to have n number of .wag files for the same mesh when the only variable is the lading -- name, consignee, and weight (with the effects it has on physics). I'd much prefer to see 1 .wag and put the variables in the Activity's Consist file... then have OR compute their effect. Open top cars should be using an assembly step (call it FA if you want) and once again that could be handled as feature of the Activity's Consist file.

The open issue is what to do when you don't want to bother with any variation and that, I think, is best answered by shoving whatever that is back into the .wag file as an optional default, fully open to being replaced by data in the Activity's Consist file.

IOW something like this:

MeshFile <----- either .sd or .wag, depending on other decisions
	CarType ( string ) <----- same purpose as fcalc2.
	EmptyWeight( n tons)
	DefaultCrossSectionWidth( n )<----- only if it cannot be obtained from the mesh or bounding box data.
	DefaultCrossSectionHeight( n )<----- only if it cannot be obtained from the mesh or bounding box data.
	DefaultLadingName( Empty ) <----- edit only when you do not want to use consist based lading.
	DefaultLadingWeight( 0 tons ) <----- edit only when you do not want to use consist based lading.


Consist
	ActualLadingMeshFileName ( path filename.s)<----- optional. include only when the lading is visible.
	ActualLadingName( string )<----- optional. include only when you want consist based loaded car.
	ActualLadingWeight( n tons)<----- optional. include only when you want consist based loaded car.
	ActualConsigneeName( string )<----- optional. include only when you want consist based loaded car.
	ActualCrossSectionWidth( n )<----- optional. include only when the lading causes the value to change (e.g., on a flat car)
	ActualCrossSectionHeight( n )<----- optional. include only when the lading causes the value to change (e.g., on a flat car)

That gives you one mesh file and one .wag file to manage and all of the activity variation anyone might want.

[jtr1962]

I like those suggestions, Dave. It will also make things MUCH easier from a developer's perspective in that they just need to concentrate on the 3D model and textures without worrying about the physics. The beauty of your approach is that it lets the Open Rails team continually refine the physics without requiring reediting hundreds of .eng or .wag files just to add or change parameters.