Dynamic break floating

[rodrigoville]

Hi friends! Could you please help for the following issue?,

I notice that when I use the dynamic break this is floating.

when I apply notch 1, or two or whatever the dynamic sounds like if I were moving from one notch to another one? Like going up and down... No stable

I will appreciate your help!

Thanks!


Enviado desde mi iPhone utilizando Tapatalk

[UP_4848_Thunder]

Is there a difference in sound possibly because of what speed is reached? Meaning are you experiencing this at high or low speeds from most effective speed range?

What engine is it an what are the dynamic settings in the eng file?

[rodrigoville]

Dynamic break floating



I am using the BNSF ES44AC from streamlines, and I notice that is more common during low speed, as reference I am using rail driver (does it could affect??)

I will appreciate your help

Enviado desde mi iPhone utilizando Tapatalk

[UP_4848_Thunder]

Shouldn't be those Notch settings but the brake curve an force settings. Do you have what the force speed settings are above from that in the section blocks of where "DynamicBrakesMaximumForce( )" is?

Not quite done with a ongoing file project for Dynamic braking systems of many kinds for use in both MSTS/ORTS. But you can try these out by copying un bolded sections an pasting over old after backup of eng file. ORTS Only sections if deciding to use must use one system in decision of Flat or Taper an be pasted on top of line "Description (" an will not use MSTS sections of dynamic braking if used instead:

GE C60AC; C6044AC; ES44AC; ES44AH;
AC60CW-ES44AC Extended High Capacity: CP, CN, CSX, BNSF, NS, KCS, UP etc

MSTS & ORTS Flat System


DynamicBrakesMinUsableSpeed( 2.01 )
DynamicBrakesMaximumEffectiveSpeed( 26.6 )
DynamicBrakesMaximumForce( 520.4kN )
DynamicBrakesResistorCurrentLimit ( 1200 )
DynamicBrakesCutInSpeed( 6.03 )
DynamicBrakesMaxAirBrakePressure ( 50 )
DynamicBrakesFadingSpeed( 6.03 )
DynamicBrakesDelayTimeBeforeEngaging ( 8 )
DynamicBrakesMaximumSpeedForFadeOut ( 108.5 )
DynamicBrakesEffectAtMaximumFadeOut( 0 )
DynamicBrakesNumberOfControllerNotches( 1 )
DynamicBrakeHasAutoBailOff( 1 )


ORTS Only Flat System

ORTSDynamicBrakeForceCurves (
0 ( 0 0 50 0 )
1 (
0 0
0.89 311375.51
2.68 520441.95
5.36 520441.95
10.28 520441.95
22.35 257996.85
)
)
ORTS Only Taper System

ORTSDynamicBrakeForceCurves (
0 ( 0 0 50 0 )
0.4444 (
0 0
0.89 311375.51
2.68 520441.95
5.36 520441.95
10.28 520441.95
22.35 257996.85
)
1 (
0 0
0.89 311375.51
2.68 520441.95
5.36 520441.95
10.28 520441.95
22.35 257996.85
)
)

[geepster775]

I don't know where the engine files that the OP showed are coming from, but I keep a folder with a copy of all payware in unzipped state, as-is, straight out of the box, just for reference reasons like this, and I cannot find any 10 notch dynamic brake code in any SLI-supplied BNSF Gevo eng file.

That being said, I ran parallel tests on 2 PC systems, one a win 8.1, the other XP, using the same version of open rails X3288, The test was on the Scenic 2 route, using the same consist file on both machines. As part of the test, I used an SLI default path starting at Berne on the 2.1% grade, going through the tunnel, and down the grade into Skykomish. And suffice it to say I got alot more wheel-slip action on the XP machine. An incredible amount, really.

In this test, when I stated on the grade at Berne, you pretty much have to apply some throttle to lean on the train to keep it from rolling away backwards on you as the train brakes slowly come off. With 4 SLI Gevos, I could not get a 2800 ton train started on the 2.1% grade at Berne. Incredible wheel-slip until the lead unit's brake cylinders dropped to 0 well after the cylinder pressure in the rest of the train had dropped to 0. Then I could finally get it going no faster than 18-24 mph without getting more wheel slip. My speedo needle just kept bouncing up and down between 19-ish and 24-ish MPH. Nursed it though the tunnel and onto the downgrade. Once on the downgrade, any amount of braking effort that put pressure in the lead unit's brake cylinders, and I would start getting the wheel-slip buzzer again while going downhill.

Hopped on over to the 8.1 box, and the run was smoother. Yes, I was able to lean on the train with significantly less slippage. And I was able to take off and get speeds well above 30 mph going upgrade. No dancing speedo needle. In fact, I found it very hard to get any excessive amount of slippage starting from a dead stop.

How does one explain such variances in behavior when running the same OR version, same route, same consist on two different PC operating systems. Are we now adding adhesion related code that is not at all friendly to older PC hardware and OS'es? No real knowledge on how old the OP's system is, nothing is ever said.

[baldwin]

I don't think it is much to do with the operating systems, more to do with the hardware it is running on. The only way to prove that theory is to have two identical machines, one running XP and one running Win 8.1. If the XP machine only has a single core cpu and an older video card, and the Win 8.1 has a multi-core cpu and a more up to date video card the XP machine will perform worse than the 8.1 machine.

[geepster775]

On the older hardware, I've found that simply changing the camera view from the in-cab 1 view to the rear 3 view, which adds the graphical overhead of the rear cars on the train, will send the train into excessive wheelslip mode. I'm running fine in view 1, hit the 3 key, and immediately get bombarded with wheel slip messages after the 3 view paints in. I can understand if frame rates take a hit, but the altered operating physics is a new experience.

And in defense, the XP box is within the minimum specs stated on the open rails website for Ver 1.0. So either new code being added to the X versions is not universally tight, or new code being added had abandoned those published minimum hardware specs.

I only add this entire test as a FWIW. And this type of altered physics behavior I'm seeing is somewhat consistent to the OP's plight. I guess we are going to start seeing flaky stuff happening on older desktop hardware or the more flimsy laptops. Or maybe its time to revise minimum specs.

[baldwin]

I think that OR has probably reached the point where older and weaker computers will have to run OR with reduced settings, much like MSTS when it was first released. The biggest hit in OR is large view distances, accompanied by high numbers of scenic items that have excessive draw calls.