First, we are making progress toward X-Plane 10.50. I sent out a private beta a few days ago; how soon we get to public beta will depend on how buggy the private beta turns out to be. (I am assuming that it will have zero bugs, because I have decided to not write any more bugs in my code. So…there, I fixed it.)
Coming in 10.50: X-Plane supports new manipulators.
- In 10.50 you can add scroll wheel to any of the existing manipulators that takes one dataref. This is done via a second directive that sets the amount the dataref changes when the wheel moves.*
- There are six new manipulators (they form a set) to support knobs and three-way switches. Each one takes a pair of commands and provides a consistent UI experience.
- The no-op manipulator now takes a tool-tip, which lets you make tool tips for gauges and other unclickable geometry.
I want to make two things clear here:
- This is support for these manipulators in the engine. This means that we can use them in our aircraft and third parties can use them in their aircraft. Adding these manipulators is a separate task, one we are working on, but which won’t be complete as of 10.50.
- Third parties are welcome to use the new manipulators, and they are welcome to follow our internal usage guidelines. They are also welcome to keep doing what they are doing; none of this is binding, everything is opt-in. Nothing about this breaks compatibility with any existing aircraft.
Why Did We Add These?
We’ve had a long term internal goal of making the 3-d cockpit as usable and user-friendly as possible. We’ve reached a point where 3-d cockpits are the norm, and all of our new aircraft development is 3-d only. But you can’t deny that 2-d cockpits are incredibly usable from a user interface standpoint. How do you make 3-d usable?
We already have view presets to let you get to a particular cockpit view easily. Once you have a good view of the surface you want to interact with, the next step is to have a mouse gesture that’s easy to use.
This is where the new manipulators come in. Rather than describing a mouse gesture (drag, click, etc.) they describe a type of physical hardware, one of a rotating knob, left-right multi-way switch or up-down multi-way switch.
Because the manipulators describe the physical hardware and not how the UI should work, we can change the interaction mode based on user preferences, available hardware, etc.
One of the big UI questions is: should you change a knob by clicking and holding or dragging? I built a test airplane with some of each and the company was split down the middle. By using knob manipulators (and not click or drag manipulators) we can change the way knobs work in the cockpit for all airplanes with one change of the code, rather than having our art team redo every single manipulator in every single airplane.
I don’t know whether we’ll use dragging or clicking-based knobs – or whether a user preference will be exposed. But by having a higher level manipulator type we make this a small programming problem and not an unmanageable authoring problem.
(The new knob manipulator automatically uses the scroll wheel – since we know it’s a knob, we can figure out how the wheel should work. The new command to add scroll wheel to legacy manipulators is necessary to provide the data the sim needs to make the user interaction good.)
The new higher level manipulators also give us flexibility for new input devices. For example, if we someday want to support multi-touch tablets and track-pads, we could map a pinch-rotate gesture to a knob – since we know the manipulator really is a round knob (and not just ‘something that you drag’) we can know that a rotating gesture makes sense.
How Do I Add Them?
The new manipulators are already supported in code in the Blender 2.7, Blender 2.49 and and AC3D. The manipulators are released in the newest Blender 2.7 exporter; I need to post newer 2.49 exporters. I do not know if/when there will be a public release of the AC3D exporter, but I can probably find the time at some point to do one more compile.
All aspects of the new manipulators are opt-in; if you don’t change your airplane, its functionality should not change.
What Aircraft Use Them
I’ve buried the lead a little bit here: X-Plane 10.50 will have a heavily upgraded Kingair C90 and Baron B58 that will use the new manipulators. We have not (yet) upgraded the rest of the fleet, and this upgrade will happen over a very long time-span. The goal of 10.50 is to lay the groundwork and make cleaner user interfaces possible by making the new manipulators available to our art team and third parties.
The guidelines I’ve been advocating for our artists are:
- Large things that move a lot like throttles are dragged via an axis that tracks the actual 3-d motion.
- Yokes track via a 2-d XY manipulator.
- Anything that toggles or has only two states is a single click, particularly for small things.
- Rotary knobs and rheostats use the new knob manipulators. The mouse wheel can turn them.
- Linear switches with three or more positions use the new left-right and up-down switch manipulators. The mouse wheel can click them.
There’s no reason why third parties have to use these guidelines; I post them only to show how we are thinking about usability. A more “3-d” approach is possible, e.g. drag a banana switch up and down to toggle it; my view is that for Laminar’s default fleet, which are the first aircraft users are going to use, single clicks provide a more direct and less surprising user experience.
For power users, having single clicks for switches may also mean you can get more done in the cockpit faster. (In real life, a pilot can reach up and flip four metal banana switches on the overhead panel very, very quickly.) We’ll still use dragging for big 3-d motions.
*This feature targets one-wheel clicking Windows-style mice. 2/3 of our users are on Windows, and Apple has shipped a wide variety of strange input devices, so the one-axis clicking mouse wheel is the most consistent hardware target for us to aim at. And frankly, I think it’s the most useful since you get clear ‘detents’ as you scroll things – good for changing a radio by one notch.
As I said on another occasion should decouple zooming with the interaction of the mouse wheel. Is a problem in turbulent conditions the drive power elements and avoid zooming.
yes , an option to disable zoom or map them to another set of inputs would be great to avoid unwanted zooms when interacting with the cockpit
The zoom problem is definitely a problem. I’ve messed up things more than once by having a control move under the mouse pointer while zooming in or out. It’s the main reason why I’m not really a fan of scroll wheel manipulators.
However, it would be interesting if X-Plane could be changed so that it won’t send out any scroll wheel events to manipulators while it’s still changing its zoom level.
When the -native- scroll wheel manipulators are used, there’s no doubling – the wheel goes to exactly one place. (I’m actually not sure why this wouldn’t work the same way with plugins.) We haven’t finalized the preferences for the mouse wheel, but they’re easy to tweak.
You’re not exactly doing one click when zooming in to a specific instrument. You’re just pushing the wheel until you are where you want to be. And especially when you’re doing it in the direction of the co-pilot, the cursor moves over quite a few unintended knobs. At one point I dropped the gear that way when zooming out in a Carenado plane.
Oh – I understand, it’s not bad bookkeeping, it’s just a weird usage model. This very reason is why we didn’t have scroll wheel instruments originally. And I think they’re a poor fit for things like the throttle where the underlying click target moves.
Can you send me one of those private beta links please ? 😉
.
X-Plane aircraft with 2-d cockpits are very usable especially for new pilots who are learning how to fly, both off and online. When a pilot moves to an aircraft that has a 3-d cockpit, the pilot work load increases significantly. Our pilot has to change his or her view in the cabin to look at number of analog/digital displays and take the time to carefully manipulate a variety of rheostats, knobs, buttons, levers, etc. Using view presets and mouse gestures will help our pilots to quickly control their aircraft on the ground and in the air. I agree with your belief that new manipulators will help all of our pilots. We need to create a new user interface that will make it easier for our pilots who have to work in a more complex 3-d cockpit environment. Thanks, Ben!
Thanks Ben for the heads up.I can’t wait for the 10.50 to be honest…
I found delta manips with sasl code to be great with rotary cursors pointing to commands. The code executes on the first click then every 1/n seconds if the mouse is held down over the cursor, with n depending on the type of instrument and whether fast or slow scroll is desirable. Sound feedback is a big help too.
With drag-axis ones, the length of drag is important but becomes critical when two-axis drag is used, as it’s easy to get unintentional behaviors (a Carenado throttle I have is almost impossible to use due to this overlap). Drag-axis for toggle types of more than one position needs time blocks to prevent over dragging as well as longer drag distances than intuitive ones. Again, a sound is helpful, and until the toggle sound finishes, subsequent switch moves are disabled by code.
By these methods, I found the existing manips sufficient to satisfy all my requirements. Altimeter-dials, for instance, can count events, scrolling by 100-ft for the first twelve events, then by 1,000-ft unless the mouse button is released. It should never display fractions of 100 (or 50). I can imagine that even using the scroll-wheel, some code would still be required to attain the best results. It’ll be ‘interesting’ to see what you come up with.
One of our goals was to -not- require a layer of scripting logic behind the manipulator to achieve usable effects.
I like the 3-D cockpits but my impression is that they reduce the fps significantly. Just downloaded the Stratmann 737 v5 and I go from 35fps to 16 fps.
That depends on the particular 3-d cockpit and how close to maxed out your machine is on certain GPU resources. I think the market has spoken though – 3d is the future.
With my late 2012 iMac 21.5″ I have to reduce my renderings each new version, so I’m not exactly maxed out nor have been for some time. I still like the 3D though.
The Fps problem is only related to x737 aircraft not xplane buddy/
I suppose that is gratifying and I hope they can sort it out. Its a great project.
Hello Ben,
Some time ago you mentioned that Night Lighting rendering distance *may* be increased in the next builds. You mentioned here: http://developer.x-plane.com/2015/06/x-plane-10-40-the-new-dsf-loader/#comment-10785 that the existing limitation is the leftover from the 32-bit version.
Is there any progress on that?
No – we are not increasing the limit any time soon.
Thank you very much for your answer. I will still hope for a slider one day. 🙂
This is all neat little stuff, but what I would really like to know is if the big issue of stuttering during a real wx update is ever going to be fixed. Last I heard from Austin he said it was too much work. Is this even on the radar?
James
You’ll need to discuss that with Austin.