Some manipulators possibly allow scrollwheel behavior, despite no effect in X-Plane

[danklaue]

I'll go through and make a comment about how each manipulator type works for me. Attached is a simple airplane that showcases all the comments I'm making here. (Labels in plane and Blend file should help clarify what's going on. I'll limit myself to comments about the manipulators.

RV-10-XP2B3.4_Test.zip

1. Drag Axis Pix: OK.

2. Command Switch Up Down: OK, except for maybe: fixed rate. It'd be nice to have control over the speed of the command repetitions. Scroll wheel feels great. Expected behaviour: being able to set the speed (e.g. 1x, 2x, 4x, etc.) of command repetitions per frame... OR make it dependent on the distance from the centre of the manipulator. (Pixels from centre: 1-10 = 1 command repetition per frame. 11-20 = 2 command repetitions per frame, etc.)

3. Command Switch Left Right: OK, except for maybe: fixed rate. It'd be nice to have control over the speed of the command repetitions. (Same as above.)

4. Command Switch Knob: OK, except for maybe: fixed rate. It'd be nice to have control over the speed of the command repetitions. (Same as 1.)

5. AXIS SWITCH UP DOWN: BROKEN. Mouse icons change to reflect correct "Up" and "Down" click zones, but actually, this manipulator reacts to left and right zones. (I.e., it's technically identical to AXIS SWITCH LEFT RIGHT, except for the cursor.) Expected behaviour: Clicking on the upper half of the manipulator should increase the dataref value by the amount set in "Click Step", and clicking on the lower half should decrease the dataref value by the amount set in "Click Step".

6. No-Op: OK

7. TOGGLE: Scroll wheel functionality reversed. (While all command-based manipulators use the convention of "Scroll forward to increase value", TOGGLE uses "Scroll Backward to increase value". It's inconsistent in terms of expected UI behaviour. Expected behaviour: "Scroll Forward to increase value".

8. WRAP: BROKEN SCROLL Not only is scroll reversed, as in previous item, scroll only works in initial little range. Unclear exactly what's happening. Expected behaviour: scrolling forward should increase the value by the amount set in "Wheel Delta", and should wrap around when it gets to the value set in "Value 1 Max".

9. DELTA: BROKEN SCROLL Scroll is reversed, as in previous items. Scroll only works in initial little range, as in previous item. Only increasing delta click spot's scroll works. (Negative or descending scroll manipulator negates proper scroll functionality.) Expected behaviour: Scrolling on ascending delta click spot should increase AND decrease value by "Wheel Delta" setting. Scrolling on descending delta click spot should increase AND decrease value by "Wheel Delta" setting. Direction should match aforementioned command manipulators: scroll forward to increase, scroll backward to decrease.

10. RADIO: WONKY SCROLL WHEN USING FLOAT DATAREFS Using scroll wheel on any of these manipulators yields wonky results. But when using INTEGER datarefs, it works as expected. Expected behaviour: to work more like it does on integer datarefs. Although, even on integer ones, it doesn't work 100% as expected. One would expect to be able to scroll on ANY radio button, and get each scroll event to increase or decrease the value between the lowest and the highest radio button, by the value set in "Wheel Delta".

11. PUSH: UNEXPECTED SCROLL Scroll event on push button "Sticks" to last value. Expected behaviour: when user stops scrolling, value returns to "On Mouse Up" value.

12. COMMAND AXIS: UNEXPECTED DRAG BEHAVIOUR and NO MOUSE SCROLL Currently, when dragging the defined distance, a repeating command gets triggered, as long as the click-drag distance is past the threshold set in the manipulator's "DRAG" directive. Scroll wheel doesn't work at all. Expected behaviour: One of the following two: EITHER the farther you drag, the faster the commands repeat OR make it work more like the "Drag Axis" manipulator, where commands are issued as a function of delta-pixels moved. (This would be handy, as an alternative to "Drag axis" manipulators... this would avoid 360º reset issues on knobs like HSI, compass, HDG, CRS, etc.) Scroll wheel behaviour should match "Command Knob" type manipulator's scroll behaviour.

13. COMMAND: SCROLL WHEEL DOESN'T WORK Expected behaviour: scroll wheel behaviour should match "Command Knob" type manipulator, on both positive command click spot, and negative command click spot. (Scroll wheel should be able to move both ways, regardless of whether the underlying command moves up or down.)

14. DRAG AXIS: WORKS SORT OF AS EXPECTED, as long as camera angle is facing forward, and as long as click spot's orientation isn't altered. Expected behaviour: mouse drag axis should be consistent with GLOBAL or CAMERA coordinate system, not local. When click spot changes orientation, all hell breaks loose, and drag direction is no longer clear. Also, drag direction should be in relation to the camera perspective. I.e., X axis drag settings should always represent a left-right motion in relation to the camera's local coordinates. Y axis drag settings should always represent vertical motion, and Z axis drag settings should always represent closer/further away from the camera viewpoint.

15. DRAG XY: SCROLL WHEEL DOESN'T WORK Expected behaviour: AT LEAST cause scroll "Wheel Delta" events to work on Y axis by default. Better yet: let authors determine if scroll commands should affect X or Y axis. ALSO: same as 14: unexpected results when camera isn't facing forward, or click spot isn't oriented the same as global coordinate system.

[bsupnik]

Hi Dan,

This bug report is not detailed enough for us to act on.

• There are no sample materials to reproduce the bug.
• There is no regression information indicating if this behavior is new to the new version.
• There is no description of the expected vs actual results.

If you can provide a blend file that reproduces the bug and the versions of the exporter that worked or didn't work, we can find the "diffs". Or if you can describe the selected feature and expected vs actual results, we can create a test case.

[tngreene]

1. When you say "doesn't seem to work properly" - do you mean it doesn't work in X-Plane or doesn't show up in the OBJ file, or....?
2. Same question for 1.
3. This is a feature request, so if you'd like this feature please make a separate feature request for it

[danklaue]

I have updated the initial comment to be more clear about what works and what doesn't with manipulators. I imagine this stuff is being worked on by Laminar to achieve expected VR behaviour. These are my recommendations for consistent, expected behaviour. Some of it is probably XP2B related, but other stuff might fall into "Laminar Bug Report" category. Not sure which is which.

[bsupnik]

I can confirm that item 5: up-down dataref switch has up-down hot spots for cursors but left-right hot spots for clicking is a bug in X-Plane. I will fix this in X-Plane for 11.10.

[tngreene]

Even though this problem isn't fixed, it doesn't have to do with XPlane2Blender anymore, so I'm going to close this.

[bsupnik]

I want to re-open this for one reason: there exists at least one manipulator where the operation of the wheel attachment produces an X-Plane object that, while format legal, has absolutely no useful behavior.

@tngreene per our previous discussions, we've tried to make the Blender UI such that it makes relatively obvious what an author should be doing with it. E.g. we hide UI that won't be used based on other modes, like hiding the texture name when auto-select is picked. The logical todo item would be to hide the scroll wheel info from a subset of manipulators where its use will produce no useful behavior under any circumstances.

[tngreene]

Can you give me a list of manipulators that should hide scroll wheel info?

in xplane_primitive.py, 190-191 this decides whether or not to have "ATTR_manip_wheel".

            if manipType in MOUSE_WHEEL_MANIPULATORS and bpy.context.scene.xplane.version >= VERSION_1050 and manip.wheel_delta != 0:
                self.cockpitAttributes.add(XPlaneAttribute('ATTR_manip_wheel', manip.wheel_delta))

In xplane_constants.py, 44-53

MOUSE_WHEEL_MANIPULATORS = (
    MANIP_DRAG_XY,
    MANIP_DRAG_AXIS,
    MANIP_PUSH,
    MANIP_RADIO,
    MANIP_DELTA,
    MANIP_WRAP,
    MANIP_TOGGLE,
    MANIP_DRAG_AXIS_PIX
)

MOUSE_WHEEL_MANIPULATORS first turned up in cfbc577477ba3f9b6, 2 years ago. No changes since.

In xplane_ui.py, this is used to test when to show the property wheel_delta.

Which is these MOUSE_WHEEL_MANIPULATORS is not correct?