First a quick note: X-Plane 10.10 Beta 11 is now out. What happened to beta 10? It lasted about 15 seconds, from when it went live to when I realized that aircraft were missing and code signing was screwed up.
We’ve had a few of these “beta bounces” where a beta lasts less time than a Plutonium isotope. The basic policy is this: if we cut a beta and it is live on the net at all, even for one second, and we then realize the beta is borked, we cut a new beta with a new beta number. Thus the very short life span of beta 10 – we didn’t reuse the number 10.10b10 when we fixed the problems.
Why not just reuse the beta number? Because we want to make sure that anyone who accidentally gets the broken beta gets the new beta, and to do that we have to bump the version number. Now that X-Plane auto-checks for updates, people get the new beta within seconds of it going live.
Autogen
A while ago I posted a road map for our autogen cities. Part of the work involved improving the road generation algorithm (a lot of which has been done for 10.10, and some of which still needs more work) and part involved new art assets.
Our original plan was to include the latest art assets with 10.10, but we are now planning on releasing the next round of city art assets with 10.20, the 64-bit version of X-Plane. There are two reasons for this:
- The urban assets aren’t entirely done, but they are very inter-dependent. To maximize framerate, Propsman shares as much texture as possible betewen parts of the urban package, so it’s quite tricky to release part of the autogen.
- The new autogen does take a little bit more memory. Not tons more, but for a user on the red line with 32 bits, upgraded autogen might require memory that isn’t available.
So rather than take up Propsman’s time finding a way to cut off and release part of the art assets, only to hear from users that thy are out of memory on OS X, we’re thinking it’s better to get on with 64-bit and release the art assets as a whole on a build that can handle them.
I think we may be able to release the new road pack with 10.10, and a number of other art assets are already in the 10.10 betas – new aircraft, upgraded global terrain, and new lights.
500. 1 to write the new lighting code and 499 to work out the gajillion ways that backward compatibility gets broken!
Suffice it to say, there are a number of major bugs with aircraft lighting and drawing in 10.10 beta 6. Beta 7 is now out and attempts to fix most of them, but I fear there may be at least one more round of fixing backward compatibility bugs in airplanes.
If you have an aircraft (built-in, third party, or yours) that looks good in either 10.05r1 or 9.70 and looks borked in 10.10b7, please report a bug, particularly if the panel and panel lighting is not working.
Why is debugging aircraft drawing so difficult? It’s a bit of a perfect storm.
- The code supports a huge number of individual behaviors. A lot of the airplane drawing code was done incrementally, so even supporting ‘What v9 does’ means supporting the presence or absence of a large number of small features in every combination. You may or may not be using regions, may or may not be using translucency, may or may not be using interior lighting, may or may not be using the 3-d texture, may or may not be using generics, may or may not be using ATTR_lit_level, may or may not be using additive instrument lighting, may or may not be using auto-adjust levels, and I haven’t even started on the per-object check boxes and global OBJ attributes! (This list is a combination of flexibility, combining two complicated systems, panels and objects, and the “little at a time” approach which introduces a number of intermediate authoring modes into the airplane SDK.)
- A number of these options are very quirky. Sometimes they have long running bugs, sometimes they’re limited by hardware, and often using two together produces weird behavior.
- Often the quirks are useful. Rather than avoiding quirky weird behavior, lots of planes take advantage of it. Bugs become new features.
- We didn’t do much in X-Plane 9 to flag, warn, or prepare authors for X-Plane 10. While we knew HDR was coming, X-Plane 9 never flagged or squawked about old authoring techniques, so a “works in v9” plane might work because X-Plane 9 supports lots of old weird stuff.
- HDR rendering (with the deferred renderer) is fundamentally different from standard “forward” rendering (what we had in v9) and thus everything above has to be coded twice.
Ironically, the generous backward compatibility of the panel/cockpit authoring system in the past (including the ability to use all of the intermediate use cases of these features) has made backward compatibility worse now by making the problem space much more complex.
Unity For 10.10
As I have posted before, one of my goals is to make X-Plane 10.10 a stable and final authoring platform for v10 planes – that is, fix all of the rendering bugs so that if your plane looks good in v10, it won’t need any more updates or check-boxes changed. 10.05r1 did not meet this criteria because there are problems with airplane rendering in HDR that an author can’t work around – they are bugs in the sim.
As part of that process I am trying to create a single “right” path for authors to use the panel texture in an HDR compatible way. This consists of:
- GLOBAL_cockpit_lit gives you the newest lighting path. When this attribute is present, lighting is the same for regions and no-region panels, the panel texture is fully lit by HDR, and transparency works as well with a panel as it does with a regular texture.*
- With 10.10 the cockpit object has a full set of plane-maker check-boxes for control over shadowing, LOD, glass, lighting, etc., to make it consistent with the attached objects.
- In 10.10 any attached object on an airplane can use ATTR_cockpit or ATTR_cockpit_region as long as the cockpit texture does too. (This means you can mae your panel texture interior for lighting but reuse the cockpit texture in a glass object for a HUD.)
These features provide for all of the authoring techniques I have seen and work with both HDR and non-HDR. Most legacy airplanes can be updated simply by adding GLOBAL_cockpit_lit to the cockpit object and confirming that check-boxes are correct in Plane-Maker.
Logging Problems
With this beta I modified the non-fatal error reporter to handle airplanes. What is the non-fatal error reporter? You know it as:
Error loading the scenery package:
/Custom Scenery/my_awesome_scenery/
The scenery may not look correct.
Please see the log.txt file for detailed error information.
The idea of this message is that it puts up a single user-readable warning that something has gone wrong, while providing details on every error in the log. Authors can see all of their problems in one load of the sim, and the single dialog box is annoying enough to users that authors can’t ignore the problems.
A few things have changed:
- Airplanes can now participate in these dialog boxes, so we can give you one message that there are several problems with your airplane.
- There is now a “quiet” version of this that logs without the annoying dialog box. This lets us put warnings in that aren’t annoying yet but may become annoying in the future.
- The log output goes through the dev console, part of an effort to unify our logging efforts. You can reopen the log file without quitting or browse the dev console on screen.
I was asked a few weeks ago whether warnings in the log hurt performance, and my unsatisfying answer was “it depends on the warning.” But I can tell you this: any problem in your add-on that causes one of these “non-fatal error” dialog boxes should be fixed! We only use it when (1) there is a definite error in your file and thus it is not parsing properly or (2) you are using a very old technique in X-Plane for which a better replacement has existed for a while and the old technique is going away.
Don’t Overuse Translucency
One last note from the * above; this came up when Tom was working on the Baron, but I see it in third party airplanes too. While you can use translucency with the panel, I do not recommend it for building non-translucent elements.
Example: if you have an annuciator panel with warning lights that can flash then…
- I do recommend that you build the panel in Plane-Maker using panel texture and multiple instruments layered on top of each other. With GLOBAL_cockpit_lit (or regions) you will get correct 3-d and HDR lighting on this panel, and it will color match the rest of your cockpit object perfect.y
- I do not recommend building the annunciators out of clear areas in the panel and layering two polygons in the 3-d object (a back polygon for the back-plate and the panel texture for the front).
Why not overlap 3-d polygons? First, the OBJ format doesn’t provide a good way to overlap near geometry without risking Z errors. Second, and more importantly, you will not get correct lighting by using alpha and multiple layers. The annunciator panel should be affected by 3-d light including the flashlight and shadows from the sun; that won’t work unless you produce a single “baked” annunciator panel in your panel texture. Finally, any time you use alpha in HDR mode, there’s fine print and issues with the lighting, so use it when you really need alpha, not when you can get the job done with a panel texture!
Beta 6 is out and with it comes quite a list of improvements.
We listened to some feedback and decided to bring mouse-look back but in a new and totally rewritten way. Originally, it was removed because as a MODE, it was confusing. Many users would pick it thinking it was “the” 3D cockpit mode and then be horrified that they weren’t able to use the mouse for anything else. Mouse-Look is no longer a MODE…there is only ONE mode which is 3D cockpit mode. This is the mode where you right click and drag to move your head and then use the scroll wheel to zoom…but now if you double right click, the view mode is locked into “mouse-look” so you can let go of your mouse button and the camera will still track the mouse movement. To get out of the mode, just right click again or switch views and it’ll disable. This works for users with a mouse and for users with a trackpad.
Quick-Look views have been fixed so that they now smoothly transition from one preset to another preset within the cockpit – without recentering each time. I do have to make an apology that your existing presets will no longer work with Beta 6 until you go to your aircraft folder and rename your preferences to *_view_prefs.txt. They used to be called *_prefs.txt. They won’t be lost or deleted, X-Plane just won’t see them until you rename them.
One other neat feature to note…it’s a really simple feature but I think it adds a nice touch of realism. As Tom was working on the Baron he said to us that since so many users like to start their planes from cold-dark-cockpit mode, they should have a way of using a flashlight so they can see what they’re doing before they get the plane powered up. What a great idea! So that’s what we did! Most aviators use a red flashlight to preserve their eye sensitivity so in the View menu, you’ll now see a way to Toggle on and off the Red flashlight. You can tie it to a keyboard or joystick button as well. There’s no menu entry for it but if you’d prefer a white flashlight, there’s a command for that as well so you can pick what you like best. Like all of the other fancy dynamic lighting in the sim, the flashlight only works with HDR enabled.
I’ll leave you with a little video demo of it to see while your X-Plane is updating to Beta 6 in the background.
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!
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 |
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 |
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.
