New NAVS EMD645 package question

[Erick_Cantu]

Ok, good info folks, I'll see this in my .eng file, so I can try removing it, and re-inserting your, yes?:

include ( "Std_Eng_GP38-2.inc" )

I don't know what's in that specific file, so I can't comment. If there is more than just an ORTSDieselEngines block, you will need to open the Std_Eng_GP38-2.inc file and replace the ORTSDieselEngines block with data from one of the 16-645E include files. My files only include the diesel engine parameters, and if Std_Eng_GP38-2.inc has more than that, then you would lose all of that data and probably have a nonfunctional locomotive if you overwrite the entire file with my data.

[qballbandit]

I removed the original .inc statement in the .eng file, then inserted Erick's - all is right with the world now!

[wwhall]

I know that a lot of folks put their .inc files in a separate folder from their .eng files and then point the "include" statement in the .eng file to that location. I understand the logic behind that--if one wishes to modify an .inc. file used in multiple locomotives, one only has to modify the one .inc file that the multiple locomotives use.

I don't generally use that method and here is why: I like each locomotive to have some unique parameters--slightly different RPM scales, different smoke settings, etc. So, I place my .inc file in the folder with an individual locomotive or group of locomotives. Then, just point the "include" statement to that .inc file--e.g., include ("ABC_123.inc") .

This method does not lend itself to Erick's .inc file regimen. Nor does Erick's regimen like to have multiple .inc. files other than his in the locomotive .eng file that could conflict with his files. My suspicion is that TS-type ORTS statements in an .eng file could also potentially conflict with Erick's .inc file regimen. I like Erick's sound files, but I only have used them, so far, in .eng flies without other .inc files or embedded ORTS statements.

[geepster775]

I don't generally use that method and here is why: I like each locomotive to have some unique parameters--slightly different RPM scales, different smoke settings, etc.

Agree. Completely.

[eric]

Same. No two pieces of mechanical equipment are going to perform exactly the same. They'll be close, but never exactly the same.

Sent from my SM-S911U using Tapatalk

[Erick_Cantu]

I like each locomotive to have some unique parameters--slightly different RPM scales, different smoke settings, etc. So, I place my .inc file in the folder with an individual locomotive or group of locomotives. Then, just point the "include" statement to that .inc file--e.g., include ("ABC_123.inc") .

This method does not lend itself to Erick's .inc file regimen.

I think that idea lends itself fine to the way I set things up, in fact, that's exactly what I did!

That's why there are 4 versions of each include file for each engine, and that's why I place the DieselEngineMaxRPMChangeRateRPM parameters on my own locomotives in the individual ENG file and not the remote physics files. This allows the user to have 4 slightly different sets of smoke parameters right out of the box, and the RPM change rate value in the individual ENG file sets the rate of change. True, I didn't really put much variation into the RPM tables, but that's a simple thing for a power user like you to do. In fact, all the user has to do if they want even more variation is copy one of the files, place it wherever they want, change the RPM table or smoke colour/opacity values (I don't recommend changing the smoke rate, those are synchronized to the rate at which the engine should be sending smoke pulses at any given RPM), and add in the correct path.

The main reason things are set up the way they are is because the typical use case is applying the sounds to an old MSTS engine without an ORTSDieselEngines block. You also can't use the values included in existing ORTSDieselEngines blocks, and I don't have the energy to make a conversion for every existing locomotive with an ORTSDieselEngines block, which means it makes more sense to provide the data for users to copy into those locomotives.

These sounds need a dedicated RPM schedule because they go all the way down to full stop (actually 5 RPM) and all the way up to 1000 RPM because some 645 engines run at 950 RPM and some idle well below 318 or well above 318, meaning the minimum and maximum RPM are set outside of the actual RPM range with the actual in-sim values applied with the RPM table. If I didn't do this, you would need:

1. Separate startup and shutdown sounds with all of the problems that experience with the 567 has shown that this introduces (e.g., looping issues, issues with startup sounds playing when the SMS loads in when the engine is already running)
2. Separate frequency curves for every single of the multiple RPM schedules used on the 645-series engine (I don't have the energy for that, especially when it's completely unnecessary)

With separate startup and shutdown sounds, you'd also have awkward pauses and other issues during a cancelled start or a shutdown under power (a possible condition with several different OR parameters). It just made more sense to simulate the entire engine operating range plus a little extra just in case OR gains the capability to simulate how RPM spikes when a locomotive dumps load (e.g., under transition or wheelslip). But that means the user has to have either the knowledge to edit the RPM range and throttle tables correctly, or they have to have a set of pre-made files that allow them to quickly apply the appropriate parameters without digging into the guts of an ORTSDieselEngines block that the typical user probably doesn't understand anyway.

You can certainly use any locomotive with an existing ORTSDieselEngines block, but you would need to edit the idle and max RPM values to 5 and 1,000, respectively. But if you're at the level where you are comfortable with doing those things, then you don't need much more than a quick peek at my include files for guidance anyway. And the side benefit is that the engine sound will be correct regardless of what RPM values you set because any value between 5 and 1,000 is fair game.

[yellowdog]

Yeah, I've been able to customize that package to make specific loco profiles now that I know how to get it to play nice(r) with other inc files.

[R. Steele]

There are now several different examples of the ORTS Specific Diesel Engine Definition ( found in manual section 8.2 of the manual ) for general use...all work fine. All use the include file option --- in somewhat different ways --- coded into OR.

However, difficulties usually arise when the end users start mixing and matching elements of the different examples....especially if they are not accustomed to using include files.

I have integrated Erick's well thought out files into mine, I especially like the attention given to matching the rpm values to the throttle and sound files.

It is not necessary to use the OR Diesel Engine Definition....OR is coded to build an engine definition using data from the MSTS engine file: [from the OR manual]

If no ORTS specific definition is found, a single diesel engine definition is created based on the MSTS settings. Since MSTS introduces a model without any data crosscheck, the behavior of MSTS and ORTS diesel locomotives can be very different. In MSTS, MaxPower is not considered in the same way and you can get much better performance than expected. In ORTS, diesel engines cannot be overloaded.

Because diesel engine behavior is different in OR it is important to note the following: [again from the manual]

In configuring the locomotive correctly it is important to use the correct power/force values. The key values required in the ENG file for a diesel locomotive (regardless of transmission type) are as follows:

ORTSDieselEngineMaxPower ==> sets the maximum power output at the shaft of the diesel engine (or prime mover).

MaxPower ==> sets the maximum power at the rail (provided to the wheels).
MaxForce ==> sets the force that the locomotive is able to apply to the wheels when starting.

MaxContinuousForce ==> is the maximum force that the locomotive can continuously supply to the wheels without exceeding the design specifications. Typically this is linked to a particular speed (see next parameter).

ORTSSpeedOfMaxContinuousForce ==> is the speed at which the maximum force will be applied.

MaxVelocity ==> is the maximum rated design speed of the locomotive. Some locomotives had a speed alarm which applied the brakes, or set the throttle to a lower value. This can be modeled using the OverspeedMonitor function.

etc. <<see manual

If an OR Diesel Engine definition is used the following is very important:

If the ORTS specific definition is used, each parameter is tracked and if one is missing (except in the case of those marked with Optional), the simulation falls back to use MSTS parameters.

<<<My Emphasis

So mixing and matching, or editing the OR diesel engine definition or the OR Standard engine files available without care can result in errors or the sim not performing correctly.

[LuFeDuTi]

I translated the readme file, understood it and the sound worked in Open Rails. I put it on my Favorite Locomotive, the GMD SD40-2W which comes in a CN package that is on Trainsim