[Weter]

Hmm...
I understand Your words, Phillip, in such way, that the phenomenon, we see, isn't an ORTS bug at all, but an expected result of tractive force curves lack in *.eng-files, right?
Then, let's think about possible addition of some check (in analogy with missing steam parameters case), when ORTS runactivity would read obsolete max velocity parameter and apply some default speed limitation (logging this action for user to be aware)...
There are friction and aerodynamic (latter grows in quadratic progression with speed) resistance, which never allow locomotive with "saturated-state" electric transmission to reach 300km/h

[joe_star]

pschlik, on 10 April 2024 - 12:21 PM, said:

I recommend being careful with the ORTSUnloadingSpeed and not using it randomly, it is not a suitable simulation of a locomotive overspeed sensor. It should specifically be used only when you know the locomotive in question hits a voltage limit at speed, which would show up on tractive effort curves as a deviation below the constant horsepower curve at high speed. This will not be true for all locomotives, some generators are beefy enough or engines weak enough that they won't reach maximum voltage even when the locomotive is at max speed. For example, I know for sure that the GP40-2 reaches maximum voltage at 60 mph, but the SD40-2 won't be at max voltage even at 65 mph because real data indicates as such.

I also disagree with the implementation of ORTSUnloadingSpeed, as a linear decrease in power output toward 0 is not what happens in real life. When considering series wound motors given a constant voltage (in this case, the max generator voltage) the power output has a sort of exponential decay as speed increases, never actually reaching 0 power output no matter how fast the motor spins. This means a series wound motor will gladly explode itself when given even fairly low voltages under no-load, and is why series wound motors aren't very popular outside industrial applications.

The real solution here is to make custom tractive effort curves that implement whatever high speed behavior you want using real data, rather than approximations bolted on top of MSTS-era physics.

Correct. The decay is exponential. The critical speed or unloading speed can usually be found in locomotive tractive effort charts

https://i.ibb.co/HxdYnVp/978-1-4419-0851-3-20-Part-Fig13-800-HTML.png

I suggested using 60-70% as above as this allows MSTS defined locomotives to achieve what their "MaxVelocity" at which point the power balances out with friction forces, within the current implementation (which I also agree is inadequate)

In the current OR implementation, MSTS defined locomotives are essentially unlimited in their speed capabilities especially when running single or with a light load, because no reference to limiting the power output at MaxVelocity is defined anymore. Ideally we should still have an absolute check on MaxVelocity that cuts the power output (representative of some form of speed control)

Quote

The real solution here is to make custom tractive effort curves that implement whatever high speed behavior you want using real data, rather than approximations bolted on top of MSTS-era physics.

That's a solution that abandons MSTS compatibility though, and impacts a huge collection of MSTS locomotives (the Indian railways content I use is pretty much entirely defined with only MSTS parameters)