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.
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.
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!
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.
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.]
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!
So I just realized that it’s been a full month since I’ve posted anything on the dev blog, which is a bit ridiculous since we’re working on a ton of stuff for 10.10 and a number of announcements have also come out in the computer industry. I’ll try to catch up on various topics over the next week.
Where Is 10.10???
I’m pretty sure that that’s the money question: where is 10.10? The answer is: we are working on it, mainly fixing bugs pre-beta. When will the public beta program start? I don’t know – that will be determined by how quickly we can knock out some of the current bugs. My view is that it’s a waste of everyone’s time to go beta on 10.10 with known bugs that we can fix without going beta – going beta too soon means users waste their own time reporting bugs we know about, and we are distracted from fixing those bugs with the task of going through the duplicate reports.
64 Bit – Not Yet!
I think we’ve described this road map before, but in case there is any confusion let me be absolutely clear:
X-Plane 10.10 will not be 64 bit!
We have already made significant progress toward a 64-bit X-Plane and we will continue working on this front. But the plan was never to ship 10.10 with 64 bit support. Rather, X-Plane 10.10 ships with a number of changes to our compilers (as well as a ton of other stuff). The next major patch (10.20) will support 64 bit on all three platforms at once, and we will know that any problems will be due to the 64-bit-ness (and not the changes to compiler, runtime, makefiles etc.) because those will have been vetted in 10.10.
The reason to ship 10.10 in 32-bit is to get out all of the other changes we’ve made so far.
What’s In 10.10
This is not a complete feature list – when we do the first public beta we’ll run through our source control log to scrape out all changes. But here are some fairly big things:
Austin is putting new UI into the sim for flight setup and airplane selection.
Roads don’t shoot up in the sky anymore – crazy road grids was always a problem in how X-Plane showed the data, not the data itself. This change may also improve the stability of the sim.
Chris has integrated “breakpad“, an open source automatic crash reporting system. The vast majority of the bug reports we receive are crash reports, and of them, the vast majority are missing critical files we need to understand what crashed. Automatic crash reporting should both save users time in reporting (you just have to click “ok” when X-Plane asks you if you want to send the bug to LR) and let us dig in with complete file information.
10.10 includes faster clouds on ATI hardware on Windows.
This build moves us to new compiler setup – while this is an internal change, it should mean faster load times on Windows.
10.10 fixes some stability problems in 10.05r1. I don’t think the early betas will be great for long flights, but I think 10.10 will in total be better on this front. (But note: a lot of the crash reports we get are due to running out of memory. You can’t run X-Plane at the edge of your memory limits for 10 hours of flight – at some point it will go over. This particularly applies to Mac users.)
Chris has rewritten the low level joystick code; while this was suppose to be ‘just the hardware’ code (with new UI coming in 10.20) it looks like one aspect will go live in 10.10: you can plug and unplug your joysticks while you fly without restarting the sim.
The artists have been working this entire time and we’ve built up a pretty good pile of art assets to ship too – I’m not going to try to enumerate them right now because I’m not up to date on what they’ve created.
Third Party Airplanes
One goal I have for 10.10 is to close out all of the bugs that are stopping authors from converting their payware add-on planes from X-Plane 9 to 10. Some of these are already fixed and some are still on my todo list. I’ll post more about some of the stickier remaining issues in another post.
Last weekend I was in Columbia, South Carolina for the second X-Plane developer’s conference – that is, the US meeting. I’ll try to write that up later, but first a quick note on WED 1.2. We had Tom Kyler on site, and his demonstration of WED 1.2 with the new lego brick objects turned out to be the surprise hit of the weekend. It’s one thing to say “we’re going to crowd-source airports” – it’s another to show the pieces in action.
WorldEditor 1.1 is released, and WED 1.2 is available as a “developer preview” – it’s that developer preview we showed at the conference. A real “beta 1” will be out shortly.
What’s a developer preview? It’s an incomplete beta. In this case we didn’t have all of the features of 1.2 in place, but I wanted to get it out there for people to poke at. Tom set up Seattle using the developer preview, so clearly it’s “usable” – albeit with a heavy dose of caution.
My plan is to get WED 1.2 beta 1 released some time this week, with every planned feature except for “submit-to-Robin”, which he and I should probably test internally a bit while we make sure that WED’s output is solid.
Note that if you are making custom scenery, there’s no reason why you can’t use WED 1.1 for now – it’s finished and stable. WED 1.2 has usability and v10 updates, but overlay editing has been available in WED 1.1 for a while.
After WED
After WED, the next scenery tools priorities will be:
Getting ac3d and Blender 2.49 caught up for version 10 technology. For Blender 2.49, I am trying to merge my hackingchanges with Jonathan’s, so that users of the public scripts can use my v10 mods without having to rework content. I will send these to Jonathan, and also post some of our newer scripts (e.g. autogen-editing).
MeshTool 2.x will write v9 meshes, but a new 3.0 version will be needed to make “v10”-style DSFs; this is on my todo list.
What About That Program That Simulates Airplanes?
It’ll take a bit to get through the scenery tools because we are also mid-patch for X-Plane. 10.10 will be the next “patch” with new features. It looks like we will post a 10.06 first with some new translation files that have come back to us from a number of sources.
We’re in the middle of the X-Plane developer conference here in South Carolina; I’ve had a chance to improve and revise some of the presentations since Mallorca; my voice is totally shot but once it comes back Austin and I can turn some of the talks into YouTube videos.
As always seems to happen, we’ve put a few features into the sim during the conference…why talk about a problem when we can just fix it?
So for the next patch, you can put a shortcut or alias or simlink to a scenery pack into the Custom Scenery Folder, rather than the custom scenery pack itself and that means…
…that the scenery pack can be on another hard drive. This may take the sting out of an orthophoto pack if you run X-Plane off of an SSD.
Edit: to answer a few commonly asked questions:
This is new if you are on Mac/Win and want to use the file-browser-level alias mechanism. Yes, Linux nerds can use simlinks (I was actually surprised that this path works, but apparently it does.)
We are only doing this for scenery packs. Scenery packs are the biggest single thing you can install, so to relieve hard disk pressure we will start with scenery packs. We might allow linking some other pack later, but for now we are not doing aircraft – our goal is to keep X-Plane maintenance simple, predictable, and supportable.
I meant to post this before, but: the new Catalyst 12-3 drivers fix a number of Radeon HD 7xxx-specific artifacts with X-Plane: incorrectly cut-out tree billboards and flashing triangles. So while I suggest latest drivers anyway, this update is particularly useful if you have a 79xx.
