Category: Development

Spam My Wiki, Please

I’ll post more about scenery soon; this will be short and not terribly topical.

The X-Plane Plugin Wiki used to have no login requirements – anyone could just click and edit. All was good for a while, and then I logged in one day to find some of the most highly used pages stuffed to the gills with the phrase “Nigritude Ultramarine” over, and over, with links to other sites.

You can read about this phrase, why it was invented and what was going on here.

Our response was to put a user login requirement on the site, and we haven’t had a spam problem since (knock on wood) although we do seem to get what appear to be bogus signup requests. (They don’t really hurt anything, they just clog the user database. I’m not sure why anyone would sign up if they don’t intend to actually do anything.) But a few thoughts on Nigritude Ultramarine and people’s attempts to get junk spam sites into the top of Google’s search listing:

  • I was pleased to see a real site (this FAQ) as the number two search hit for the term…this real link from a real blog to them can be sort of a contribution to their page rank.
  • I have faith that Google will continue to fight the technology arms race against seach engine optimizers…Google has gobs of money and an immense motivation to do so.
  • Apparently link farmers, in an attempt to raise their page rank, have been using bots to automatically steal blog content. I haven’t seen this myself yet and I’ve never had an X-Plane query go to a junk site. But some blogs I read have complained of this happening.

Only mildly related, there is an X-Plane Wiki, and I’ll try to point people toward it next week; I’ve been posting things there rather randomly in an attempt to get underdocumented stuff written down somewhere.

Posted in Development by | 3 Comments

The Relationship Problem

I just finished about 15 pages of emails, mostly to Andrew McGregor (who is the very first MeshTool user) and also Benedikt Stratmann (whose x737 is on the bleeding edge of plugin-based aircraft) and AlpilotX (we all know about his forests). Probably all three are wondering how the hell I have time to write so much on weekends. (The answer is of course that my frisbee game got rained out. Foo!)

In the meantime, probably about 300 other people who have emailed me in the last few
months are wondering why the hell they have heard nothing from me. My in-box looks like a mail server exploded. It’s not pretty.

So let me blog for a moment about the “relationship problem”. Simply put, there are two of us (Austin and myself) and about a thousand of you (third party developers doing cool and interesting things with X-Plane) plus significantly more users, some of whom have some very weird tech support problems.

In this environment, our algorithm for who gets “developer attention” is pretty broken and subject to total thrash…there is a huge element of random luck (who emails me when I am recompiling the sim vs. debugging a nasty bug).

I’m aware of both how hard the task Austin and I face and how frustrating it is for a third party developer because I’ve been on both sides. Before I worked for LR, I was a third party and I was always astounded that Austin couldn’t remember what we talked about last week.

Then I started working for the company and saw what it’s like. Imagine sitting at a train station watching the trains go by* (at full speed, not stopping) and someone says “last week I waved to you out the window and you waved back, remember me?”

So I would advise three things to the neglected third party:

  1. Be firm – you may need to ping us again because at busy times we can’t always keep track of who has asked for what.
  2. Be patient – if you need something the week we’re burning DVD masters for a second time (because the first set failed at the factory) then you’re going to have to wait.
  3. Don’t take it personally…a lack of a response usually indicates overload inside the company, not a poor opinion of your work!

This blog post has rambled enough, but it may feed well into the next one.

* This analogy is totally stolen from “How Doctors Think” by Jerome Groopman – he uses it to describe the task of primary care physicians trying to spot the early signs of a very rare illness among a fast-moving train of patients who are almost entirely healthy. I strongly recommend this book particularly for Americans – we need to understand the forces at work in shaping the quality of our medical care!

Posted in Development, Scenery by | Comments Off on The Relationship Problem

Things That Are Not Jokes

Just to clarify, these things are not April Fools Day jokes.

  • RC3 coming out.
  • The installer installing to the desktop.

And as always, relax, you will be able to put the install anywhere you want via the “destination” button.

Posted in Development by | 1 Comment

Instaling to the Desktop (Let’s Start a Riot)

I am intentionally announcing a decision that might make experience X-Plane users unhappy – my goal here is to solicit arguments against it (if there are any) since it’s a sort of a strange change.

The proposal is to make the default installation location for a new copy of X-Plane be…the desktop.

EDIT: to clarify some of the blog comments, this is a default installation location; the user will be able to customize both the folder name that is created to contain X-Plane (default will be “X-Plane 9”) and the folder into which this new X-Plane 9 folder will be placed.

The desktop? What are you hacks thinking? Well, here’s what we’re thinking:

  1. Our goal is to minimize tech support calls during installation. This means making an installer where the last computer-savvy users will not get stuck in the installation process. If you know what you’re doing, you’re not who we’re aiming at. (I reiterate, we get a lot of calls about installation problems from users who have never used a computer before.)
  2. We need a location that the user installing X-Plane has access to, guaranteed. That rules out places like the Applications folder on OS X – we expect the least sophisticated users to not customize the install location, so we need one that will work.
  3. We need a location that the user can find. This rules out their home folder (the user may not use their home folder or know it exists) as well as the C drive and the Program Files folder on Windows (both can have their files hidden by default on Windows XP to keep users from breaking tings).

The desktop solves all of these problems. Every user has write-access to his or her own desktop, and every user knows where it is.

If, like me, you don’t want X-Plane on your desktop, you can simply click the “destination” button in the installer to put it somewhere else.

As a final note, the strongest alternative to this on Windows was to put the app in program files and build a start menu short-cut. But this starts the sweater unraveling…if we have a shortcut, we need an uninstaller rather than trashing the folder…if we have an uninstaller, how do we cope with multiple installs…by the time you solve these problems you have a huge amount of new untested code.

I’d like to get a more Windows and Mac interface compliant installer, and we’ll get there eventually, but the work I’m doing now is aimed at the biggest real problems we face:

  • Users not knowing where X-Plane is.
  • Errors during the install in its default configuration.
  • Problems installing and configuring scenery.

Okay, there it is, fire away!

Posted in Development by | 22 Comments

More Threads – the Installer

Nine women cannot have a baby in one month – that’s the classic example that gets thrown around computer science for the difficulty of parallelization – that is, just because we have ten times as many resources doesn’t mean we’re going to go ten times as fast.

Problems of scalability via parallelization have become very important for graphics engines as everybody and their mother now has at least two cores, and users with more serious hardware are going to have four.

I get asked a lot: “will X-Plane utilize X cores…” where X is a number larger than two. My general answer is: sometimes, maybe, and probably more in the future. I can’t make strong predictions for what we’ll ship in the future, but the general trend for the last 18 months has been us using more cores every time we go into a piece of code to do major architectural changes.

I’ve been doing a lot of work on the installer this week – the first major overhaul of the installer since we originally coded it all the way back at X-Plane 8.15. And the new installers and updaters will try to take advantage of multiple CPUs where possible. A few cases:

  • The X-Plane updater runs an MD5 checksum over the entire X-Plane folder to determine which version of the various file components you have and whether they need to be updated. This s not a fast process. I am working on threading this so that more CPUs can work on the problem at once. It looks like there will be only modest benefits from this because the process is also highly bottlenecked on the disk drive.
  • The installation engine from the DVD will use more than one CPU to decompress files. For zip compression this wasn’t very important, but the scenery will be compressed via 7-zip compression to get us down to disk DVDs. 7-Zip compresses DSFs about 10% smaller per file than zip, but it’s horribly slow to decompress, so being able to throw twice the CPU at it is a big win.

Now on one hand, our top performance goals are for the sim, not the installer. On the other hand, faster installations are good. But my main point here is: when we wrote new code four years ago, we assumed one CPU and a nice graphics card. We now assume at least two cores and possibly more, and that informs the design of every new feature, not just the rendering engine. If we don’t create a multi-core-friendly design, we’re effectively leaving at least 50% of the CPU on the table.

Posted in Development by | 5 Comments

When Will X-Plane Stop Saying It Is Beta?

If you look at the about box for X-Plane 9 RC1, it still lists itself as a beta.

Here’s the thing: that label is dynamic. Right now when X-Plane calls up the server to see if there is a new patch, it notices that its current version (900Rc1) is newer than the latest “final version”. (This is because we haven’t declared any version of 9.xx final yet.)

So it thinks for a second and goes “oh – I’m newer than the latest final version, I must be a beta.” And that yellow beta label appears.

When we finally declare a version final (which involves tweaking the versions listed on the servers) the existing code will then look at the server and go “oh, I’m the latest version” and that beta label will disappear.

Posted in Development by | Comments Off on When Will X-Plane Stop Saying It Is Beta?

Version 9 – Probably Too Late

If you have a third party add-on and you haven’t tested it against X-Plane 9, well…honestly it’s probably a little bit too late to fix compatibility bugs now. We’re in RC, and only changes to fix critical bugs are going into the sim; everything else will have to wait for 9.1.

So if you have an add-on and you haven’t tested it against 9.0, for crying out loud, do it now! Submit the bug anyway – if we can’t fix it for 9, we can fix it for 9.1. But…after almost 14 weeks in beta, we’ve got to close this build up.

BTW a minor side note on fuel pumps…

In X-Plane 864, an airplane will run even if the electric fuel pump is off. (However, if the fuel pump failure is triggered and the electric fuel pump is off, either by switch or electrical-system failure, then you’re out of fuel.)

X-Plane 900RC1 restores this behavior; in beta 25, an electrical failure would turn off all sources of fuel. This is wrong for a plane like the C172 where gravity can feed the engine.

In the long term X-Plane does need a more complex abstraction (e.g. does this plane have gravity feed or engine drawn fuel, or engine driven pumps, etc. etc.) but for now the 864 model, while inaccurate and incomplete, causes less problems than beta 25, which was simply wrong for a number of planes.

Posted in Aircraft, Development, Scenery by | Comments Off on Version 9 – Probably Too Late

Installer Theory

Let me go into the installers in a little more detail before I start a mini-riot. Basically there are three “installation” operations that we (Laminar Research) support:

  1. Installing a new full sim from a DVD.
  2. Installing a new demo from the internet.
  3. Updating any installation from the internet.

The problem with the current installer model is that tasks two and three (get a new demo, update an existing installation) are handled by a single application. This means that the web-demo-installer/updater cannot know which choice (2) or (3) the user is trying to do (since both are legitimate) and therefore user error can result in the wrong operation.

The most common problem we have is users installing new demos when they meant to update a DVD install. The result is an old copy of X-Plane with scenery, a new copy without scenery, and a very confused user who has to contact us for help.

The solution I am working on is simple: provide separate applications for all three tasks.

  1. Like before, the DVD installer comes on your DVD. It installs the DVD, nothing else.
  2. A demo installer does nothing but install the demo. You get the installer from the web, probably from the “demo” page (which would have to no longer be an “update” page too). The demo installer always does a full install, and will stop you from trying to install on top of existing installations.
  3. The updater is always fetched by the app and updates the app. Thus the paradigm is that the app is “self-updating” (even though most of the work is done by a helper application). That updater (fetched by the sim) can only update the copy of the sim that fetched it.

Dealing With Problems

The above work-flow is meant to address most users doing the usual thing without technical problems. We must also consider how we will deal with tech support problems, and finally what the impact is on advanced users. There are two cases where we sometimes have to help users out:

  • If the DVD installer for some reason will not work for a user’s computer, we usually provide a downloadable DVD installer. You would insert the DVD, run this “DVD installer” and thus install the DVD. This is not the normal case, but we will probably continue to provide DVD installers specifically for users with tech support problems (based on the tech support incident), just like we have been in the past.
  • We will provide the updater directly for users who need to update the sim but cannot launch the sim. This is the exception case, so a direct link to the updater would not be globally advertised on the main page of the sim. Rather it would be a support link, again only provided to users who really need it. 98% of the user base will be able to update from the sim.

When you run the updater from the web (the support case) it will prompt you to locate your X-Plane folder if needed.

Advanced Users

Will you be able to keep multiple copies of X-Plane around? Absolutely. But you’ll have to manage your operations in terms of the “three operations” (make a new install from the DVD, make a new demo install from the web, update any one version you have laying around).

If you want to get a new web demo, you’ll have to use a separate application than you would for an update. I don’t think this is a huge problem; generally your best bet for keeping an old copy of X-Plane (when running a new beta) is to simply copy the entire X-Plane folder, rather than downloading the contents from the net.

Posted in Development by | 7 Comments

Fun With Installers

So first, if I promised you scenery tools about now (MeshTool, AC3D, or any of the other things I’ve been asked for), please wait two weeks and ask again. I thought Austin would be cutting master DVDs while I would have time for tools, but instead I will cut the DVDs, so tools will have to wait until the masters are done.

To calm any fear: if you have X-Plane 9 DVDs, you will not need to buy new ones. We will be periodically updating our master DVDs (just like we always have), but we’ve taken a number of steps to ensure that everything new since the original “Beta 1” DVDs will be deliverable by reasonably small incremental web updates.

If you are reading this blog, you’re probably an advanced X-Plane user, possibly one who makes airplanes or scenery or even plugins, and you’re probably comfortable with computers and know a lot about the sim. Please bear in mind as I describe some of the changes we’re making in the installer that we have users who have never used a computer before, and purchased their first computer to run X-Plane.

Simply put, the primary goal of the installer is to allow the non-experts to use X-Plane too.

Anyway, with this post I’d like to call attention to a feature that I believe very few people know about (because it was broken for a long time and yet we didn’t get many reports).

You can update X-Plane 8 or 9 from the About Box – when you pick “About X-Plane” the sim will check our update servers for new versions, and if one is found, it will give you an update button. This update button will then download the very latest installer and launch it, setting it to update the copy of X-Plane you were running.

X-Plane 9 beta 25 will be out soon; when it comes out, please try updating by using the About Box in beta 24. Let me know if the process works correctly.

(What’s so great about updating from the about box? Well, one of the biggest tech support calls we get is users who do not successfully patch their existing copy of x-plane, but use the web updater to fetch a whole new X-Plane, which of course has no scenery. When you get the installer from the about box, you always get the latest correct installer, and the sim tells the installer which copy to live. In the future we’ll be removing the “destination” button when you run this way, so it’s as simple as “go”.)

Posted in Development by | 9 Comments

Hardware Profiles

X-Plane 9 currently recognizes (roughly) three categories of graphics hardware:

  • Non-Pixel-Shader hardware (GeForce 2,3,4, Radeon 7000-9200)
  • First-Generation Shader Hardware (GeForce FX 5nnnn, Radeon 9500-9800, X300-X600)
  • Later-Generation Shader Hardware (GeForce 6, 7, 8, Radeon X200, Radeon X700+)

That first bucket is pretty simple: those cards don’t support programmable pixel shaders (as we know them today) and can’t run any shader effects. The “use pixel shaders” check box doesn’t appear in the rendering settings.

The distinction between the later two is a little bit more subtle. Basically the first generation of pixel shader cards (the 9700 and friends) support only 96 instructions for each pixel shader; this puts us right on the edge of sometimes not being able to draw all of our effects; we have to simplify the water slightly to make it work. The next generation of chips (X850 and friends) doesn’t have this limitation.

By comparison, while NVidia cards have been able to handle long shaders from day one, the GeForce 5’s shader performance is really poor.

So we bucket all of these chips as “first-gen”. When we detect this we:

  • Simplify shaders slightly (gets us out of trouble with the 9700).
  • Don’t default to shaders being on when the sim is first booted (because the framerate will probably be unusably slow).

Even though the 9700 provided very usable shader performance in its day, by the standards of modern GPUs, this older chip isn’t that fast, so it’s probably for the best that we not enable reflective water by default on machines with these cards.

By comparison, X-Plane deals with almost all other capabilities on an a-la-carte basis; particualr features are enabled if the right menu of hardware features is available. We do this to try to deal more flexibly with the wide variety of cards that are out there. Some examples:

  • You’ll get hardware accelerated runway lights if your card supports pixel shaders and sprites (virtually all shader-enabled cards have sprites).
  • You’ll get sun-glare effects if your card supports pixel counting (virtually all modern cards can do this).
  • The non-pixel-shader rendering code will show more detail if your card supports more texture units (this is only an issue with very old hardware).

I’ve been looking over hardware profiles a lot lately, and I suspect that the next big “jump” in hardware will be the DX10-compliant cards (GeForce 8, Radeon HD). There’s a lot of fine print in what the various cards can do between all of the pre-DX10 cards; at some point when we decide what menu of features we’ll require for rendering, we need to simplify.

My guess is that when we start to have “really advanced” pixel shaders that require hardware more sophisticated than what we need now, we’ll simply require a DX10 card. Otherwise we’ll have to sort through 8 different profiles of fine print, only to attempt to partially support cards that probably won’t be fast enough anyway.

(That is to say, a feature is only useful for us if it can run reasonably quickly. It doesn’t make sense for us to try to make a special “simplified” version of a rendering feature for, say, the X850 if every X850 is going to turn it off every time for framerate reasons.)

If any of this turns into hardware buying advice, I suppose it would be this:

  • If you are deciding between a DX10 and DX9 card (e.g. between the HD2400 and X1900, or GeForce 8600 vs 7900) go for the newer generation DX10 ards (HD or GeForce 8); if the card has decent performance you’ll also be setting yourself up for future features.
  • As always, pay attention to the fine print of the model numbers, particularly the configuration. Lower model number cards basically have fewer parallel components than higher number ones and that leads directly to lower framerate.

I see an add online for the GeForce 8500 for $70 and 8600 for $90. But if you look at the links below, you’ll see that the 8500 has only half the shaders of the 8600 – that’s going to be a huge performance difference for $20.

(So the moral of this story is: try to get an HD or GeForce 8 card, but don’t dip into the really low end cards because they’re stripped down too far for X-Plane use.)

These pages (NV, ATI) on Wikipedia list specs for a whole pile of cards and can be useful to decode the fine print.

Posted in Development by | Comments Off on Hardware Profiles