Testing New Engine RPM Behaviors (+ more tweaks)

[pschlik]

Building off the diesel sound features, I have just put up some new changes for diesel engine RPM control and fuel consumption, and it's worth giving a test. See the pull request for the specific tiny changes made, because I'm just going to cover the high level here. This is present in unstable version U2026.07.15-0137. I can't guarantee it'll be in every unstable version due to silly conflicts.

First off, even if you aren't planning on using the new features, there are a lot of changes that will affect all diesel engines even if you change nothing, so testing is needed to make sure nothing horrifically breaks! Anyway, here's the changed stuff:

No more limitations on throttle RPM table! The core thing that's been changed is that now the diesel engine can be run to any RPM independent of the tractive effort without odd behavior or strange workarounds. This means that the ThrottleRPMTab can have constant RPM without OR automatically adding 1 RPM (900 RPM idle, 901 RPM notch 1, 902 RPM notch 2...that's gone) and RPM can actually decrease from one throttle setting to the next. A variety of real locomotives can now be modeled much more accurately, so consider checking your ThrottleRPMTabs to get rid of those workarounds.

New fuel consumption model! Fuel use will now vary with engine load and engine acceleration. This synergizes nicely with the ability to hold RPM constant at multiple throttle settings, as fuel use will be accurate even in this case. At minimal load, fuel use is determined by simulated friction, and when accelerating an engine will use a lot more fuel than when holding a steady speed. No additional inputs are needed, as much as possible is estimated from existing data, so please check that fuel use at full load and steady-state is the same as it was before. You should expect to see lower fuel use than before when at low power output (like revving in neutral, or at low speed before the transmission is up to full power), varying fuel use when engine RPM changes, and slight variations in fuel use even when driving normally. All that's intended (and, contrary to what some people seem to think, physically normal behavior). Things that would not be normal would be something like the fuel tank draining twice as fast as usual. Also note, if you were using the new diesel sound features, engine power and engine torque will behave different due to this change and that might require some adjustments to those sounds.

Reworked default engine cooling! The previous engine temperature/cooling system did not make any physical sense, and it wasn't working well with the other changes I made, so that's been reimplemented. Engine temperature is now based on engine fuel use (ie: more burn = more hot), ambient temperature, the type of cooling system used, and the temperature values given in the engine definition. Again, no file changes are required for the new system to take effect. You can expect to see engine temperature go up when running at high power, and go down when idling (I know this sounds obvious, but the previous system didn't even model this properly), with higher engine temperatures in summer than in winter. Each cooling system type has bespoke behavior, with the proportional system (Cooling ( 3 )) holding temperature most accurately and the no cooling "system" (Cooling ( 0 )) doing a terrible job to keep consistent temperatures. There's still no consequences to high or low temperatures, but the values shown in the HUD and on cab view controls should at least be sensible now.

Changed smoothness of tractive effort for older engine files! One thing that had to change for things to work is tractive effort delivery. Previously, the engine RPM controlled tractive effort but that has been disconnected. Instead, the MSTS parameter RunUpTimeToMaxForce (or 10 seconds if no run up time was given) and the rate of change of engine RPM are now used to determine how smoothly tractive effort changes. You should get the same amount of tractive effort, but it may be a bit slower or faster to build up than in the previous system. If you want to control this further, use the "traction force retardation" feature. (If you already use traction force retardation, then you will see no changes. This feature only applies to locomotives without traction force retardation configured.)

And a bunch of under the hood stuff. No need to go into specifics, just try various diesel engines and make sure they load in without new errors. While plenty of functionality is unchanged, the exact way diesel engines are loaded has been streamlined...it's still complicated though.


Ok, now for the highlight new features:

Discrete Engine Speed Control
Due to the way ORTS engines are built out of lookup tables in the form of linear interpolators, it is possible for input values in-between those defined to result in output values in-between what's defined. That is just how interpolation works, of course, but for certain systems in some locomotives that just isn't accurate; only discrete output values can be produced even if the input is continuous. One such case is the engine RPM demanded by a governor. Electro-hydraulic governors can only produce a few predefined RPMs, and not anything in between (hence the 8-notch throttle seen on North American equipment, as opposed to a fully analog throttle handle).

To replicate that, rounding has been added as a feature to interpolators (which technically means it's not an interpolator anymore) which can be implemented in a diesel engine by adding the SpeedControl parameter to the diesel engine block. The accepted values for SpeedControl are SpeedControl ( "RoundDown" ), SpeedControl ( "RoundUp" ), SpeedControl ( "RoundNearest" ), and SpeedControl ( "Continuous" ) (this is the default mode). If any of the "Round" modes are selected, then any table that produces an RPM value (eg: ThrottleRPMTab) will round the input (eg: throttle %) from the actual value to one of the values defined in the table, then return the RPM for that. This prevents producing an "in-between" RPM value, much like an electro-hydraulic governor would. The direction of rounding is specified by the specific mode ("Up" "Down" or "Nearest"), though if the input throttle % is already an exact value then no rounding happens.

For example, let's say we have this ThrottleRPMTab:

Engine (
    ORTSDieselEngines ( 1
        Diesel (
            ThrottleRPMTab (
                0.0         400
                25.0        600
                50.0        800
                75.0        1000
                100.0       1000
            )
        )
    )
)

If the throttle % is currently 40%, with the default behavior (SpeedControl ( "Continuous" )) the resulting engine RPM will interpolate between 600 RPM (the 25% throttle setting) and 800 RPM (the 50% throttle setting), giving 720 RPM. If the governor is electronic, it wouldn't actually be able to set 720 RPM. Instead, if SpeedControl ( "RoundDown" ) is added to the engine, the 40% throttle value will be "rounded down" to 25% (the next lowest or equal throttle setting in the table) and the RPM will be set to 600 RPM. Conversely, SpeedControl ( "RoundUp" ) would round the 40% throttle to 50%, giving 800 RPM. And SpeedControl ( "RoundNearest" ) would also round 40% up to 50%, as 40% is closer to that than to 25%.

Hopefully that makes sense. This isn't accurate for every locomotive, but it is accurate for some and can allow you to make smaller lookup tables instead of defining individual RPM values for every possible throttle setting.

Dynamic Brake Engine RPMs
Many diesel locomotives with dynamic braking will use engine RPM other than idle to provide extra cooling to the various parts of the transmission that are likely to get hot during dynamic braking. People have known this should be a thing for a long time, but ORTS previously considered engine RPM a function of throttle setting only. However, now with tractive effort disconnected from engine RPM, it is viable to change the engine RPM without causing trouble for tractive effort, so we can finally give engine speed during dynamic braking.

This is done with the DynamicsRPMTab in the engine definition, which behaves just like the ThrottleRPMTab but instead of using the throttle handle to set RPM, uses the dynamic brake handle. If a locomotive doesn't have dynamic brakes, then DynamicsRPMTab will not be used. And, of course, if the dynamic brakes are disabled then these RPMs will be ignored. DynamicsRPMTab works with SpeedControl too, which can be used to do rounding of the dynamic brake setting.

Engine (
    ORTSDieselEngines ( 1
        Diesel (
            SpeedControl ( "RoundDown" )
            ThrottleRPMTab (
                0.0     400
                25.0    600
                50.0    800
                75.0    1000
            )
            DynamicsRPMTab (
                0.0     400
                75.0    800
            )
        )
    )
)

In this example, dynamic braking keeps the engine at idle RPM of 400 until 75% dynamic braking is reached, at which point RPM will increase to 800 RPM and stay there up to 100% dynamic braking. Many other arrangements of engine RPM are possible, enter in as many dynamic brake and RPM values as needed to replicate whatever behavior your locomotive employs.

Fuel use will increase as RPM increases, but not to the same level as when powering thanks to the previously mentioned fuel consumption rework.

Now, one thing I'm not sure of is if this should be implemented automatically on MSTS locomotives. Right now, the only way to get dynamic brake engine RPMs is to add DynamicsRPMTab, which leaves the classic locomotives out there stuck with unrealistic behavior. The issue is, some sound sets fake dynamic brake RPMs, which would sound strange if stacked on top of the sounds of the engine actually revving up, and there are so many different styles of dynamic brake RPMs in real life that it might just make things less realistic to choose one style and apply it to every MSTS locomotive out there. A decent compromise would be to just use the same RPM as 50% throttle for all dynamic brake settings, as that was a typical way to do it on first generation locomotives, but that is entirely wrong for many other locomotives. Curious to see how people feel about backdating this feature.

Electric Train Supply Engine RPMs
Another commonly considered situation where something other than throttle affects engine RPM is locomotives with electric train supply. Many diesel passenger locomotives use a diesel engine to provide ETS power, but not without changing the RPM behavior of that engine (perhaps because the engine can't make sufficient power at its idle RPM, or a specific RPM is needed to produce a specific frequency of power). Previously, this would require a different engine file with a different diesel engine definition, but now ETSThrottleRPMTab and ETSDynamicsRPMTab can be added to a diesel engine to give correct behavior in both normal power and with ETS enabled.

Engine (
    ORTSDieselEngines ( 1
        Diesel (
            SpeedControl ( "RoundDown" )
            ThrottleRPMTab (
                0.0     400
                25.0    600
                50.0    800
                75.0    1000
            )
            DynamicsRPMTab (
                0.0     400
                75.0    800
            )
            ETSThrottleRPMTab (
                0.0     600
                50.0    800
                75.0    1000
            )
            ETSDynamicsRPMTab (
                0.0     600
                75.0    800
            )
        )
    )
)

In this example, with ETS enabled the engine RPM increases from a minimum of 400 to 600, which requires changes to both the throttle and dynamic brake RPM behavior. Obviously, ETSThrottleRPMTab and ETSDynamicsRPMTab will only be used if ETS is enabled for the locomotive. Note that if ETSDynamicsRPMTab is not defined, then the 0% throttle setting of ETSThrottleRPMTab will be used, even if DynamicsRPMTab is present.

Fuel use with ETS enabled will vary with the ETS load, which is added on to the auxiliary power draw and subtracted from the traction power.

Engines for ETS Only
Related to giving the proper RPM for ETS, some locomotives (or non-locomotive power cars) employ engines that only supply power for ETS and not for tractive effort (and vice versa). This can be controlled using the diesel engine parameters ProvidesTractionPower ( 0/1 ) and ProvidesETSPower ( 0/1 ) (both of these are set to 1 [enabled] by default). Disabling traction power means the engine performance will be unaffected by the tractive effort the locomotive applies, while disabling ETS power means the engine performance will be unaffected by the ETS draw from the coaches.

This can be combined with multiple engines to produce locomotives with a dedicated engine for traction and a small engine for ETS. In this case, the power draw from traction and ETS will not interfere with eachother, giving more accurate locomotive performance and fuel consumption for this type of locomotive than was possible before.

Engine (
    ORTSDieselEngines ( 2
        Diesel (
            ProvidesTractionPower ( 1 )
            ProvidesETSPower ( 0 )
            ThrottleRPMTab (
                0.0         400
                25.0        600
                50.0        800
                75.0        1000
                100.0       1000
            )
        )
        Diesel (
            ProvidesTractionPower ( 0 )
            ProvidesETSPower ( 1 )
            ETSThrottleRPMTab (
                0.0         1800
                100.0       1800
            )
        )
    )
)

Note that even if an engine does not provide ETS power, ETSThrottleRPMTab and ETSDynamicsRPMTab will still affect the RPM used. Delete those tables if you want the engine to truly ignore ETS.



Ok, those features are the highlights, but I ended up implementing a few smaller things to compliment the new capabilities, and give new opportunities for extra realistic engine operation:

More Control of Fuel Consumption
Now that fuel use varies with engine load, we need some way to define the fuel use at low load. DieselConsumptionTab defines the fuel used at full load perfectly well, but we can only estimate the fuel used at no-load from this. To get an exact value for low load fuel use, add the IdleDieselConsumption ( x ) parameter to your diesel engine to define the amount of fuel used per hour at idle RPM with no load. Accurate idle fuel use helps estimating friction, giving more accurate fuel use at all RPMs.

Auxiliary Power Draw
In a further effort to give more accurate fuel consumption, the power consumed by auxiliary systems (fans, battery chargers, lights, and such) can be defined versus RPM using AuxiliaryPowerTab in the diesel engine. This power is subtracted from the DieselPowerTab to determine the power available to the transmission (this means that DieselPowerTab should be the gross engine power, not the traction power).

Engine (
    ORTSDieselEngines ( 1
        Diesel (
            DieselPowerTab (
                400     20hp
                ...
                1000    2650hp
            )
            AuxiliaryPowerTab (
                400     20hp
                ...
                1000    150hp
            )
        )
    )
)

Note that the auxiliary draw listed here is always active and always contributing to fuel consumption, even if the engine is cold and in neutral. In reality, some of the biggest auxiliary loads (like cooling fans) are intermittent, but that isn't supported yet and will be a future thing. For now, approximate the average auxiliary load at each engine RPM. Note that ETS power is added on to auxiliary power in real time, so do NOT add ETS power to AuxiliaryPowerTab if you intend to use the full ETS simulation.

If AuxiliaryPowerTab is missing, it will be calculated automatically based on the DieselPowerTab and the traction power (calculated from the ORTSMaxTractiveForceCurves), but this may have limited accuracy. Any engine where the DieselPowerTab has been set to rail power instead of gross power will have 0 auxiliary power, limiting how accurate low load fuel consumption will be for such engines.

Transmission Efficiency
So far in Open Rails, the load on the engine has simply been the power at rail. In reality, the load on the engine is higher than the power at the rail and knowing this is also important for getting reasonable fuel consumption as the energy lost in the transmission represents extra fuel that had to be burnt. To consider efficiency, add ORTSDieselTransmissionEfficiency ( u ) to the Engine section of your locomotive. The value given should be 0-1, OR will throw out anything else.

If your diesel engine has been defined with DieselPowerTab set to use the rail power, then adding ORTSDieselTransmissionEfficiency will cause such an engine to become overloaded. DieselPowerTab should be changed to be gross shaft power, and the legacy MSTS parameter MaxPower should be set to the traction power.

Engine Inertia
The inertia of a combustion engine is a tricky thing, as it is very important to how responsive an engine seems, but is basically never measured or reported. For that reason, you probably won't be messing with the engine parameter ShaftInertia ( I ) (only accepts values in kg * m^2). Like all the engine parameters, if that's missing it will be estimated. In this case, inertia is estimated from the friction (which is estimated from idle fuel use) and the ChangeDownRPMpS. Increases in friction (idle fuel use) and RPM deceleration result in lower estimates for inertia, as friction naturally slows the engine and a lighter engine will slow faster. This estimate can then be fine-tuned using the ShaftInertia parameter-just look in the log file with "verbose eng/wag configuration messages" enabled, and the friction estimate will be reported somewhere in there.

More inertia means that the engine has to make more power and burn more fuel to increase in RPMs, so if you see suspiciously high fuel use and/or power output use when RPM is increasing, that indicates that the inertia might be too high. Though also consider that high inertia leads to a greater drop in power and fuel required when the engine is decelerating (enough so that power may go negative, as friction drains energy from the engine faster than fuel is adding energy).

Missing Parameters, Found
There were some bits of data that the diesel engines used but for some reason was missing a way to enter it in, so I took a moment to add those.

• IdleExhaustMagnitude ( x ) - the lifespan of exhaust particles when the engine is at the idle RPM, measured in seconds by default
• MaxExhaustMagnitude ( x ) - the lifespan of exhaust particles when the engine is at max RPM, measured in seconds by default
• ExhaustDecelColor ( aarrggbb ) - the color of ehxaust particles when the engine RPM is reducing

I hope all this is useful and mostly trouble free. Opening up the engine RPM so that it can do whatever without affecting traction and while still giving reasonable fuel consumption opens up a lot of other opportunities too, but if it's not clear, there's already quite a bit that had to be done to get dynamic brakes and ETS affecting engine RPM in an accurate way. Those other opportunities will have to wait a bit, I'll be out of town anyway, but it should be easier to continue adding to the list of things engine RPM can do.

[generalpalmer]

This is excellent work. Thank you for your efforts. I will enjoy testing these features. Are there any plans to implement "low idle" with associated drop in RPM and fuel consumption when the reverser is centered?

[pschlik]

With the behind the scenes changes, low idle is technically possible and you would see a reasonable drop in fuel consumption (assuming the fuel consumption parameters are entered in properly, of course). The only thing to do is to change the code to tell the engine RPM setting, and that is the complicated part.

The thing with low idle is that it isn't actually as simple as setting the idle RPM to X when the reverser is at Z, a lot of locomotives with low idle behavior include more complicated checks like timers (if someone leaves the reverser in gear at idle for long enough that they are clearly waiting on something, use low idle anyway) and engine temperature (engine could cool off in low idle due to the lower fuel use, don't want it to get so cold that you lock something up when trying to power up again).

Basically, it's not going to be very accurate without a more flexible system. But a more flexible system also doesn't have to be limited to low idle. Ideally, one system would allow for high idle, compressor speed up, extreme temperature load limiting, turbocharger bootstrapping, auto start/stop, and on and on. It's a lot easier to make one generic thing that can be customized to create a wide variety of behaviors than to foolishly attempt to manually implement all of those behaviors as individual features.

I have a spec for this, but I haven't made it yet since it will be pretty complicated and this set of features is already complicated on its own. Also, I'll be out of town for the next 2 weeks so I wouldn't and don't have the time to set that up, and I'd rather get out the things I have finished before then. So, something like that will come next. Whenever "next" is.

[Erick_Cantu]

Oh, this is awesome. I've been holding off on several audio ideas due to not wanting to deal with RPM issues. The last 645 package had something like 128 SMS files due to dynamic braking and horn variations. Now if we could just remove the two SMS limit per locomotive to separate the horns/bells/cab equipment from the engine...

[pschlik]

Multiple sms files might not be that hard to set up. Under the hood, it's best to just have 1 sound source at a time, but what exists as multiple sound sets on the hard drive could be combined to function as one single set in memory. Each sms file is just a bunch of streams, so it's not crazy to just combine the list of streams (read the sms files separately, add the list of streams from the additional sms files to the list of streams already present, done). There could be some subtle limitations, like the scalability groups probably need to be ignored for any additional sms files, but that's not a hugely consequential thing. This is more related to the sound features, of course. But that change is still in testing so it's not too late to add to it.

[Erick_Cantu]

That would be neat - imagine having one folder full of all of the cab/horn/bell SMS options, then a single SMS file for each engine type. Queue them into the ENG file, treat them as a single composite SMS (sort of like we do with include files in physics) at runtime, and Bob's your uncle. You'd be able to swap horns, cab equipment, and so on with a few quick text edits.

[pschlik]

Heads up, ORTSTransmissionEfficiency has been renamed to ORTSDieselTransmissionEfficiency. This parameter only applies to diesel locomotives (though the type of transmission doesn't matter). In the future, we could consider the efficiency of things like electric motors for electric locomotives and diesel-electrics (in which case, motor efficiency would stack with transmission efficiency).

As a bonus though, the old MSTS MaxPower parameter now considers the power before transmission losses, so you can punch in MaxPower ( 3000hp ) directly, instead of needing to do some calculating to figure out what the rail power should be and entering that in (this also results in horsepower per ton calculations closer to what you expect). Of course, don't forget to combine that with, say, ORTSDieselTransmissionEfficiency ( 0.86 ) and OR will do the math itself to produce the proper rail power output. (Of course, if you have ORTSMaxTractiveForceCurves then the rail power is defined by those instead, no need to manually specify ORTSDieselTransmissionEfficiency in that case.)

[dcarleton]

...the old MSTS MaxPower parameter now considers the power before transmission losses...

When was this change implemented? Is this something recent?

[pschlik]

This was added yesterday, hence me posting about it then.

Everything will behave exactly the same as before unless you add new data like the transmission efficiency, as the transmission is assumed to be 100% efficient unless specified otherwise.

[dcarleton]

Thanks for the clarification. I've been going through the psc.inc files and implementing that method wherever appropriate.

[pschlik]

Right, in the physics files you'll see that all MaxPower values are all rail power, so they are lower than the rated power (like MaxPower ( 2590hp ) for the SD40-2 physics). In this update, you can put MaxPower ( 3000hp ) into the SD40-2 physics and that will help make diesel engine performance more realistic (the rail power will still be 2590hp despite changing MaxPower because rail power is determined by the ORTSMaxTractiveForceCurves-note that this means OR doesn't need ORTSDieselTransmissionEfficiency, it already has enough data to figure that out automatically). You can repeat that for all the locomotive types in the physics set, using the manufacturer's power rating as MaxPower.

I'll update my things (not just with the proper power values, but also with dynamic brake RPMs and so on) when the code is done, and that would be included with a mod update for version 1.7, whenever that happens.

[pschlik]

This feature set is now available in testing versions and will eventually be part of the stable 1.7 release.