Prop Lock Test Bug

[GridiroN]

When holding down the prop unfeather switch, only the left condition lever is movable. 

Condition levers also do not have clickzones. They move only on an axis. 

[Matchstick]

8 hours ago, GridiroN said:

When holding down the prop unfeather switch, only the left condition lever is movable. 

Condition levers also do not have clickzones. They move only on an axis. 

It looks like the condition levers do have a clickzone until you move them with the joystick at which point it which turns off the clickzones and only allows you to move them with the axis.

[Ch.Cole]

2 hours ago, Matchstick said:

It looks like the condition levers do have a clickzone until you move them with the joystick at which point it which turns off the clickzones and only allows you to move them with the axis.

This is intended behaviour, according to the documentation.

Quote

The following information is a bit technical, but may be useful for troubleshooting. X-Plane has a complex system for keeping track of the various hardware configurations for multiple aircraft. As authors, X-Plane only tells us which axes is moving and what the value is when it is moving. When no hardware axes are being moved, X-Plane does not tell us anything at all.

When the MU2 simulation begins, we sniff all the hardware axes and wait for any axes to be moved. Once an axis is moved for the first time, we take note of that for the rest of the sim session, assume a specific configuration and take various actions accordingly. For example, if you have a single paddle throttle (assigned to THROTTLE) and we detect it, then we hide the manipulators for the throttle so you don't mix and match interaction techniques, which is problematic; however, we keep the condition lever manipulators onscreen etc. The assumption here is you cannot get very far into the simulation without moving your hardware and once its moved in the session, things should be fine.

If you change an axis assignment mid-simulation, say you have a single paddle and you reassign it from the throttle to the condition lever in the same flight, which is quite unlikely of course, then this will cause issues. Any time you change a hardware axis assignment, you should begin a new flight so the code can reset and pick up the new setting. The obvious protocol here is simply to configure you hardware for the MU2 before your first flight and then all subsequent flights should be fine with that same hardware. Only changing axis assignements mid-flight would cause an issue and this is not terribly likely.

Further, if you assign any single axis to THROTTLE 1 or THROTTLE 2 (same with the condition levers) then we assume you have a dual lever setup and hide all manips for those levers. In other words, we do not expect a user with a single paddle to assign that single paddle to a LEFT lever only. We also do not expect a user with two levers for a single function (throttle OR prop) to assign one lever to a single power lever (THROTTLE) and the other to a single condition lever (PROP), etc.

 

Edited July 16, 2022 by Ch.Cole

[Matchstick]

Just now, Ch.Cole said:

This is intended behaviour, according to the documentation.

The following information is a bit technical, but may be useful for troubleshooting. X-Plane has a complex system for keeping track of the various hardware configurations for multiple aircraft. As authors, X-Plane only tells us which axes is moving and what the value is when it is moving. When no hardware axes are being moved, X-Plane does not tell us anything at all.

When the MU2 simulation begins, we sniff all the hardware axes and wait for any axes to be moved. Once an axis is moved for the first time, we take note of that for the rest of the sim session, assume a specific configuration and take various actions accordingly. For example, if you have a single paddle throttle (assigned to THROTTLE) and we detect it, then we hide the manipulators for the throttle so you don't mix and match interaction techniques, which is problematic; however, we keep the condition lever manipulators onscreen etc. The assumption here is you cannot get very far into the simulation without moving your hardware and once its moved in the session, things should be fine.

If you change an axis assignment mid-simulation, say you have a single paddle and you reassign it from the throttle to the condition lever in the same flight, which is quite unlikely of course, then this will cause issues. Any time you change a hardware axis assignment, you should begin a new flight so the code can reset and pick up the new setting. The obvious protocol here is simply to configure you hardware for the MU2 before your first flight and then all subsequent flights should be fine with that same hardware. Only changing axis assignements mid-flight would cause an issue and this is not terribly likely.

Further, if you assign any single axis to THROTTLE 1 or THROTTLE 2 (same with the condition levers) then we assume you have a dual lever setup and hide all manips for those levers. In other words, we do not expect a user with a single paddle to assign that single paddle to a LEFT lever only. We also do not expect a user with two levers for a single function (throttle OR prop) to assign one lever to a single power lever (THROTTLE) and the other to a single condition lever (PROP), etc.

 

Unfortunately that does mean you can't use the mouse to move them to Emergency Stop just by dragging.

[Ch.Cole]

Yes. Once you use an axis, you can't go back to mouse control. I assume you'd run into issues with noisy axis, if they don't match the in-sim controls.

[tkyler]

Quote

 

When holding down the prop unfeather switch, only the left condition lever is movable. 

 

Noted on this, added to bug list.  Thank you.

Regarding the click zone, This is indeed a tough philosophical discussion.  I'm on the fence about hiding the manips when hardware is present.  I've heard arguments both for/against.   I think this will evolve into an "options" where you can choose your preference but doing so requires a bit of coding infrastructure on my end....so hopefully we'll get everyone accomodated soon.  I am not terribly happy with the 'unfeather test' / condition lever situation myself...its a fight against X-Plane...I fought this more than I would have liked.  The only reason I accepted it for now is its a small part of the overall experience, but I won't be happy till its perfect.  

-TomK

 

[tkyler]

11 hours ago, GridiroN said:

When holding down the prop unfeather switch, only the left condition lever is movable. 

What is your hardware configuration in this situation?  Single paddle assigned to prop etc? left or right unfeather button etc?

[GridiroN]

8 hours ago, tkyler said:

What is your hardware configuration in this situation?  Single paddle assigned to prop etc? left or right unfeather button etc?

So I actually managed to fix it by assigning both prop levers to individual axis'. However, if using the basic XP11 "prop" dataref (in which any number of prop levers are mapped to a single axis) only the left engine is manageable during a large number of procedures. 

 

My HOTAS is a Virpil T50 mongoose (original version)

[tkyler]

A favor....to help me understand user cases better.  I was laboring under the assumption that if a user had  "dual levers" intended for a common function (power or prop), then they would logically map those levers to "1 and 2" (throttle or prop).  So if you have multiple prop levers as mentioned in the previous post,  then why would you not map those to 1 and 2 to begin with?....i.e  what would you map the 'left' and 'right' ones to in another circumstance?

-TomK

Edited July 17, 2022 by tkyler

[Matchstick]

On 7/16/2022 at 4:57 PM, tkyler said:

Noted on this, added to bug list.  Thank you.

Regarding the click zone, This is indeed a tough philosophical discussion.  I'm on the fence about hiding the manips when hardware is present.  I've heard arguments both for/against.   I think this will evolve into an "options" where you can choose your preference but doing so requires a bit of coding infrastructure on my end....so hopefully we'll get everyone accomodated soon.  I am not terribly happy with the 'unfeather test' / condition lever situation myself...its a fight against X-Plane...I fought this more than I would have liked.  The only reason I accepted it for now is its a small part of the overall experience, but I won't be happy till its perfect.  

-TomK

 

If I may be entirely selfish for a moment what I'd personally like to see are Emergency Stop On/Off events (or a Toggle with a dataref to show current state) that can be use to move the Prop levers from Taxi to Emergency Stop and vice versa.
That way on my Honeycomb Bravo I can set the Prop levers with the curve starting at 10% as suggested in the documentation and then use the switch below the bottom of the lever arc to trigger the Emergency Stop events.

Now, I've no idea if this is a) practical from a coding position or b) any use to anyone else who isn't using this specific throttle quadrant, but I though I would throw the idea out there just on the off-chance it is

[tkyler]

5 minutes ago, Matchstick said:

ow, I've no idea if this is a) practical from a coding position or b) any use to anyone else who isn't using this specific throttle quadrant, but I though I would throw the idea out there just on the off-chance it is

It absolutely is.  All it takes is dialogue so the "specs" become clear.   I'm noting this request and working it into my investigation. hardware is important and I'm actually working on it right now.  I kind of knew this would be the issue...the engine management and quadrant is the heart of this beast and so getting everyone's hardware working in a natural way for them is priority.  TBH, my unfamiliarity with all the hardware is part of the issue....honestly haven't seen that "button at the back" situation of the honeycomb.  Now that I know its there, I'm sure we can come up with a solution.

I mentioned elsewhere that I am re-implementing (because its in Version 1) the animation of the quadrant levers.  What I mean by this is I'm going to decouple the hardware input from providing the actual value that the animation uses...this way, the levers will always move smoothly between positions.  So if you do use a command to send things into reverse, it will animate the lever there naturally...and it will allow me to squeeze in a nullzone configuration, because my levers are shaking like they're naked at the north pole.....not exactly precision flight controls....though thats the name on the box

-TomK

Edited July 17, 2022 by tkyler

[tkyler]

providing the command to move the condition lever to emergency cutoff and back should be no issue....I'll see about working it in for the next patch.

[GridiroN]

6 hours ago, tkyler said:

A favor....to help me understand user cases better.  I was laboring under the assumption that if a user had  "dual levers" intended for a common function (power or prop), then they would logically map those levers to "1 and 2" (throttle or prop).  So if you have multiple prop levers as mentioned in the previous post,  then why would you not map those to 1 and 2 to begin with?....i.e  what would you map the 'left' and 'right' ones to in another circumstance?

-TomK

When you start doing this, you start getting into territory where we're getting hardware restrictions. In planes without failures modelled, it really doesn't matter to have multi axis' and in cases where you do need to it (The AirFoilLabs King Air 350 for eg.), it's manageable my using the mouse instead. 

The issue with your product is that it doesn't have a mouse clickzone for manipulation AND it requires more than 1 axis, making it difficult to manage unless you have pretty good hardware with many (useful) axis' (like a honeycomb or something).  

Edited July 17, 2022 by GridiroN

[tkyler]

Quote

The issue with your product is that it doesn't have a mouse clickzone for manipulation

FWIW, I've already provided a preference to "expose manipulators" with hardware....so they'll always be exposed if you choose.  I'm pretty sure we can get everyone accomodated with time.  I just have to work through each of the use cases and my uses cases are probably much more limited than consumers.

Edited July 17, 2022 by tkyler