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.
- Be objective, not emotional. No one hates bugs more than we do but writing a rant instead of a bug report may make you feel better, but it makes me grumpy. And when I get grumpy, I attend seminars…and when I attend seminars, I feel like a winner. And when I feel like a winner, I go to Vegas…and when i go to Vegas, I lose everything. And when I lose everything, I sell my hair to a wig shop….Don’t make me sell my hair to a wig shop.
- 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.
View Larger Map
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.)
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!
Posted in News
by
Ben Supnik |
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:
- No bug reports on the blog. Bug reports go here! Please, no back-door bug reports via “is X still broken”? When it’s fixed, we’ll release note it.
- Speaking of which, release notes here!
- As long as those notes are, it still doesn’t do justice to how much changed. For example, we spent a lot of time making things 64 bit safe, but since that’s not done, no release note. I had 215 commits to go through for 10.10 – not sure how many everyone else had.
- I’ll try to get docs up (and updated) on some of the new scenery features; further improvements to the rendering engine have put me even farther behind. But a lot of the rendering engine improvements are either for Alex’s use in autogen or just make the existing stuff work better.
- One thing you can tell from the 10.10 notes is that we’ve put a tremendous amount of emphasis on usability; when we looked at 10.00r1 after shipping, we identified a number of areas where using the sim (especially as a new user) just wasn’t fun, easy or welcoming. The new features in 10.10 include those plans coming to fruition, finally.
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.]
Posted in News
by
Ben Supnik |
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:
- You do not need to re-report bugs that are not listed as fixed in the release notes. We try to post long, detailed release notes so that you don’t have to waste your own time repeating bug reports. If it isn’t listed, it means we haven’t gotten to the fix yet. Beta 1 does not fix all bugs we know about!
- Please do not post any bug reports on this blog. Please do not post bug reports on this blog even if you have also filed a bug report. Please only file a bug report on the bug report form.
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:
- One person initially reads all of the bug reports. That means that duplicate bugs are rapidly recognized as dupes, wasting less triage time and helping us understand what bugs occur frequently (so we can fix them first). When bugs go into multiple places then more than one engineer looks at them and a lot of effort gets wasted.
- With the bug report form, we control who it goes to. We can change who reads them if someone is out of the office or overloaded.
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!
Posted in News
by
Ben Supnik |
