[Weter]

AFAIK, Cesar have started (or even already made) this functionality available.
IRL, it's present on some trams and EMU since 1970 onwards.

[cesarbl]

Yes, this is a feature that has to be implemented at the Train Control System script. I implemented it for the Spanish TCSs, but it should be straightforward to add it also for other countries' TCSs. It could be implemented also for the default TCS, in the same way as DoesBrakeCutsPower().
For TCS scripts, it is just as simple as modifying the SetTractionAuthorization() function call to:

SetTractionAuthorization(CurrentDoorState(DoorSide.Both) != DoorState.Closed && otherConditions);

(with otherConditions being the rest of conditions that cut off traction)
This will prevent traction from being applied while doors are open.

[Laci1959]

Hello.

I asked a train driver. The Stadler FLIRT and KISS locomotives have a control ban. That is, the throttle switch does not work.
The brake can be released when the door is open, I think this is what is needed for moving in the workshop.

Sincerely, Laci1959

[Traindude]

Not sure if this is relevant to the discussion, but I'd like to bring up operations with "unfitted" UK freight trains. It is customary for unfitted freight trains to stop at the crest of a hill to "pin down" their handbrakes. However, ORTS' default handbrake logic of "off or set" seems to contradict reality.:

http://www.igg.org.uk/rail/4-rstock/sv3fd3g8.jpg

This illustration from the Goods and Not So Goods website demonstrates that the handbrake lever has multiple notches, allowing variable application of the handbrakes. Although theoretically one could use the new "Manual Braking" function to simulate this, it's not very realistic. Both MSTS and ORTS (in its current state) seem to ignore the NumberOfHandbrakeLeverSteps( x ) parameter entirely.

Does anyone else agree that we need variable-strength handbrakes?

[darwins]

As far as I know the main reason for the notches is to take up wear. For all practical purposes the brakes were either 'on' or 'off'. The application procedure was basically put two hands and full body weight on the lever, push it as far down as you can and put the pin in to keep it there.
To adjust the brake force depending on the load gradient and weather different numbers of wagon brakes, or all of them might be applied. Sometimes the number of brakes to be pinned down was specified, but normally this was left up to the train crew.
https://i.imgur.com/cJw93ei.jpg

[Weter]

Very interesting info, thanks.
Here we use to see screw drive of handbrake, propelled by steering wheel.
In old trams and metro cars, there was a pedal, I guess, for fixing screw against self-loosing.

[Traindude]

Another UK-related brake question, in particular sound triggers.

I have tried retrofitting some of the CTN UK steam locomotives, and their associated rolling stock, with a brake squeal audio stream. I discovered that vacuum brakes are the opposite of air brakes as far as the "BrakeCyl" variable trigger goes. On an air-braked locomotive, the brake cylinder pressure increases during application and decreases during release, but on a vacuum-braked locomotive, the cylinder pressure decreases during application and increases during release.

That sounds straightforward enough, simply invert any "BrakeCyl"-related variable triggers and curves.

But what do you do if a locomotive has a vacuum brake for its train brake and a steam brake for its engine brake, like the CTN Merchant Navy Pacific (the Southern version)? Well, when I coded the brake squeal stream for vacuum brakes (decrease during application, increase during release), it would cause the brake squeal to be heard whenever the engine (steam) brake was in the release (0%) position.

So there needs to be a way for *.sms files to tell the difference between vacuum, air and steam in regards to the "BrakeCyl" variable.

Also, is there any discrete trigger related to handbrakes? I can't seem to find one in the spreadsheet on the CTN website.

[cesarbl]

Quote

Given that there is now a way for rail vehicles other than the player-controlled one to increase or decrease the brake pipe, could we please for the love of railroading make it such that DP units apply and release the train brakes in sync with the player locomotive? The relatively new DP features are fantastic, but the fact that DP units can apply and release brakes is a massive factor in their real-life popularity. Not having this ability in OR is a serious loss.

I'll think about it. If DP units just follow EQ as you say it's pretty straightforward.

Quote

Emergency dump valves are great to have, really picks up the pace on emergency applications. BUT I have been completely unable to recover from an emergency application without cheating after implementing the vent valve simulation. I looked at the code and it seems to me that there was no code to reset the dump valve, so once the brake valve goes into emergency, it is impossible to recover! This is a major oversight and makes this feature gamebreaking.

You're completely right here. Two people asked for this but I never got feedback about it. There is indeed a reset condition (BP increasing), but it cannot obviously trigger if the valve is venting air.

Quote

In real life, when the dump valve is activated it will remain open for 2 minutes and then automatically close. This will not cause the brakes to release, but it does allow for the brake pipe to be recharged (and thus, ultimately to release the brakes). Why 2 minutes? This is assumed to be a long enough time that the train should have come to a stop, as it would be unsafe to recharge the brake pipe while in motion after an emergency application.

Absolutely thanks for this information. Is this a standard feature, or do some valves reset when they detect a low BP pressure (e.g. below 1 psi)?

Quote

The addition of this feature also reveals a weakness in other brake systems: we need to make anglecocks gradually open. The current implementation where anglecocks instantly open can easily result in an undesired emergency application when coupling to a train with empty air. In real life, this can happen too, but is avoided by gradually opening anglecocks. Gradually opening the valve slows down the flow of air enough to prevent an emergency application.

This would require some graphical modifications too, which are not my most liked area. However the recent F9 proposal looks pretty good, so I could even try to do it myself.

Quote

Also, could we please get a sound trigger for the vent valve opening? Multiple sound sets for US trains have sound cues for emergency brakes (in the form of a loud pop due to air escaping from the vent valve) but have had to bodge this by making the sound activate at certain brake cylinder pressures, rather than activating the moment an emergency application happens.

I'll look at it.

Quote

The addition of the CompressorIsMUControlled token is...interesting. As it stands right now, the compressors already synchronize on directly connected units without this token, which is accurate behavior. But, with the addition of this token, the compressor will be synchronized for all units, even DPU. This is not accurate as the compressor sync signal is only sent over MU cables, not over DP. (This makes sense from a design standpoint as the main reservoir hoses are only connected between locomotives of the same multiple unit, but are not connected all the way to the DPUs.)

Is this intended to represent a system other than what's used in the US? If so, that's fine, the original behavior is perfectly fine. If this is meant to represent the US system, it's wrong.

If the default works for DP units, please use it. This feature was intended to be used for European MUs where there are passenger cars between locomotives (so not directly attached), but their compressors are synchronized (as the rest of MU signals). Also, I don't think that "the compressor will be synchronized for all units, even DPU", since I am explicitly checking that the locomotive is in RemoteControlGroup == 0 (MUed units).

Quote

Having the ORTSDynamicBrakesHasPartialBailOff token has the potential to be a real lifesaver, the previous blended brake implementation left a lot to be desired and I think what's planned here may be able to do a much better job at creating the sort of behavior I'd expect from blended braking. Still has some very very weird bugs though.

Nice work making the blended braking automatically shut off when the train stops and making bail-off kill blended braking. Those two ways to shut off blended braking are important and I've seen some sims forget about those features.
I observed some very weird oscillations in brake cylinder pressure, where it would alternate between 0 psi and whatever pressure would be in the brake cylinder if there were no braking (so a bit over 70 psi in my case) every other frame. This was happening even when I paused the game. I cannot fathom what is going on here that would allow the brake cylinder pressure to change literally instantly. I can try to get a video if this can't be reproduced.
I also didn't see the sort of smooth changes in brake cylinder pressure I'd expect to see as dynamic brake force drops due to running at a slow or high speed. I think this may be related to my previous point where the brake cylinder alternates between 0 and max instantly.

Do you have ORTSDynamicBlendingForceMatch ( 1 )? This is required for the partial Bail-Off to work correctly. I tested this feature extensively for several trains, and I couldn't reproduce the issue. I know where the almost-instant pressure increase comes from, but that part of the code shouldn't be triggered when you have partial bail off.

[hroch]

Hello,

Where can I find documentation for the ORTSDynamicBrakesHasPartialBailOff parameter? I don't see it in this manual. Or has it not been inserted yet? I can't neither find the ORTSEPBrakeControlsBrakePipe parameter. Possibly some example of use.


Another thing I want to ask. Is there or is it planned to program a high pressure overcharge notch? Another thing I want to ask. Is there or is it planned to program a high pressure overcharge notch? With and without low auto-overcharge.
When the brake controller is placed in the high-pressure overcharge position, the brake pipe continues to fill up quickly to the main reservoir pressure.
By low overcharge I mean the same function as in OR TrainBrakesControllerOverchargeStart.

With low auto-overcharge:
After moving the brake controller lever to the driving position, the pressure in the brake line drops quickly to a value of 5.4 bar. To a value of 5.4 bar, because a low-pressure overcharge is introduced. Then the pressure in the brake pipe decreases as in the TrainBrakesControllerOverchargeStart position to a pressure of 5 bar. When the brake controller lever was in the high-pressure overcharge position and the pressure in the brake pipe exceeded about 6 bar, the brakes will be applied. The locomotive is released brake by bail-off button or bleed valve. Wagons only by a bleed valve.

Without low auto-overcharge:
The pressure in the brake line drops quickly to a value of 5 bar. Otherwise, everything is the same as with low-pressure overcharge.

High overcharge with low auto-overcharge and overcharge also exist as buttons.

[cesarbl]

Quote

Where can I find documentation for the ORTSDynamicBrakesHasPartialBailOff parameter? I don't see it in this manual. Or has it not been inserted yet? I can't neither find the ORTSEPBrakeControlsBrakePipe parameter. Possibly some example of use.

The manual will be updated when the changes get into the Testing version.
Basically you will use ORTSDynamicBrakesHasPartialBailOff(1) for any blending system that complements dynamic brake with pneumatic brakes to achieve the desired brake demand.
ORTSEPBrakeControlsBrakePipe(1) is for trains which have the UIC EP braking system: brake pipe is charged or discharged at each car following instructions from locomotive.

Quote

Is there or is it planned to program a high pressure overcharge notch? With and without low auto-overcharge.

I don't know about the exact functionality you mention, or what are its possible uses, so I'm not planning to add it at the moment, sorry. You have Quick Release and Overcharge (available as button or position) which might serve for your purposes with adequate configuration.