I have updated the OBJ8 specification with the new X-Plane 10.10 commands. This blog post explains why we added some of these commands.
Pixel-Space Drag Manipulator
The pixel-space drag manipulator is a new axis manipulator whose drag length is measured in screen pixels instead of meters; its drag axes are always screen aligned, but it works both horizontally and vertically.
The goal of this manipulator is to make draggable knobs that:
Have a good response speed for both slow and fast drags via a non-linear curve and
Have the same drag sensitivity no matter what camera angle.
The axis manipulator has the problem that it works in 3-d; depending on how you look at the manipulation target (both position and rotation) the sensitivity of the drag can change radically.
Recommendation: use the regular drag-axis manipulator for levers and other physically moving items. Use the pixel-space drag manipulator for drags where the underlying target does not move, like knobs. Use button-type clicks for anything that just toggles – it’s easier on the user.
No Shadows
Three new attributes (GLOBAL_no_shadow, ATTR_no_shadow, and ATTR_shadow) allow you to exclude part or all of your object from shadow casting. Shadows can make certain types of geometry, like grass billboards, look silly; excluding them from shadows fixes artifacts.
Note that ATTR_no_shadow is different from ATTR_shadow_blend..
ATTR_no_shadow: the geometry simply does not cast a shadow! This is meant to exclude objects like vegetation.
ATTR_shadow_blend: the geometry does cast a shadow, but only if the alpha is greater than a certain ratio. This is meant to make windows with tint cast shadows correctly.
Recommendation: fix shadowing bugs using ATTR_no_shadow for non-instanced objects, and GLOBAL_no_shadow for instanced objects. Use the Plane-Maker check-box for parts on aircraft.
GLOBAL_cockpit_lit
This attribute lets you have your cake and eat it. In X-Plane 9, ATTR_cockpit gives you alpha blending, but ATTR_cockpit_region gives you correct 3-d lighting. You have to pick one or the other.
In X-Plane 10.10, GLOBAL_cockpit_lit gives you both. It makes ATTR_cockpit use 3-d lighting (while maintaining translucency) and it makes ATTR_cockpit_region respect alpha translucency (while maintaining cockpit lighting).
You can add this attribute to any airplane. This attribute should make it easier for authors to adopt correct 3-d lighting in their airplanes.
Recommendation: use GLOBAL_cockpit_lit on any airplane that uses ATTR_cockpit to change to 3-d lighting for your panel texture. Also see here for more guidance.
Once Ben is done fighting his war on HDR arthropods, Beta 5 will make its way out to the masses. In it, you’ll find some very cool updates to the view system that we think will make sim-life much easier, more intuitive and more useful.
The first change is the removal of the “mouse look” in 3D mode. This was the mode where the mouse controlled your camera orientation just by moving the cursor around without clicking. We had some feedback on the feature and agreed that it’s really not a very useful mode. The mouse is needed to click on various things in the 3D cockpit and to have your head bobbing around while you’re trying to do that was just annoying.
To look around in 3D mode, you can still of course right click and then move the mouse to adjust the camera angle. You can also use your scroll wheel to zoom in and out of things. This has been in the sim throughout the 10.x run and will remain the primary means of controlling head movement (unless you use your keyboard or Track IR of course). Since many people find the right-click/scroll gestures to be intuitive and useful, I’ve gone in and made things more consistent. Now, no matter what view you’re in, if head movement or zoom is possible, it’s done with right click and scroll. It used to require a LEFT click and scrolling was not an option. This should immediately help people who had trouble with the left clicks activating their mouse-flying box.
The final change is a pretty important one. We’ve added a system called “Quick-Look” (QL from this point on). Technically, you already have QL but I didn’t want to point it out to everyone until I had time to make some improvements to the system which I’ve done for Beta 5. QL allows you to get a view just the way you love it…and then save it to a hot key/cmnd that you can recall at any time later to go right back to the same spot.
For example, suppose you’re flying the default King Air and you find yourself frequently positioning your head, tilting down and zooming in on the throttle quadrant to see how you have the aircraft configured. This can take some time to setup and if you do it often, it can really get tedious. Let’s assign it to a QL then! Get the view the way you like it, and assign it to QL1. Now, no matter what you do to your views, when you press QL1, your head position, orientation and zoom goes right back to your memorized view of the throttle quadrant. It’s not just for 3D cockpit mode either. It works in all aircraft-relative views so 3D Cockpit, Ridealong, Chase, Circle, Forward with Hud etc. The reason for that limitation, is that these views are saved a little differently than other things in the sim. These are aircraft specific preferences. This is necessary so that your views for the Cessna 172 stay with the aircraft and don’t interfere with views for the King Air etc.
Currently, you get 10 QL views per aircraft and they’re saved/recalled anytime you switch aircraft. The QL keys are number-pad 0-9 by default. So for example, to recall QL3, just press the 3 on your number pad. To save a view to QL3, just get the view the way you like it, then press CONTROL + Num-pad 3. CONTROL is the default modifier key to do memorization. Like most of the commands in X-Plane, these are customizable so you can wire them up to any button combinations that you want. Also, you can use your joystick buttons as well to recall saved views.
A word of caution…some of you may have already discovered the QL system in earlier betas. That version is a fairly limited prototype (it only works in cockpit mode) so please do not report any view bugs prior to testing Beta 5. Lastly, your aircraft QL view preferences are going to get trashed with Beta 5 so please don’t spend hours tirelessly getting your views perfect for dozens of aircraft.
***EDIT*** Here’s a quick video I took of some sample views that I setup in the default King Air.
…between myself and X-Plane’s deferred rendering engine. It is a battle to get correct alpha blending behavior when scenery objects fade with distance. Current casualties include a good chunk of the existing HDR shader code and my sanity. Once there is a victory (no guarantees it will be me) we’ll cut beta five.
As you are hopefully already aware, the Joystick subsystem of X-Plane was completely rewritten for X-Plane 10.10. It uses a much lower-level method of communication to essentially talk directly to the devices so that we have complete access to their capabilities instead of being limited to what a “middleman” layer of software feels like telling us…which is how things used to work.
While most of the bugs have been fixed as of 10.10Beta 4, there still remain a small subset of devices that are still having problems. Let me list the known open issues:
Even after calibration, some devices still show their axis max limited to about 75% of what it should be when viewed on the Axis tab of the Joystick Dialog. In other words, pull the yoke toward you and it goes to 0, push the yoke away from you and it goes to 75% instead of 100%. This is not a joystick bug at all but in fact a UI bug that’s been around all along but just never visible until now. This has been fixed in 10.10Beta 5 which is coming soon. You can also go to the “Null Zone” tab and see that your axis does in fact have it’s full range of travel.
Some hardware does not appear at all on Linux. This is not a bug! This is a security feature of the Linux operating system. The problem is, Linux is a multi-user operating system and it has to worry about permissions to devices that are attached to the system. Take a keyboard for example…imagine if another user logged in could see everything you were typing because he had read permissions on your device! Linux locks down permissions on devices that are not part of an exception. The way to create an exception is to create a UDEV rule. If you don’t know how to write a UDEV rule, google it a bit..they are not very complicated for the average linux user. If you’ve chosen linux as your operating system, we hope you possess the skills to configure it. Here’s a simple sample rule:
Here the VID is 0x06A3 and the PID is 0x0BD4. These are unique codes that identify that brand/model of joystick and the rule says “When you see this device, chmod 666 it.” One way of finding your VID/PID is by doing “lsusb -n”.
Some devices have hat-switches that appear to “stick” in the ON position. This is fixed in 10.10Beta 5 as well.
Last but not least, there are some devices that have particular AXIS or HAT SWITCHES that simply do not work. So far, I’ve seen a Logitech G25 clutch pedal and a Logitech G940 hat switch that doesn’t work. It works in the windows calibration screen as well as X-Plane 10.05R1 but not in the latest version.
Here’s where you guys come in. If you have one of those two Logitech devices, please let me know if yours is working just fine or if you have the problem as well.
I’m also interested in hearing about other devices that are having the #4 issue as well.
Lastly, if you are having any other kinds of Joystick problems that do NOT exist in 10.05R1 but that DO exist in 10.10 that haven’t already been mentioned, please let me know.
You can file a bug and please include a Log.txt file from 10.10Beta 4 as well as a description of what’s not working properly and on which device.
(Oh come on, I know at least some of you are Dr. Who fans…)
If you have not read the news, OpenStreetMap will be removing their non-license-compatible roads this week. I stopped following the debate on this years ago, but basically they changed open licenses and have had to drop contributions that could not be re-licensed from the original authors. My understanding is that the amount of data that will have to be nuked will be very small.
If you have already contributed to OSM even remotely recently, you probably agreed to the new license terms and your data is fine.
My thought: after the redaction is finished would be a great time to check your home town and help put back any lost roads, etc.
Propsman sent me this rather zen bit of OSM the other day…
I certainly hope they won’t have to redact it. 🙂
(Seriously though, one of the major data quality problems with X-Plane is people creating train platform and building footprints out of actual train tracks. If you are working on an area, please check the tagging of stations and platforms to make sure they’re not actually railways!)
I do not have a schedule or plan for recutting from new OSM data – it’s an aspiration right now but there’s a lot on the short list we have to deal with first (like 10.10).
Having such a small development team, it’s very difficult for us to test ALL conditions in which X-Plane is being used. Each of our offices are littered with joysticks, laptops, desktops, loose video cards, hard drives and various other hardware. We do our best to always be making steps in the right direction but it’s a losing battle to keep our testing internal. A prime example is the recent Joystick debacle. I rewrote the entire Joystick subsystem on 3 platforms and tested it on all 3 platforms on all joystick hardware I own, and Ben and Austin did the same. We worked out all known bugs and then shipped it…and immediately we found hardware that caused crashes 100% of the time. Once those were fixed, other devices were still broken…some devices didn’t even meet USB compliance and we had to work around that issue as well. I can’t possibly own every USB Joystick device on the market so how on earth do we get the product to be as stable as everyone wants it to be?
The answer is simple…we rely on ambitious and courageous users to take the plunge and help us test it. Being a Beta tester is a bit of a thankless job. Sure you get an early look at the new goodies but it can be very frustrating since often, you can’t enjoy them without crashes, artifacts and other annoying bugs. Most users are happy to provide their feedback via the bug form, and now with the new automatic crash reporting system, we’re finding and fixing crash bugs in record time. A prime example is the Joystick crash. Within minutes of releasing 10.10Beta 1, I was aware of the crash and had all of the information that I needed to solve it. And within 24 hours, we had a new build that took care of it. But that’s only useful for crashes, it doesn’t help us learn about visual artifacts or other problems. That’s where we need YOU.
After reading through the forums, it’s become clear to me that many people are just not exactly sure what it means to Beta test software so I’ve come up with my own list.
Keep two copies of X-Plane. If you care to ever fly X-Plane for enjoyment, ALWAYS keep two copies of the simulator on your hardware. One on a stable release that you use for enjoyment, the other on the latest beta for test purposes only. Your sanity will thank you later.
Don’t use the beta for recreation time. If you’re only in the mood to fly and have fun that night, stay away from the beta copy unless you don’t mind your flight getting cut short. Too many users expect to fly for 6 straight hours and become enraged when the sim crashes on short final. That’s Murphy’s law!
Always stay on the LATEST beta. Users often say “The latest beta broke XYZ, how do i go back to the previous beta?”. The answer is you don’t and you shouldn’t. That defeats the whole purpose of beta testing! During a beta process, the code is often changing very rapidly. If we’re on Beta 6 and you’re still submitting bugs on Beta 2, you’re wasting your own time and you’re not helping the product. It’s important you keep up with development.
Blame us, not your system. If it worked in Beta 3 but it’s broken in Beta 4, do NOT tear your machine to pieces trying to figure out the cause of the problem. Report it and let US figure it out. Time after time, I see users change their drivers, install service packs, uninstall and reinstall X-Plane, update their OS etc trying to solve the bug…when it’s probably OUR bug…not your computer’s.
Beware of the placebo effect! _EVERYTHING_ affects frame rate. Time of day, clouds, location, aircraft, view angle, view direction, addons, plugins etc etc. Sometimes we’ll release a simple patch that does nothing but fix one bug that was unrelated to the rendering pipeline. I’ll poke my nose in the forums to get some feedback and see 10 users who all of a sudden claim to see some massive fps increase in performance and 10 users who see a massive decrease in performance. I role my eyes at the claims because it’s not a controlled experiment. For example, if you’re the type of person who flies with real world weather enabled, flying one day with clear skies may get you 60fps while the next day you may see 40fps with overcast. Heck, even departing from a different runway than the previous day can result in different frame rates. Running with the command line fps_test IS a controlled experiment. THAT’s the only way to be sure you’re seeing a change in performance. Don’t trust your instincts, gather data in controlled experiments.
Always read the release notes (http://wiki.x-plane.com/beta) for each new version. They’ll tell you what bugs are supposed to be fixed as well as what new features have been added. If you see a bug that’s claimed to have been fixed yet it’s still happening to you, that’s when you write a new bug report. If we didn’t claim to fix it, it’s probably not fixed in that particular beta.
We need a Log.txt! When submitting a bug, ALWAYS ATTACH the Log.txt from THAT sim run. Even if you don’t think the Log.txt is applicable, attach it anyway. Tell us in as much detail as you can what you were doing at the time.
We already know about your crash. Because of the new automatic crash reporter, there’s no need to submit a manual bug report for crashes! Let the system do its thing. If you remembered some details after the fact that you want to tell us, then go ahead and file a report. Of course, if the auto-crash reporter didn’t load up for whatever reason, that’s a good time to file a manual report.
Tell us who you are and what you know. We really appreciate users who enter their email and comments into the crash report form. It gives us a way to contact you to get more information. This was invaluable to me when attempting to fix the joystick issues earlier in 10.10. A handful of really helpful users made the research a breeze.
Stop staring at the fps counter! It seems that many users are obsessed with their fps counter. “It went up this beta. It went down this beta. It stayed the same this beta.” Yes, the framerate is ONE useful metric to determine the software’s performance but it’s not the ONLY one and often it’s not the right one. Turn it off and fly! Enjoy the simulator. Sometimes there’ll be a bug in one beta that increases fps as a side effect because the sim is no longer drawing what it’s supposed to. Suddenly, some users are thrilled to see a 20% boost in performance and perhaps they don’t notice that half of the usual streets aren’t being drawn any longer. Ben fixes the streets and in the next Beta, all of a sudden they lose their 20% performance gain and are outraged that we “broke things again.”
If you haven’t run beta 3 and already been told so, X-Plane 10.10 beta 4 is out. Hopefully we have a beta stable enough for it to last more than 48 hours.
The ability to draw the inside of your Plane-Maker fuselage is going away. In X-Plane 10.10 beta 4 you will still see this geometry if your airplane uses it, but:
There is no option to enable this in Plane-Maker anymore and
If you save your airplane in Plane-Maker, the feature is turned off.
I’ve blogged about the path to removing a feature before; the basic idea is that we are not forcing you to update your airplane now, but the next time you go into Plane-Maker to do work on your plane, you will have to fix your use of interior geometry too.
If you really want your interior to look exactly like your exterior, but inside out, it’s not hard to get this effect:
Export your airplane as OBJs from Plane-Maker.
Open the fuselage in a 3-d editor and flip the faces.
Attach your new “interior” in Plane-Maker.
Here’s the overall LR viewpoint on Plane-Maker and drawing:
OBJs are the way to draw an airplane. OBJ provides all of X-Plane’s rendering features, really good performance, a stable file format, and good tools to edit.
Visualization of the built-in Plane-Maker geometry is good for simple planes and experimentation, but it is not at all meant for serious graphic work.
We will not be adding any of the new rendering features to Plane-Maker’s “built-in” drawing.
We don’t think “I can’t draw X without an OBJ” is a problem; use an OBJ.
In other words, we’d rather focus our effort on a single drawing path, OBJ, and not invent a parallel, inferior second drawing system using Plane-Maker beyond what’s needed to simply say “there is my airplane.” Thus we are not adding new drawing features to the Plane-Maker geometry.
When I saw this near KMSY in New Orleans my first thought was: oh hell, what bug created that? All of the roads seemed to run over these channels of water, as if someone had created mini-rivers for them. I assumed bad OSM data.
Then I looked the area up on Google and…no, they actually built the road over water intentionally.
X-Plane 10.10 Beta 3 is here. To avoid having to type it each time, all of the info about betas is now on the release notes page here. Please read it carefully! Please: no bug reports on the blog, only on the bug report form!
You may have noticed the large number of joystick-related bugs in X-plane 10.10, something that is unusual for X-Plane betas. There is a reason for this: Chris totally rewrote the joystick IO code from the ground up for 10.10. We had been living on the same old dubious code for perhaps 5 years before; the new stuff is literally brand new.
Chris is working through the joystick bugs at a pretty quick pace. We will continue to push betas frequently as long as there are bugs that interfere with us collecting other bug data (e.g. crashes, joysticks totally inop, etc.); then we’ll slow the pace of betas down to get more fixes in per beta.
What possessed us to send Chris off into HID land on a quest for new IO code? The new IO code is meant to support a number of features, a few in 10.10 but most coming in a future build:
Hot swapping (here now).
Correct hat switch operations (here now).
Preferences bound to more than one stick without resetting (here now).
Automatic configuration (coming in the future).
Better descriptions of the hardware in the UI (coming in the future).
Ability to easily open source the Linux IO code (coming in the future).
The new code sets up a unified interface to the hardware, with the hope of sharing configuration info and being able to open source the low level IO code.
The long term goal is to make it really easy to work with X-Plane joysticks: plug it in, go through the absolute minimum configuration just once, and you’re flying.
What, You’re Not Root???
Linux nerds: X-Plane 10.10 moves from the joystick API to the input API for joystick IO.* The input API gives us a modern interface with better meta data about the hardware. However we have seen cases where the access control list on the “event” device for the joystick isn’t user-readable even when the “joystick” device is.
Chris is still discussing what we can be done with knowledgeable Linux types, but my view is: this seems like a bug. If the device is safe for users as a joystick, it’s safe as an input event source, and it shouldn’t be necessary to make a udev rule and/or chmod the device entry to use the joystick-type device. So perhaps at some point we can push corrected udev rules up into upstream distributions.
But this isn’t something that Chris and I have any expertise in; if you are a Linux X-Plane user and have expertise in the area, please keep an ear open for when we get closer to a resolution on this issue.
(In the meantime, you may have to take the sudo-hammer to your joystick in 10.10.)
* Our preferred interface would be a HID interface, but we don’t have our own HID descriptor parser; we use the OS X and Windows one. There are two show-stoppers to speaking raw HID. One is the lack of a parser on Linux and one is that the raw HID-as-report device has similar permissions problems to the ones mentioned above for weird joysticks, except the permissions are root only all the time.
So some day in the future perhaps we’ll get to reading raw HID (which would give us perfect similarity to Mac/Win) but for the time being we expect to ship on the unified input interface.
***CHRIS’S EDIT*** I _think_ I’ve squashed all kinds of Joystick related crashes and Joystick calibration issues. These are issues where the stick would not move smoothly from one end of travel to the other. I also think I’ve squashed issues where certain devices/axis were just not showing up. If you have a device that’s still having problems with Beta 3…PLEASE FILE A BUG REPORT. I definitely want to know about it. Always include a Log.txt from a sim run that had the device attached.
One of the changes to X-Plane 10.10: custom scenery packs now are tracked in an .ini text file called “scenery_packs.ini” that sits in the custom scenery folder. This blog post explains how the .ini file works and what problems it was trying to solve.
The Old Days
Long ago, in X-Plane 10.05r1 (and every version before it dating back to X-Plane 8) X-Plane would load custom scenery packs in alphabetical order from a folder called “Custom Scenery”. This simple convention was a work-around for not being able to “manage” scenery pack load order.
In the old days, you could change priority of a pack by renaming it and disable it by moving it to a different folder. I have a number of packs called a_Some_Overlay and z_Base_Mesh and I’m sure others do too; I also have a folder called Custom Scenery (Disabled) that I dump stuff into.
Unhappy Installers
The problem with the old way is that users have to manage scenery packs by renaming and moving them. If an installer has installed a pack, it won’t be able to find what it installed again. We started to see this with X-Plane reinstalling the Aerosoft custom scenery packs that come with the global edition of X-Plane; users would delete or reprioritize the pack and our installer would not be able to update the pack because it had moved.
scenery_packs.ini: Explicit Priorities
scenery_packs.ini simply contains a list of scenery packs to load in priority order: top of the file is highest priority. Listing the pack as SCENERY_PACK_DISABLED disables loading entirely.
This means that a user or third party utility can now organize and prioritize scenery without having to rename files. Installers will still be able to find their installations and packs can have their “factory” names.
How Does scenery_packs.ini Get Updated?
What happens if the file system and scenery_packs.ini are out of sync? Here are the rules:
Any scenery pack listed in scenery_packs.ini but not present is removed from the .ini file on load.
All scenery packs present in Custom Scenery but not in the .ini file are added to the top of the .ini file in alphabetical order.
Note that this means that your new packs are installed in alphabetical order relative to each other, but they are installed with higher priority than any existing packs.
We can’t easily install new packs in alphabetical order compared to all packs because all packs may not be in alphabetical order if the packs have been reorganized.
Ways to Reorganize Scenery
There are a few work-flows I can think of to easily re-prioritize scenery:
Edit the .ini file. It’s just a list of files, and can be reordered as desired.
Remove some packs, run x-plane, quit, and add them back. Those packs will go to the top of the list.
Delete the .ini file. The entire file will be rebuilt in alphabetical order.
The Future
Someday I do hope we’ll have a UI to organize scenery, but we don’t have one yet and won’t have one for 10.10. My thinking is that it’s still an improvement to not have to gum up scenery packs with prefixes to control their load order. But this does cause some work-flow changes. (If you want to continue to use alphabetics, simply delete the .ini file after editing.)
