Category: News

A Hail of Bug Reports

10.11 Release Candidate 2 is out – this fixes the constant hail that was showing up in 10.11r1.  If you have 10.11r1 it will prompt to auto-update.

Posted in News by | Comments Off on A Hail of Bug Reports

X-Plane 10.11 and Other Release Plans

X-Plane 10.11 release candidate 1 is now available online – run the installer, and update with the “get betas” button checked to get it.  This is a small bug fix build to get new Japanese strings out; most of these bug fixes were coded during 10.10’s release candidate period but held to keep the sim stable for DVD pressings.  It’s a small update.

EDIT: Please stand by, the upload did not work right – it should be available later tonight.

EDIT 2: Okay – now we are live.

We may do one more small bug fix release (e.g. a 10.12) before we get to 10.20, which will introduce 64-bit and have a longer beta period.  64-bit porting is going well and I am happy with the progress so far.

What About WED?

A number of WED users have reported a really nasty bug: while mousing around, WED would put up a fatal error dialog box and quit, with work lost.  This bug sucks, and what was worse, no one could find a good procedure to reproduce it.  The steps appeared to be “do some work, get a lot of changes ready, click, lose work.”

That is, until now; the other day Chris round the reproduction case.  I now have a fix, so I will try to cut a WED 1.2 beta 2 in the next week.

Posted in Development, News by | 18 Comments

X-Plane 10.10r3 – Go Use It

X-Plane 10.10r3 came out this weekend – go use it!  This is my expectation over the next week:

  • Barring a truly horrific bug, we’ll probably declare 10.10r3 to be the final build of 10.10 and make it live to everyone.
  • We will probably cut a 10.11 bug fix patch within the next week.

Why do I expect 10.11 so soon?  Because there is always one bug that we don’t find out about until we make the rc live to everyone – inevitably one hour after the build goes live, someone reports something that no one saw in development, no one saw in the company, no one saw in beta, that we want to fix.  Murphy’s law is irrefutable.

In the case of 10.10, the rate of bugs coming in on 10.10 has slowed down a lot, so if we continue to fix bugs in rc, we’ll be fixing bugs at a very low rate without moving on to the next thing.  Thus it’s likely we’ll “kick it out the door”, get our one late bug, and cut a quick patch.  We may also get additional localization into 10.11, depending on what we get from our translators.

It looks like the next sim patch after 10.1x (e.g. 10.10 plus any bug fixes) will focus on finishing and shipping 64-bit, hopefully with more autogen coming along for the ride.

As always, please report bugs to the bug reporter, not the blog, and not email; link is on the right.

(A quick side note/rant: my email server kind of exploded a week or two ago – lots of emails bounced, lots of emails were lost.  This is one reason why I do not want bugs by email!  I am always threatening “if you don’t file a bug, it might be lost.”  Well, if you sent me a bug by email, for all I know it was lost.  Please use the bug reporter!!!)

Posted in Development, News by | 11 Comments

X-Plane 10.10r1, Screen-Casts, and Airplanes

First, X-Plane 10.10r1 is out, at least for the next few hours; beta notes here.  There are already two known issues:

  1. 10.10 is not particularly happy with current shipping ATI Windows drivers.  We’re still figuring out what our best path is.  We may have to disable functionality when we identify this driver set.
  2. It turns out I broke the P-180 3-d panel, so we’ll cut a new release candidate pretty soon.

If you create add-ons, please go test this release candidate!  We can’t fix bugs that are not reported, so now would be a good time to find out if your add-on is adversely affected.

Screen-Cast: Engine Settings

While the changes to the starter are pretty limited, Chris and I did spend a lot of time experimenting with the starters on a number of planes.  (The starters are tuned on the 747, C90, B58, P180, and C172.)  So I decided to try a screen-cast showing how to edit the starter settings.

This is not exactly the highest production value screen-cast you’ll ever see; rather it’s something I whipped out in less than an hour while the release candidate was uploading.

If this kind of resource is useful, please let us know.  During the developer conferences, Austin and I did some short hands-on demos; it isn’t hard for us to turn that kind of thing into a screen-cast.

The screen cast and the blog are not meant to be a replacement for documentation; we’re working on that too.  But creating demonstration materials is significantly easier in screen-cast form than document form.

Posted in Development, News by | 16 Comments

The Next Autogen Drop: With 64-Bit

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:

  1. 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.
  2. 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.

Posted in Development, News by | 42 Comments

How Many Aircraft Does It Take to Change a _LIT Bulb?

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!

Posted in Aircraft & Modeling, News by | 15 Comments

Beta 6 and more View improvements…

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.

Posted in News, View System by | 34 Comments

The Views – Updates to a very important system

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.

Posted in News, View System by | 75 Comments

X-Plane 10.10 Beta 3: Rapidly Beating HID Into Submission

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.

Posted in Hardware, News by | 19 Comments

X-Plane 10.10 Beta 2 Is Here

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 | 10 Comments