[Jean-Paul]

Hello,
Two problems appearing with X 3936 (but also with unstable version X3933).
1 - Under 1280 x 1024 screen resolution, some cabviews are straightened (see files)
2 - Dynamic brakes, which functioned perfectly with X3919, are totally erratic with X3936 (also with X3933). Applied force is out of proportion with .eng values (for instance, 165kN for 25 % DB intensity, vs a max force defined as 90 kN). Wheelslip occurs, and DB are unusable.
Thank you for your help.
Jean-Paul

PS : I use specific Openrail file for "ORTSMaxTractiveForceCurves". Is it possible to add in the same OReng file "ORTSDynamicBrakesCurve" or something similar ? It would resolve very easily those difficulties, I think

Attached thumbnail(s)

• 
• 

[Csantucci]

Can you provide a link for trainset and cab showing these problems? Are the screenshots taken in full screen or windowed mode?

[Jean-Paul]

Hi Carlos,
Both views are screenshots, taken in full screen. I send you a sample of .eng file showing the problem of dynamic brakes with X3936. Everything was correct with X3919. Notice that an almost similar cab (the one I sent last week in my post about X3931) doesn't have the problem, but fits a Diesel engine. Incriminated cab fits an electric one (resp. french CC72000-Diesel & CC6500-electric)
Best regards,
Jean-Paul

Attached File(s)

•  BB25204_CC.eng (39.06K)
  Number of downloads: 245

[Csantucci]

Hi Jean-Paul,
for the cabview problem I need at least the cabview front .ace file.

[Jean-Paul]

Csantucci, on 02 September 2017 - 10:41 AM, said:

Hi Jean-Paul,
for the cabview problem I need at least the cabview front .ace file.

Sorry !
I send it !
Thanks,
Jean-Paul
Important !! With your help, I found the solution : Front view was 1024 x 1024. So, I resized this view in a 4:3 format (1024x768), and also resized transparency template. And cabview is OK. It seems (don't smile, I'm not a specialist ! :D) that recent modifications are "allergic" to non-4:3 files, whilst there was no problem before with "square" formats.

Attached thumbnail(s)

• 

[Csantucci]

OK. It's not the problem of OR being allergic: OR now maintains the proportions of the .ace file. As it can be seen in your last picture, the horizontal axis is squeezed already in the .ace file, and the same you will see at runtime. So .ace files can have any dimension, but the picture they represent must not be squeezed in one of the two directions. This way OR can accept .ace files that are "native" in any aspect ratio.

[Jean-Paul]

Csantucci, on 02 September 2017 - 12:11 PM, said:

OK. It's not the problem of OR being allergic: OR now maintains the proportions of the .ace file. As it can be seen in your last picture, the horizontal axis is squeezed already in the .ace file, and the same you will see at runtime. So .ace files can have any dimension, but the picture they represent must not be squeezed in one of the two directions. This way OR can accept .ace files that are "native" in any aspect ratio.

Allright ! More funny is the fact that... It's a commercial cab ! And that my reskin didn't show this default :-) But, if I remember, I didn't use the same windows, so, when I adapted the panel, I think I had to resize it and also eliminate this distorsion.
Thank you for your help !
I come back to the dynamic brakes problem. Knowing that many dynamic brakes have not a linear intensity profile, won't it be convenient to allow a definition of a curve profile, similar to those I (we ?) use with profit for traction parameters ? Must say that ability of OR to fit with non-linear variations of tractive effort seems to me to be a great progress for more realism in driving electric or diesel engines, particularly those using a "graduator" system. So, why not with rheostatic brakes ? ;-)
Thak you again !
Jean-Paul

[Csantucci]

With x.3939 the problem of the dynamic braking of the BB25204_CC has been solved.
I put the attention to the fact that there are two errors in the .eng file that you have attached: DynamicBrakesFadingSpeed is set higher than DynamicBrakesMaximumEffectiveSpeed, while the MSTS documentation (both MSTS original and Realmuto's manual) affirms it must be the opposite. As I found this error also in another trainset, now OR checks whether the first speed is lower than the second one, and if not the speeds are swapped.
The second error refers to MaxForce and MaxContinuousForce, that are both set to 1200 kN; this seemed definitely too high to me, so I searched on the internet and found this http://fbrisou.free....icheBB25200.pdf , where the max tractive force under CC is 175 kN.

Re your request for dynamic brake force curves, the code foresees that (I haven't tested whether it works): you can define a table under OrtsDynamicBrakeForceCurves, like you can define one for the tractive force. If you find out that this doesn't work I'll have a look.

[Jean-Paul]

Hi Carlos,
Thank you for your help !
About Max Tractive Force, I use specific OR Curves with dedicated file. Each notch of throttle is related to specific values depending on speed, like OR allows to do it. That's the best way to obtain a power/tractive effort as similar as possible to the reality.
So, I know that continuous tractive effort of BB25200 is around 178 kN, but it's only the value in which intensity and voltage may be indefinitly maintained. But, in theory, maximal force for an electric (continuous/direct) motor is greatly higher when speed decreases to zero, because its torque aims mathematically to infinite. That's the reason why traditional electric locomotives were fitted with resistances to avoid a too high effort when starting. I send you corresponding OR file "BB25204_CC.eng", if you're interested in this modelization. You'll see that power is always below the maximum of 3400 kW, and that variations are, like in reality, non-linear (non-shunted notches have a rapid decrease of effort with speed; shunted notches are less effective at low speed, but allow to maintain power at high speed). It works wonderfully well with OR, and justifies the necessity to choose adequate notch, with the risk of an epic sliping episode if the notch is too high, like in reality. Look at real tractive effort curves, and you'll see they tend to infinite when speed tends towards zero.
I must say that this "improvement" works very well with OR, which reproduces with reliability the non-linearity of curves. Of course, with very modern engines fitted with asynchron motors, this sophistication is unuseful, but driving is much more annoying, even if realistic ! ;-)
I'll try DB with X3939, and thank you very much for your help !
If you wish more details, send me a mail !
Cheers,
Jean-Paul

Attached File(s)

•  BB25204_CC.eng (13.63K)
  Number of downloads: 264

[Jean-Paul]

Hi Carlos,
Just to thank you again : I have tried X3939 by adding ORTSDynamicBrakeForceCurves (and they are "complex" with BB25200), and, owing to you, it works perfectly ! :sign_thanks: So, I'm happy !
Cheers !
Jean-Paul