[steamer_ctn]

#3530 has been committed which now includes the first phase for setting up potential wheel skid with braking.

This first patch implements the variation of brakeshoe friction due to speed (hence the braking force on the wagon will also vary with speed). For some background reading see this page.

As indicated on the diagram on the reference page, a default curve approximating a cast iron brake shoe is used by OR to vary the friction with speed.

It should be noted that the MaxBrakeForce parameter is (and has always been) the actual force applied to the wheel after reduction by the friction coefficient.

The patch supports the following three modes of operation:
i) Advanced Adhesion not selected - brake force operates as per previous OR functionality, i.e. - constant brake force regardless of speed.
ii) Advanced Adhesion selected and legacy WAG files or NO additional user friction data defined in WAG file - OR assumes the users assigned friction coefficient, and reverse engineers the braking force, and then applies the default friction curve as the speed varies.
iii) Advanced Adhesion selected and additional user friction data HAS been defined in WAG file - OR applies the user defined friction/speed curve.

Option iii) is the recommended method of operating, and naturally will require include files, or variations to the WAG file.

To setup the WAG file, the following changes will need to be made:
i) use the new OR parameter ORTSBrakeShoeFriction ( x, y ) to define an appropriate friction/speed curve. This parameter needs to be included in the WAG file near the section defining the brakes. This parameter allows the user to customise to any brake type.
ii) Define the MaxBrakeForce value with a friction value equal to the zero speed value of the above curve.

See the reference page for an example of how the code is configured in the WAG file.

The FORCES INFORMATION HUD has been modified by the addition of two extra columns:
i) Brk. Frict. - column shows the current friction value of the brakeshoe and will vary according to the speed. (Applies to modes ii) and iii) above). In mode i) it will show friction constant at 100%, which indicates that the MaxBrakeForce defined in the WAG file is being used without alteration, ie it is constant regardless of the speed.
ii) Brk. Slide - added in preparation for next phase and will indicate whether the car wheels are sliding under brake application.

It should be noted that the "Adhesion factor correction" slider will vary the brakeshoe coefficient above and below 100% (or unity). It is recommended that this is set @ 100%.

These changes will add an extra challenge to train braking, but provide a more realistic train operation.

For example, in a lot of normal Westinghouse brake systems, a minimum pressure reduction was applied when moving the brake controller to the LAP position. This is catered for with the MSTS parameter, TrainBrakesControllerMinPressureReduction. Typically Westinghouse recommended values of between 7 and 10 psi. This feature does not appear to be implemented in OR. so when applying the brakes initially, especially at speed, it maybe worthwhile to drop the BP pressure by 7 psi straight away. Previously it was not easily possible to follow this approach as too much brake force was applied at speed, which stopped the train too quickly.

[disc]

What is the default friction curve? BTW i still think that another parameter with values like "disc", "tread" would be useful, as most of the developers don't have friction curves, but the curves of the same brake type is usually the same, so the same curves would be included in all wag files.

[Coolhand101]

I have waited a very long time for this. There were workarounds in MSTS to allow different braking curves versus speed.
All I can say is very well done.
Thanks

[copperpen]

One of the best items to be developed so far. Using the full version is a step change in train handling. Well done Peter.

[Genma Saotome]

Cool.

Any chance of addressing real buff and draft forces? It would add run-in effects with braking (which could cause skidding and possibly jack-knifing and/or string-lining cars). It would also lay the groundwork for a new multi-player feature: different people tying to manage a train w/ helpers.

[steamer_ctn]

disc, on 25 April 2016 - 06:11 AM, said:

What is the default friction curve?

I am not sure what you mean?

The curve shape, and values are shown in the reference diagram referred to in the above post.

disc, on 25 April 2016 - 06:11 AM, said:

BTW i still think that another parameter with values like "disc", "tread" would be useful, as most of the developers don't have friction curves, but the curves of the same brake type is usually the same, so the same curves would be included in all wag files.

I considered this approach, but felt that this would only complicate things from a coding and model development perspective.

The use of the ORTSBrakeShoeFriction ( x, y ) allows model developers the flexibility to customise the brake friction to any brake type.

In regard to developers not having access to friction curves, information is available on the internet, or alternatively I am happy to host some standard curves that could be cut and pasted into relevant WAG or include files, if people have suitable curves to share.

Genma Saotome, on 25 April 2016 - 12:08 PM, said:

Any chance of addressing real buff and draft forces? It would add run-in effects with braking (which could cause skidding and possibly jack-knifing and/or string-lining cars). It would also lay the groundwork for a new multi-player feature: different people tying to manage a train w/ helpers.

This will probably require a lot more research, so I suspect, to quote Star wars, that it is probably in a a galaxy far far away.

[ATW]

Run in forces an limits could be same approach as coupler stretch limits as a start for buff loading. There is a MSTS parameter that can simply be used for it.

[steamer_ctn]

The wheel skid functionality has been added in #3534.

This feature will identify if a wagon wheel is locked, and started to skid. The braking force will drop, and the train will slide for a significant distance. If a skid condition is encountered, then the brakes need to be released until the wheel starts to rotate again.

Diesel and electric locomotives are excluded from this function at the moment as they appear to be covered in the original base advanced adhesion model.

The main parameters that will influence a wagons ability to skid are the following:

• Force applied to the brakeshoe
• brakeshoe friction
• weight of the wagon
• wheel/rail friction

To test the concept, a test set of wagons can be defined with light loads, and high brake forces.

[ATW]

I am use to my locomotives sliding under some conditions like heavy dynamic braking in the snow at there most effective speeds like before an like the wheel slides on them but I have a question. Are the WAG cars supposed to slide an show its effects too with sliding animations or even a less rotation in movement because I got cars to slide but animations don't show it an it makes them rotate like normal?

[steamer_ctn]

ATW, on 27 April 2016 - 10:21 PM, said:

I am use to my locomotives sliding under some conditions like heavy dynamic braking in the snow at there most effective speeds like before but I have a question. Are the WAG cars supposed to slide an show its effects too with sliding animations or even a less rotation in movement because I got cars to slide but animations don't show it an it makes them rotate like normal?

I am still try to work out the code for the animation. Hopefully that will be the next component added.

[ATW]

Ok cool. Maybe slipping it in with the same wheel animation from locomotives but to un powered WAG?

[disc]

Bug: reversed wagons have negative braking friction, which rises as the speed falls, and so the braking force disappears completely.

[Genma Saotome]

Quote

Quote

Any chance of addressing real buff and draft forces? It would add run-in effects with braking (which could cause skidding and possibly jack-knifing and/or string-lining cars). It would also lay the groundwork for a new multi-player feature: different people tying to manage a train w/ helpers.

This will probably require a lot more research, so I suspect, to quote Star wars, that it is probably in a a galaxy far far away.

My gut tells me it shouldn't be that hard to try out but the implications of having it as a feature are hard to tell.

Basically a solution would involve identifying subsets of a train where each set is composed of those cars that have an adjacent car in a full draft or full buff relationship. "Full" could mean 100% to either end of the draft gear movement... or for practical purposes, maybe a bit less. The sets, having no slack within should move as a solid unit WRT the train. The relationship between sets represent what is called a node. A train going up or down a grade will soon reach a state where it has no nodes (absent helpers) and so is represented by one set. To create a node one has to change the power output so the acceleration (or deceleration) causes as change of state at some coupler pair. The location of a node or nodes will change depending on both train handling, terrain, and the presence or absence of helpers.

As for what the feature might do... seems likely to change train handling behavior on long trains, especially when they start; It could be an enabler for a train surge against the locomotive on a big run-in; Plausibly it should dynamically change the load the locomotive is pulling; A big run-in on some empty cars could cause a jackknife; Last, it doesn't appear to me that the total length of our trains vary as they should and so perhaps this might help address that too.

[ATW]

I agree with Dave.

I feel it won't be so hard as the current run out coupler Break code can be used as template but in opposite force triggers being bunched instead of stretched. If bunched break coupler forces can't use a part of the coupler settings "Break( 2nd space value)" there is always those 2 MSTS parameters that can be the trigger limits to code an target.

They come of no known use in ORTS yet but are present in almost every file:

DerailRailForce ( 2.5N/kg*23t )<---Implement to use for how much ton force opposing cars are against where coupling speed limits from derailing may be of no use like MSTS default.wag but by run in mass an speed is against opposing cars bunch forces an limits.

DerailBufferForce ( 900kN )<-------Implement to use for bunched run-in coupler/hose Break push limit disciplines.

[Mike B]

Back in the v. 0.9 era, the F5 HUD in the X builds would display slack as 0-100% for the train, and state "bunched" at 0 and "stretched" at 100. That seems to have vanished at 1.0 & later, and I'm not sure how (if it's even possible) to get it back. If that code is still around somewhere, it might be used for what Dave's asking for.