So all kidding aside, my iPad arrived today, and it is a pretty cool device. My normal attitude toward new gadgets is “great, more video driver bugs to fix”, but the iPad is exciting.
I’ll blog some other time about why I think the form factor is important and there is a spot for something bigger than a smart phone and smaller than a laptop.
For now I just want to point out that it flies X-Plane; X-Plane for iPad a bunch of new features, including 2-d panels while you fly, 3-d airports with full taxiway layouts, a completely rebuilt user interface, improved sky and water effects, and even some auto-gen buildings.
Also first impressions of the device itself: it’s really responsive. I have tried to surf the web with my iPod touch (which is based on first-gen iPhone technology) and it’s a tough experience – between the small screen, slow CPU and limited RAM. The iPad surfs the web like a desktop. A very light weight, portable desktop.
It goes without saying that this post was, um, inaccurate.
This, however, is real.
I wasn’t planning on discussing this until April 3rd, but some sites have already picked it up, so I might as well explain the why behind it. Simply put: X-Plane 10 will be for the iPad only. I figure that by letting you know now, you can make an informed decision about whether you want to buy an iPad. (Hint: you do!)
This wasn’t an easy decision to make, but here were some of the deciding factors:
-
I spend a lot of my time debugging video drivers, and it makes me very grumpy. You guys seem to think that you can plug anything with copper and wires into your PCIe socket and call it a “video card”. By restricting version 10 to iPad only, we cut down development time by targeting only one GPU.
-
We love everything Steve Jobs does and kiss the ground he walks on. Steve says the pad is magical.
-
The biggest single feature request we get for X-Plane is “can I use X-Plane while operating a motor vehicle.” X-Plane 9’s requirement of 1 GB of RAM, a modern CPU, etc. means that most X-Plane 9 machines are not particularly portable. By making X-Plane 10 iPad only, we can provide X-Plane in a portable format that’s more compatible with flying a flight simulator while driving.
One fringe benefit to cockpit builders: because the iPad is so light and thin, creation of a realistic home cockpit with X-Plane 10 will be easier than ever. Simply take some super-glue, wipe it on the back of your iPad, and simply “stick” the iPad to whatever part of the cockpit you want. It’s so easy a four-year-old could do it!
A few days ago Austin made the recently cut X-Plane 9.45 “final” – that is, it is now the version you get when you update or grab a demo. This (hopefully) ends a sequence of 940 patches that represented a mix of fixing last-minute bugs and breaking and then fixing the throttles for a few add-on airplanes.
As always, if your add-on worked in an older version 9 but is broken in 945, please let us know. I believe the compatibility situation with 9.45 is pretty good though.
Will there be a 9.46? I don’t know, but I think the answer is: “probably”. I found a driver bug (occurs only on OS X) we can work around a few days after 9.45 was cut. We maintain a list of fixes, and when it starts to add up, we’ll cut a new patch to address them. Normally a driver bug would get a patch immediately, but from what we can tell, this one is very rare, so we’re not going to fire-drill and cut a new patch 1 day after 9.45 went final.
What kinds of bug fixes make it into these “bug fix patches”? To give an example, I received a report that the “clipping” checkbox on instruments is not preserved when you export an instrument as a text file. That’s the kind of thing we’ll fix in a patch, but we won’t cut a new patch immediately for.
A few quick notes on the various betas floating around:
-
X-Plane: with the 9.4x series we are trying to fix small one-off bugs and improve stability. The BK-117’s throttles will be fixed in the next beta, and we fixed a crash with a third party orthophoto scenery pack.
This goes for any beta, but: if you have an add-on that used to work on an older build (especially 940) and it does not work, please report this immediately! There are no intentional add-on compatibility breaks in this patch.
-
WorldEditor: apparently developer preview 2 doesn’t contain the latest texture coordinate editor (TCE) code, so I will try to cut a preview 3 soon. The texture coordinate editor is a new small editor that lets you specify the texture placement on draped polygons. This facility lets you create custom markings. (The current TCE in preview 2 apparently doesn’t have snap to grid and a few other useful features.)
What’s holding us back from a real beta? The problem is that the DSF export of draped polygons cannot split bezier curved polygons (especially with texture coordinates) across the boundaries of DSF tiles. Since I don’t have an algorithm implementation for this yet, I’m not sure how soon I will be able to fix it. For now, don’t try to export a DSF polygon that spans DSF tiles.
-
MeshTool 2: beta 4 seems to be a keeper. I hope to cut an RC some time in the next week. (You can see the results of MeshTool 2.0 in these FranceVFR preview pics.)
This is my 500th post. I put off posting it all week because I wanted to post something lofty and clever. But in the end, the great is the enemy of the good – if I wait until I have a really good post, it could be weeks before I have time to write a 6000 word treatise on the relationship between quantum physics, shaders, and the price of crude oil.
The decision to publish less now or more later always comes up in software release planning – once the resource budget for a project is fixed* the only choice is ship sooner with less features or later with more features.
With both X-Plane and WorldEditor we often choose “ship now with less” for a simple reason: we are going to ship with more later, but if we ship now with less as well, people get some benefit in the meantime. WED is a perfect example: the first version could only edit airports, and shipped almost 18 months ago. Had we waited until we had overlay editing and airports, we would have had a more impressive release, but authors would have had no editing at all for 18 months. Why force the people who want to edit airports to wait 18 months for overlay features?
(An assumption in this is that the cost of actually doing a release is fairly low. Obviously we don’t want to do a new release every single week!)
There is a contrary force that might argue against frequent releases: once we change a feature to make it better, users are surprised if we don’t make it perfect. Users assume that if we fix some bugs in a feature but not all bugs, that it’s because we didn’t know about the bugs we didn’t fix. (The truth is usually that we had limited resources.) This produces a very strange situation where users are sometimes happier with a product that is less featureful/more deficient/more buggy because a small improvement in real functionality introduces an expectation of a large improvement.
A second behavioral phenomenon amplifies this: in my experience users consider new bugs to be significantly “buggier” (for lack of a term) than bugs that have been around for a while. This is perfectly understandable: humans are very adaptable and we get used to a bug over time to the point where we may not consider it as “bad” as when we first saw it. Trade the old bug for a new one, and we have to become re-acclimated.
These two behaviors argue (particularly when bugs and limited functionality are involved) to make a small number of large changes that move an aspect of the program from one ‘stable’ configuration to the next.
* If you think that more resources can break this trade-off between features and a quick release date, I strongly recommend “The Mythical Man Month“. The short version: 9 women can’t have a baby in 1 month – if you want a quicker release you have to do less.
I’ve been very busy with X-Plane feature development…when the blog is quiet, usually something interesting is getting coded. (Actually this weekend, I’ve just been sick in bed, so…hrm…when the blog gets quiet, perhaps I am infected.)
Just a quick note: if you see any kind of spam or vandalism on the wikis, please let me know immediately. The wiki engine we use (mediaWiki) has some fairly advanced anti-attack capabilities, but they need to be brought in when a problem occurs. Over the last two weeks I’ve cleaned out repeated attacks on the SDK site and one attack on the main site, and it appears that the software installed now is working.
But if more attacks come in, the next step is filting, e.g. programming the wiki to automatically reject posts based on typical off-topic keywords like certain ED drugs, etc. So if you see a post like this, please let me know – I’ll kill the post and set up the anti-spam filter.
Palm announced 3-d gaming for the Palm Pre! Some big names there…Need for Speed, Monopoly, the Sims 3, X-Plane — hey!! Laminar Research?!?! Who let those hacks in!??
I have the original Palm Pre (not the newly announced Palm Pre Plus) and flight is quite smooth! Thanks to the Palm team for letting us in on the roll-out.
Happy New Year! This entire post is going to be off topic, but hopefully worth it; I will resume the usual ranting about how video cards are slowly turning our brain into string cheese later.
I think my favorite part of working for Laminar Research and being part of the X-Plane community is the friends I have made in the X-Plane community – X-Plane really does bring a great group of people together. While I lived in California, I met Jay Oliver, and actually lived not too far from him while I was in ATC school.
Here’s the thing about Jay: he is a fabulous musician. In an age where music is “produced” and so much of what we hear is digitally manipulated, there’s a lot to be said for listening to a human being who is simply astoundingly good with his or her instrument. It’s an experience that can’t be synthesized. It was always enjoyable to get a few drinks into Jay and put him down in front of the Piano and then just listen.
I’ve been listening to Jay’s new album for a few days now, but Austin beat me to the punch, putting it on the X-Plane announce list. Jay set up his new website here, and his album is available for sale in CD or DRM-free mp3 format. You can also listen online right on the site.
Austin’s usual diet is highly electronic, usually runs at about 180 beats per minute, and is the musical equivalent of shooting Jolt cola directly into your brain. What Jay does is completely different, and it’s really something special.
Let me set the record straight on this: you should not need to re-save an airplane to have it work in a newer version of X-Plane. If you have to do this, X-Plane is broken … please report a bug!
(In the case of 940 – there is a big fat bug – see the end of the post.)
Here’s a little bit more about what’s going on under the hood.
When Austin creates a new revision of the acf format (which happens in virtually every major patch), he handles backward compatibility with old aircrafts in one of two ways:
- He sets the default value of a setting to match the “unused” value in the old ACF file and sets this default value to match the legacy behavior. This naturally initializes all newly introduced functionality to its “backward compatible default” for old airplanes.
- Where this is not possible, he writes some conversion code that maps old ACF values to new ACF values. This mapping tries to re-create the old systems functionality as closely as possible.
This forward conversion code runs in two cases:
- When you open the airplane in Plane-Maker.
- When you open the airplane in X-Plane.
Plane-Maker will resave the plane in the newest format, with the automatic system updates in place. But this should not be necessary because X-Plane applies the same automatic process on airplane load. This is why you should not need to resave – X-Plane will do the upgrade “on the fly”.
Now about that bug…it turns out that 940 incorrectly updates 930 airplanes – the generator amperage is not correctly initialized. This is why 930 planes will run their batteries down in 940. (This bug was fixed in 941 beta 2, btw.)
What was strange was that, because of the way Plane-Maker’s code was structured, this code was failing in X-Plane but succeeding in Plane-Maker. This doesn’t happen very often (usually the code fails everywhere) but the result was authors noticing that their planes would start working if resaved in PM.
And that brings me back to the beginning of the post. If Plane-Maker can update the airplane but X-Plane cannot, that’s a bug! Please report it as such.
I want to make sure people realize that auto-update should work, and that resaving in Plane-Maker should not be necessary. Otherwise authors will start silently resaving their airplane instead of reporting the bugs, and we’ll never find them.
(Systems bugs sometimes only show up with a particular combination of systems settings. So while I do hope that we can catch all such bugs in beta, it is always possible that one peculiar model will induce a bug once the sim is released.)
