PARKING BRAKE setting does not set BRAKE LEFT (and RIGHT) POSITION

[lkalam]

Hello,

We noticed that there's a behavioral difference between FSX and P3D (all versions):

After setting PARKING BRAKE in FSX, the two variables BRAKE LEFT POSITION and BRAKE RIGHT POSITION return maximum values.

In P3D, the same action (setting PARKING BRAKE) does not affect those two variables - as if the brakes are no longer pressed.

Was this change made on purpose and if so why? It causes compatibility issues between sim platforms so I am wondering how we should approach a solution and why it has not been reported thus far.

EDIT:

You can test this behavior in the two sim platforms by using FSUIPC as well, and observing variable 0BC4 (BRAKE LEFT POSITION) as a S16 value.

[Adam Breed]

Hello,

Correct, there was an update made to better support those SIMVARs. See:

http://www.prepar3d.com/forum/viewtopic ... 09&t=11682

In April 20114, BRAKE_LEFT_POSITION and BRAKE_RIGHT_POSITION were updated to match the documentation. Previously they were not directly settable and would only be set to 0 or 1 based on PARKING BRAKE. To get the same functionality, after setting PARKING BREAK, set LEFT & RIGHT to 1. It should cause the same behavior as it would in FSX.

Regards,
Adam

[lkalam]

Thank you Adam,

I searched the forums for info on this but I must have missed the original posts.

I'll see what we can do to work with the changed logic.

[lkalam]

Hi Adam,

Following your advice, upon detection of PARKING_BRAKE action, we set the BRAKE_LEFT_POSITION and BRAKE_RIGHT_POSITION to 0 (when OFF) or Max (when action is "SET") accordingly.

It looked like this worked, but it only worked "properly" once (values 'stuck' to the Max and could be toggled 0 / Max depending on parking brake position). We since haven't been able to make the brake left and right values stick to Max values. They decay like they would if the brake pedals would be pressed.

My question is, thus:

Do we need to keep feeding the Sim with Max values, so that BRAKE_LEFT_POSITION and BRAKE_RIGHT_POSITION stay at Max? And if yes, why did it work one time and are there any possible parameters somewhere that define this 'stickiness' boolean logic?

[Pete Dowson]

Correct, there was an update made to better support those SIMVARs. See:

http://www.prepar3d.com/forum/viewtopic ... 09&t=11682

In April 20114, BRAKE_LEFT_POSITION and BRAKE_RIGHT_POSITION were updated to match the documentation. Previously they were not directly settable and would only be set to 0 or 1 based on PARKING BRAKE. To get the same functionality, after setting PARKING BREAK, set LEFT & RIGHT to 1. It should cause the same behavior as it would in FSX.[/quote]

But in FSX, setting the parking brake automatically ensures both left and right brakes are indicated as applied at maximum. The parking brake is merely a latch on the brakes which are otherwise like the normal parking brakes.

In simulated cockpit implementations we usually only allow the parking brake to "latch" the toe brakes if sufficient pressure is applied to them in the first place. Similarly, pressing the toe brakes firmly allows the parking brake to be unlatched.

I must admit I don't understand the logic behind the change you have made in P3D. I will have to investigate how this may affect my own cockpit implementation -- luckily, up to now, I've been keeping to FSX.

Pete

[Mike Schroeter]

Hey Lefteris,

Yes, this change was in fact intentional. There was a need for separate cockpit indications for toe brakes vs. parking brakes. We needed only the parking brake annunciator on when engaged without any pilot toe brake input. This was not possible for the reasons you've already stated. This actually made sense since the toe brakes are not necessary pressed when the parking brake is on, and the SDK does not actually distinguish if the value is the brake's "pilot input" vs. the "physical effect". So what you are actually experiencing currently is that the variable reflects the "pilot input".

It's important to note that this change does not change the actual braking of the aircraft. Internally, the physical braking effect with the parking brake engaged should be identical to what it was before. Let me know if that is not what you are experiencing.

So with that understanding, do we still have an issue that needs to be solved? At a minimum I will add clarity to the documentation.

Thanks,
Mike

[lkalam]

Hi Mike, thanks for the reply!

the explanation is clear and the reasoning also. What is unclear still is what Adam described we need to do in order to return to the old functionality.

Specifically, Adam mentioned that since BRAKE_LEFT_POSITION and BRAKE_RIGHT_POSITION are now writable, we can be setting those to Max value when PARKING_BRAKE is set, in order to get the old behavior back. He did not specify, however, if this setting has to be done in every update cycle or it can happen once at PARKING_BRAKE set and my findings are quite controversial here, as the first tests I ran allowed the values to be set once and remain at Max (unless of course there's pilot intervention), but later tests would show a gradual decay of position back to 0 (as if the user pressed the brakes to max once and let go).

This is also in accordance to other observations whereby sometimes brake action will be 'sticky' and sometimes it'll be returning to 0.

Can you therefore clarify if we need to keep setting BRAKE_LEFT_ and RIGHT_POSITION to Max value in every cycle when PARKING_BRAKE is set or if there's some hidden logic inside the sim which determines whether this will be sticky or not? I am inclined to think there's something there that decides but I haven't found what it is.

[Mike Schroeter]

Is it possible that your first try (which did not decay) was with toe brake "axis" hardware? If the input comes in as an "axis input" we don't decay. If it comes in any other way we do. This of course is necessary from a usability standpoint... a hardware input needs to have its value maintained, while a keypress brake tap is expected to bleed off.

So if you want to set with that simulation variable, yes, you will need to set every frame. Alternatively, you could set using KEY_AXIS_LEFT_BRAKE_SET and KEY_AXIS_RIGHT_BRAKE_SET, which will make the brake system think it's coming from an axis controller and thus prevent decay.

This is a good example of why choosing KEY_ events is preferred over setting simulation variables. KEY_ events are designed to be inputs into the simulation, whereas sim vars may be intermediate values within the simulation.

Hope this helps,
Mike

[lkalam]

Hi Mike,

thanks once again for the clarification. I will ensure that our code distinguishes between the two possibilities.

I would strongly recommend that this be documented very clearly in the Learning Center as it's something that will baffle even the most seasoned sim developer - this distinction between axis not decaying vs. key decaying is not immediately intuitive and I would not have guessed in a million years (even though I am pretty sure I didn't use axis in my code originally).

[loise1996]

Hello,

We noticed that there's a behavioral difference between FSX and P3D (all versions):

After setting PARKING BRAKE in FSX, the two variables BRAKE LEFT POSITION and BRAKE RIGHT POSITION return maximum values.

In P3D, the same action (setting PARKING BRAKE) does not affect those two variables - as if the brakes are no longer pressed.

Was this change made on purpose and if so why? It causes compatibility issues between sim platforms so I am wondering how we should approach a solution and why it has not been reported thus far.

EDIT:

You can test this behavior in the two sim platforms by using FSUIPC as well, and observing variable 0BC4 (BRAKE LEFT POSITION) as a S16 value.

Hello lkalam ,

Can you suggest some tips for good parking in small area.

[lkalam]

Hello lkalam ,

Can you suggest some tips for good parking in small area.

I am sorry, what?