Stabilize view when the user is clicking on buttons

[nico87]

Clicking on a button using the mouse in the 3D cockpit while flying in bumpy weather or when the engine vibrations are active is difficult. This is because the button moves under the mouse pointer.

This may be solved by reducing the movements triggered by HeadShake when the view gets closer to the cockpit. Also, a custom command that stops the movements when the user activates it may work as well.

Other solutions are accepted.

[Danita]

I think it might work very well if the plugin gradually pauses the shaking while the mouse pointer is hovering a "click zone" (or "manipulator" as I think LR call it). Once is out of the manipulator, the shaking can resume.

[nico87]

Danita, do you know if it is possible to detect the hover on a manipulator? In the plugin SDK, the only API i may find useful is XPLMCursorStatus.

[Danita]

Not really, I'm just guessing. I'm a programmer and I'd love to collaborate on the project because I use this wonderful Headshake since my first day on X-Plane, but sadly I don't know C++ nor have studied the SDK!

[wolfsnipes]

I don't think there's a way to detect the existing cursor status, only to assign a new one. So this becomes a difficult item to solve because a perfect solution involves a) hit testing, b) interacting with obj elements drawn by x-plane, and c) using 3d cockpit coordinates in a cockpit draw mode. None of these are accommodated by the SDK!

In order of difficulty, here are some ideas

1) Detect mousedown event and stop shaking when the cursor is down. This would detect any mousedown event, but not necessarily when a manipulator is involved. This is the easiest but not specific to manipulators.

2) You can do a quick parse of the object file to figure out which commands are being attached to each manipulator, and a) create an XPLMCommandCallback_f for command manipulators or b) monitor datarefs pointed to by the non-command manipulators. In effect, the first successful command execution or dataref delta would allow additional manipulator actions to be performed shake-free until a certain time has passed when no commands or deltas have been executed, then shaking would continue as normal. The upside is that there is no opengl or geometry or anything involved. The downside is that you still have to read the object file and hope that the operators first click is a good one.

3) In the authoring stage, map a texture over the manipulators and detect a texture coordinate through the texture coordinate dataref. This is the easy way but only possible when the author is involved.

4) Again, parse the cockpit object file yourself and perform collision testing on the manipulator mesh elements manually. This is the 'perfect' method but requires a whole lot of math and opengl hacking and working around the fact that there's no cockpit draw mode that actually works...but you can do it.

Other than these, the original suggestions by the OP are probably best. Others with more exposure to the SDK may as well have some hacks.

[Althar93]

I do not have access to a PC at the time of writing this comment so it is difficult for me to confirm any of this but can the http://www.xsquawkbox.net/xpsdk/mediawiki/XPLMMouseStatus potentially be of any use in this case?

[Althar93]

There may be more info on here also : http://www.xsquawkbox.net/xpsdk/mediawiki/XPLMDisplay

[wolfsnipes]

When the mouse is down yes...but there's no way to know when the cursor is over a manipulator without additional work.

On Feb 25, 2017 5:37 PM, "Craig Hupin" notifications@github.com wrote:

There may be more info on here also : http://www.xsquawkbox.net/ xpsdk/mediawiki/XPLMDisplay

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/simcodersdotcom/headshake/issues/2#issuecomment-282525756, or mute the thread https://github.com/notifications/unsubscribe-auth/ADBwxTw_w5tHkpUu7PEK_LIjaNfFtXCvks5rgNdkgaJpZM4MFg6J .

[nico87]

@wolfsnipes your suggestions are good ad may work but are too complex and possibly require too much computation. By the way, you gave another idea. What if we analyze the mouse gestures? For example, if the user is moving the mouse not in direction of the menu, we can reduce the effects!