ORTS Engine file for OpenRails - Annotated

[R. Steele]

...it will also simplify the process of upgrading from MSTS and then changing settings as our collective knowledge improves. This is because having a master list of open rails files means one change can then be reflected in the whole fleet that refers back to that file.

Chris makes a good point that is often overlooked. There is mammoth library of legacy MSTS equipment, free&pay-ware much of it without "flintstone" wheels and with proper looking couplers, brake hose, good textures and correct number of rivets - you get the point.
The OpenRails folder and the include file method is ideally suited to dealing with this. It also provides to those members who do not wish to engage in file work a lift up to OR standards. That encompasses the ideal of community good.

You know using common.cab and common.sound is also up to the end user and there are alternative schemes. But I value having stepped into a world that's been organized that way.

To add to this:
I think many members without a sense of the history of MSTS do not realize that both the Common.Cab and Common.Snd folders were another brilliant invention ( along with BIN and many other ingenious hacks) that helped keep MSTS alive.

Now on the flip side, I can surely envision a day when people will want an engine or wag file specifically constructed for OR.
Heck, who knows, we may even have different file names designed for OR by then.
So you guys proposing the various ideas and methods to go about that should get to work.

[muskokaandtahoe]

To clarify, any use in a .wag or .eng of common.cab or common.snd is, in essence, using an Include() statement w/o actually having to type Include().

They work in an identical manner, identical syntax, and identical purpose: Locating a file that will be used by many .wags and .engs.

Naturally each user doesn't need to keep those /wag and .eng files as coded by the author... they can strip away either or both commands and do whatever they want to do. Or they could put their time elsewhere because what's been handed to them is simple and it works.

A further study of what 3dtrains has done with its locomotive packs will show an identical concept to the proposed common.model folder. Instead of common.fleet Marc used a folder called 3dtrains_Fpack. Everything in common to all of his Funits went there. How many people got rid of that folder by moving it's contents to every F Unit folder where the .engs were? My guess is zero. In fact, if Marc was creating that stuff today and chose to use the proposed common.model folder the result would be "\trainsset\common.models\3dtrains_Fpack" and right next to it would probably folders for products from BLW, MapleLeafTrains, etc. etc. Result? A cleaner, slightly less cluttered \trainset folder.

My point is the proposed common.whatever are simply a continuation of what vendors have been doing since MSTS was first released and so long as they work there is no need for anyone to change files that make use of them.

[muskokaandtahoe]

WRT documenting all of the new OR specific parameters as used in .engs and .wags... is there a real need? Yes, yes, YES and absolutely.

Doesn't matter if it is all in .eng file format, text, excel, anything will do.

The real question is who knows what is OR Specific?? I rather doubt the OR developers have a complete answer.

[Erick_Cantu]

So I went through and used the sample diesel locomotive at the Coals to Newcastle site as a template to build an OR-specific GP7, so that Gerry and I can compare our results, and so that y'all might get an idea of what ended up going into it. What I did was overwrite all of the template's parameters with the equivalent ones from the physics I had been using. A simple copy/paste job. Many parameters were pruned, evidently too many, as the locomotive refused to load. I determined that the offending parameters were somewhere in the Engine section of the file, and began pasting in blocks of data from the original file until it would finally load. The original .eng, which refused to load, is attached, as well as the current one which works. So some values might still be pruned:

master physics GP7.zip

Some notes:

1.) I am no longer bothering with 2D cabs, but OR requires the cabview line anyway. So I specified a nonexistent file.

2.) The OR ChangeUpRPMpS and RateOfChangeUpRPMpSS values may seem large. This is because, using such values, we can trick OR into making the engine sound as it should - going past the governed engine speed and then coming back down as the load comes in. Unfortunately, this only really seems to work when the framerate is around 20-ish, so I might use "normal" values in the final release. Above 20FPS or so, it just sounds like it would with smaller values.

3.) The power values in the diesel power tab are all guesstimates of gross horsepower based on some quick and dirty calculations done from a 12-567B graph. What I did was figure out the gross power per cylinder for the 12-567B with the graph values, then multiplied this number by 16, and then again by a coefficient derived from the traction power values to produce an estimate of what a 16 cylinder engine produces. The last step was necessary because, while the 12-567B develops a traction horsepower of 1200, or 100 per cylinder, the 16-567B only develops 1500, or 93.75 per cylinder. Since I know that the accessory load on the test engine used to make the 12-567B graph was roughly that of a real GP7, the coefficient was necessary, or we'd have an engine delivering some 1600 HP for traction - which the real 16-567B, to the best of my knowledge, does not.

4.) Nobody really seems to know what OR really wants from the fuel consumption tab (it ain't what the manual says, I can guarantee you that). So, at some point in time, I entered a value of "100" here, observed the consumption in gallons per hour in the HUD, then used the resulting number (3.79) as a coefficient to convert real-world numbers to something that produces correct fuel flow in OR.

5.) The non-functional original test .eng attached in "master physics GP7.txt" has parameters for a 16-567C.

6.) I did not bother with OR adhesion curves because I have no clue how I'd find the required data to make them. I'm not going to waste the effort guessing when OR will automatically guess for me.

7.) Friction data is from Fcalc2. I made the calculations based on a four-axle, 246,000-lb GP7 running at 65MPH, with a frontal area of 145 square feet (the largest cross-sectional area on a GP7 is 14.5 x 10 feet). I used US units because EMD built and specified the locomotive in US units, therefore all of my data is in US units. There's no need to convert values when OR is a big boy and can handle it.

8.) I forgot to edit the locomotive description to reflect the lower output of the 16-567B - like anyone reads this anyway.

9.) I did not set up the locomotive to reduce power when the wheels slip. This is because the docs suggest that OR will actually throttle the engine down, which is not at all how this system should work. Real anti-wheelslip systems of this era reduce power through the transmission, leaving the engine running at the governed speed (although it should be said that the governor can't quite keep up with rapid changes in load, so the speed will oscillate a fair bit as the field excitation is reduced and increased to control the slip).

Now that I think I've pruned away almost all of what can be pruned, and come up with the OR-specific values that I can, the intention is to put many of the common parameters into include files in my own common folder where the sound files and crew figures will eventually be. Certainly, this will involve its own debugging woes. There, but for the grace of Bob Mould, go I.

[R. Steele]

Hi Erick, just saw that you posted, will download and take a look...always good to see you doing something useful...
I don't mean to beat that phrase to death...it's just that when I saw you use that phrase in a thread you opened (was it at ET) I guffawed out loud...
I don't know why...it just struck me as funny, self-deprecating, and oh so true on those days we all have, when it seems that nothing we are attempting is turning out as expected, we feel useless.

[Erick_Cantu]

There have been some good surprises. I found out the other day that distance can be used as a variable in an SMS file, so I've been working on close/far sounds for the new 567 sets. This, unfortunately, quadruples the amount of work to do, as I'm blending several different mixes of sounds together depending on distance, which means creating distant horn sounds that synchronize perfectly with the close sounds (that is, every single portion of the clip must be the exact same length; all cue points must be in the same place).

I wonder if there is a list of variables as OR reads them somewhere, for example, power is variable2; throttle position is variable1. What does the internal code call the amperage? I suspect OR is capable of delivering a whole lot more in an SMS than any of us think it is. I wonder if there's a way I could somehow read camera position to mimic sound cones for directional effects (this would come in handy with horns).