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:
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.
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.
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.
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 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.
What happens if the file system and scenery_packs.ini are out of sync? Here are the rules:
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.
There are a few work-flows I can think of to easily re-prioritize scenery:
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.)
See here for release notes with a list of bug fixes, and file bugs here. (BTW, if you are going to email one of us to ask if you should file a bug, please just file a bug. 🙂 It’s quicker for us that way and for you too!)
If you already have 10.10 beta 1, simply launch it – the auto-update will kick off much earlier during load. If you don’t have beta 1, you need to run the DVD installer or demo installer and update with “Get new betas” checked.
And if you would be even remotely sad if your computer sprouted legs, stood up, grabbed your USB joystick and threw it out the window, don’t install betas. Everyone will get 10.10 once it is final – install the beta only for testing purposes, not for flying enjoyment!
Just a few quick notes on the 10.10 beta process…
First, we have received well over 1000 automatic crash reports. For those who have not figured it out from reading forum posts, 10.10b1 crashes on startup with some combinations of joystick hardware and its associated software. Chris has a fix for this which will ship in beta 2, some time this weekend.
Thank you to everyone who has clicked “send to Laminar”. Receiving such comprehensive and complete crash data is really really helpful. We get a very clear picture of what’s happening with complete details. Clicking “send to Laminar” is better for us than filing a bug (because the crash reporter is very thorough in grabbing forensic crash data and the crash submission system pre-processes the crash for us, saving us labor) and hopefully it’s easier for you too.
Also, thank you to everyone who has filed bugs on the bug report form! We really do read every one of them, even though we do not reply to all of them. We try to list fixes in the release notes so you can see what’s going on.
Overall behavior re: posting bug reports on the comments section has been quite good, but I will continue to trash bug reports here. I apologize for the inconvenience, but my fear is that if I start responding to bug reports here, it will encourage other users to “file” bug reports on the blog too and then we’ll have a mess on our hands.
To be clear: my goal is not to snuff out negative feedback. This is not “if you have nothing nice to say”. But…most negative feedback really should be a bug report, e.g. “X used to work and now it is broken” really belongs on the bug report form.
I am fixing my last bug for beta 2, which I hope to have cut over the weekend.
***CHRIS’S EDIT*** We’re aware that having a joystick plugged in destroys frame rate…That’s already fixed and will also be in Beta 2.
After a last-minute morning recut (previous beta candidate was missing 80% of autogen, which is actually a great performance enhancement 😉 10.10 beta 1 is available for download to the brave and foolish. Some notes:
To get the beta, run the X-Plane installer/updater or demo installer, pick “update” and check “get new betas”. X-Plane will not prompt you to automatically update your stable 10.05r1 into the unstable 10.10 beta 1.
Finally, X-Plane 10.10 beta 1 is the first beta after a huge amount of code change. If you like to fly X-Plane for fun, do not update your “working” X-Plane install to 10.10; it’s too new and too raw. You can copy your X-System folder (or part of it) and then update the copy.
[Hint: now that we have sym-linked scenery, you can copy your folder minus custom and then sym link custom scenery back into place. Sym-linking is not supported for airplanes and global scenery.]
Here’s another thing that’s new in 10.10: safe mode on startup.
One of the most common sources of tech support is users who can’t start X-Plane because their previous rendering settings crash the sim when restarted. This often happens from maxing out system VRAM or process address space, but it can also happen due to driver incompatibility. The problem that hoses users is that the setting change takes effect on restart, causing a “lock-out” condition.
X-Plane 10.10 knows if it shut down cleanly or crashed; if upon start, it realizes that it crashed, it will offer to run with default rendering settings. This makes it easy to restart an rebuild rendering settings without losing all preferences.
This is not a replacement for improvements in rendering engine stability and 64-bit but it should help for now and will always help for edge cases where a particular hardware combination crashes in a way we’ve never seen.
X-Plane 10.10 is compiling now; in theory it should be up tomorrow morning. Obviously if the build crashes on us before it is uploaded we’ll recut it.
In my tentative list of features from this blog a while ago I forgot to mention that 10.10 has some of the scenery management features I mentioned a few months back during the dev conference in Columbia: scenery packs can be reprioritized or disabled by a text .ini file and they can be on other hard drives.*
To be blunt, I think beta 1 is a little bit gooey and underdone in the center. I think there will be a big difference in quality between the first beta and what we have 1 week later. The main bugs we are interested in early on are regressions, e.g. things that worked in 10.05r1 but do not work in 10.10b1, especially with third party add-ons.
Two notes on bug reporting:
I am going to be a complete bastard about that second point. If you post a bug report as a comment, I will delete it without reading it. If you do this multiple times, I will ban you. We really need all bug reports to go to a single place. When they go to the bug report form:
So: no bugs in the comments section – it’s the best way for all of us to get to a stable, final 10.10 faster. I will post links to release notes and the bug report form when the beta goes live.
* Unix nerds: yes, ln -s works on Unix OSes. The feature here is that aliases and shortcuts made using the Finder/Explorer by non-geeks work too!
While working on the HDR pipeline, I ended up with these. Clearly not what we want to ship, but I do think they’re pretty cool looking.
At this point the only thing holding up a public beta of 10.10 is, well, me. I am currently working on a set of related aircraft rendering bugs, and as soon as I can get the car off of jacks, we can go beta.
One of my goals or 10.10 is to close out the issues that stop payware authors from releasing final conversions of their aircraft to 10.10. By final, I mean conversions that won’t need any additional future editing. Right now X-Plane 10.05r1 has a few bugs that cause v10 to look different from v9, different depending on rendering settings, or just wrong. I want to fix those problems in a permanent manner so that authors can release aircraft and not worry about having to update.
Here are my goals for 10.10, roughly in priority order:
The switch of priority between item 2 and 3 is a fundamental change in priority from what I originally intended for X-Plane 10.
Originally I thought that the best thing to do would be to keep non-HDR rendering as close to v9 as possible, so that at least content would look correct with HDR off.
My new thinking for 10.10 is that we should aim for consistency between HDR and non-HDR modes. Realistically, an author is going to have to make at least a few adjustments in moving v9 content to v10; better to have the cost of rendering engine changes be borne out in a v9->v10 upgrade than to have every v10 airplane require double authoring to cope with HDR vs. non-HDR differences. In the long term, it’s best to not have v9 haunt v10 like a ghost years after authors are making exclusive v10 content.
This begs the question: why is HDR rendering so weird? Why does it look different from non-HDR rendering, and why doesn’t it look the same as v9? What did you guys do?
There are a number of changes to how we render in X-Plane 10, some specific to HDR rendering, and some sim-wide.
X-Plane maintains two separate rendering paths for HDR vs. non-HDR and they are quite different in both what happens at each stage and when the stages occur.
Fixing some of the authoring bugs has required further changing the HDR pipeline to allow for correct rendering. The up-side of this change in pipeline is that the new one supports better HDR tone mapping and possibly even better fill rate performance. The down-side is that it’s a lot of complex code to touch and it may take a few betas to work out the bugs.