Green, Yellow, Red

I originally meant to write a post about deprecation and feature evolution a while ago when I accidentally (and temporarily) broke the way textures are located in scenery packs and put it back.  In X-Plane 10.04 betas we are now fighting with apt.dat validation, so the topic is perhaps again relevant.

X-Plane is continuously patched.  We put out about 4 major patches a year plus numerous bug fixes for the life of the product.  One of the implications of this is that even if we are planning to drop a feature, we can’t just go from “it’s there” to “it’s gone” in a patch, because users get grumpy if their content doesn’t work after a free (and hard to avoid) update.  No one wants to pick between getting the latest perf tuning and having working content.

The way we try to cope with this is by easing in sim changes that are necessary in the long term but disruptive in the short term.  We try to make the stop light go yellow before it goes red.  Here are some examples:

• If we are going to drop a file format, we can set the sim to give one of those nasty “scenery pack” warnings with log info before we drop the file format.  Now the developer knows that the file format is going away, but the pack isn’t instantly broken for users.
• If we are going to drop an airplane feature, we can support it in the sim but drop it from the Plane-Maker UI (or new file format).  Now authors can’t proceed forward on tech without addressing the change, but old content still works.
• If we find a case of invalid data, we can log it as invalid before we simply refuse to load it.

I originally meant to post this back in 10.02 betas when I removed the code to handle the old (X-Plane 7) texture file location system and discovered that a bunch of otherwise current scenery packs still use it.  The new (art asset relative) system has been available since version 8 (that’d be 7 years) but X-Plane never warned that obsolete packages were doing something that was going away, so I put the code back with a warning.

We’re running into another version of this with custom airports that put ramp starts, windsocks and beacons in strange places.  I suspect that some of this represents accidental bad data and some of it represents intentional authoring – attempts to use X-plane in a manner that we didn’t quite expect.  The need for data validation comes from the ATC system – with ATC and AI planes using apt.dat, weird data causes significantly more problems than it used to.

I don’t know what the final outcome will be – we’re still looking at some of the apt.dat files that fail.  But my expectation is that:

• When we’re done, apt.dat files that were flyable in 10.03 will be flyable in 10.04.
• Some apt.dat files from 10.03 will give off warnings in 10.04 if they do things that we consider to be illegal or need to be implemented in a different manner.

X-Plane 10.04 Beta 2 and Autogen Control

X-Plane 10.04 beta 2 is out now.  Release notes here; like all betas, you’ll need to run the updater and click “get betas” to see this – it won’t auto-update until we go final.  Report bugs here.  Do not post bug reports on the blog.

A Temporary Outage

The beta was actually ready last night, but iWeb, one of our hosting providers, had a fairly major outage in the data center that the update servers are hosted in.  The servers are now back on the net, so updates should work normally.

Our overall strategy for updates is to spread out the update pool over a few providers so that temporary outages only reduce capacity, not availability.  In the short term, however, we have a lot of capacity at iWeb because their pricing is really aggressive and we had to push a lot of bits for the X-Plane 10.0 roll-out.  This is the first outage they’ve ever had; if we see continued reliability problems we’ll get more aggressive about rebuilding our demo/update mirror.

Controlling Scalability

With 10.04 beta 2, the attached objects on the parking garage facade now shows more or less cars based on the object rendering setting.  This means that if you have a computer that cannot instance and you run with lower object density, the KSEA is going to be a lot less expensive than it used to be.  The facade engine also allows more control over object placement, which Tom was able to use to further reduce overall object count.

Our plan is to include this kind of object density control on all parts of the airport lego brick library so that the amount of “ramp clutter” is variable by user settings.  Chris and I were in the terminal at KCLT waiting for a flight and looking out across the ramp, one thing was clear: there’s a ton of crap floating around the ramp at a major airport.  With variable density objects, authors can put down major “mini-scenes” (e.g. a jetway plus docking position) and we will be able to scale from the minimum objects to make the sim functional all the way up to a ton of clutter for machines with good instancing performance.

What’s On the White Board

I have a white board on my wall with some of the highest priority bugs scribbled all over the place; I like it because it gives me an immediate view of what can’t get ignored, and when I am on the phone I can simply write down an issue that someone brings up.  So far the white board issues tend to be in a few categories: crashes and serious bugs, performance, authoring platform features, and rendering artifacts.

With 10.04 beta 2 I finally had a chance to start killing off artifacts; the taxi lines should (previously they’d get all bent out of shape when they went around sharp curves) and the water shader is better.  (The water shader still isn’t done, but there should be no more hard lines in it.)

At this point rendering errors and performance still dominate the board and my next few weeks of coding.