(Example of a tabber)

I'm the kind of person who closes programs running in the background. If you Cmd-Tab on my Mac, you usually see three programs: Finder, because thats what runs the Desktop, you can't close it, QtCreator, because that's the tool I work with and Chrome, because I've always 5-10 open tabs of documentation and reference manuals.

On Windows, I used to be a "systray-nazi". No one f*cked with my systray! If you were a program and you installed a "speed launcher" in my systray, you got nuked from my harddrive immediately.
Today, even with 8 Gigabytes of RAM, I still close every process and service that I don't need right now, even if it needs only 640k.

And that's a principle that applies to my whole life, not just to my computer. I'm the kind of person who gets nervous when he owns too many things. Every thing I own is like a background process running in my brain, occupying 640k of memory to remember where I left it.
Using a little kitchen sink psychology, I assume this comes from me losing a lot of things when I was a child. I was always scatterbrained, and every week I would forget something, lose my pencil case when changing classrooms, forget my phone card (no cell phones these days!), forget my lunchbox, lose the gym bag on the bus and forget the writing pad with my homework. The latter was particularly annoying, because I didn't take homework assignments too seriously anyway, so then I had ACTUALLY DONE my homework but forgot the goddamn pad or folder at home. I grew up getting more aware of the things I have to look after, and me coming home with my mother looking at me saying "where did you leave your X?" became more rare an event.

("You what?" I lost my yo-yo. "Well where did you have it last? "Eh! If I knew that... I'd still have my yo-yo.)

But this came at a considerable waste of computing power in my brain.
Right now, I have kind of a list of all the things I own in my head, and I know where each of these items is. Each item on that list is like a background process, because it occupies a little bit of my brain. Perhaps 640k. And you know what I do with background processes, right?
That's the reason why I hate this list becoming too long.
So I try to not have too many things I don't really need.

Actually, there is exactly only one item that I really, really, really need. And thats the RSA-key for my repository server. I've stored that quadruply redundant on every harddrive and USB-pen that I have. If the whole building burnt down, leaving me with nothing but what I have in my pockets, all I need would be a computer with internet connection, and I could resume work. If and only if my apartment burns down at the same time my hoster goes out of service, I'd be in trouble.

Why am I writing this stuff? Because I today decided to kill one of those brain's background processes of mine, and get rid of a thing that's been getting on my nerves for a long time. I decided to sell my car. Since I've moved to Frankfurt, this thing was parked for two months. Not moved an inch. I live 300 meters from the train station now. Yesterday I was forced to start my car and drive a few kilometers. The goddamn thing runs worse than a cement mixer, because the mass airflow meter is fried. I have no idea why, it worked okay last time I checked. The spare part isn't expensive. Replacing it is so easy, even I could do it. But I don't want to dedicate a single thought anymore to this thing. So I came back home today, parked the car, went up to my apartment, switched on the printer, printed two "FOR SALE" signs, went down to the car and put them in the rear windows.

I however did bother a few minutes to browse the usual used car websites to look up an adequate price. And I realized that this thing has cost me more than 4000€ since I bought it, only for owning it, not driving one kilometer. Not including tax. Not including insurance. Only loss of value. And by the way, gas is currently $8.05/gal (€1.64/ltr) in Germany.
What few people realize, is that the TCO of a car is obscene. And loss of value is the biggest factor. All people talk about this for computers or smartphones, but with cars it's much worse. A car is even worse than a Windows PC in this respect.

Here's the deal: For the money I save by not having a car, I could easily afford a "Bahn Card 100". That's a yearly subscription for the german railroad system. You pay about 3800€ per year and then you don't have to buy a train ticket, you just jump on any train and go wherever you want. Many people think 3800€ is expensive. It's not. It's cheaper than owning a car.

And I don't care about broken mass airflow meters anymore. I don't care about having to change tires. I don't care about having to find a parking spot (a REAL problem in German cities!). I don't care about gas prizes going up and down.
This frees up so much resources in my brain, it's incredible.
Plus, I can read stuff while going somewhere. Try that with a car

Next up on the list of things to ged rid of (2 of n): my new Dell Notebook. It's fast, it's shiny, and I bloody hate it. Because Dell doesn't know how to build a good notebook anymore, but that's for a different blogpost. My old Dell Latitude D620, that's a great notebook. I dropped it to the floor a few times already. I spilled tea on it. It has so many scratches and dents, it looks awful. And it's too slow for X-Plane 10. But I love it. Because: It. Simply. Works.

The biggest advance is what I call the no-more-pretzels-technology. The CRJ was notorious for doing awkward things when trying to enter a holding pattern. Entering a holding in what was supposed to be a parallel entry looked more like flying a pretzel.

If you are not interested in software development, you can stop reading here. Just believe me it works great now. If you want to know why, read on.

How does no-more-pretzels work?
It is all about treating object-oriented design as type-design. Just like Scott Meyers says in Effective C++ (i take it for granted you all have a copy of this book besides your bed. If not, buy it now!) you're not doing object-oriented design right unless you treat class design as type design.

The key to get the holdings right was to solve the confusion I was having about the four types of "course" there are:

• True Track
• Magnetic Track
• True Heading
• Magnetic Heading

If you are passing around courses as numbers (floats), you are in the constant state of wondering "wait, is this magnetic? And what about wind here anyway? Is the wind direction magnetic or true? Can I add a correction with regard to magnetic wind on this true course?".
Believe me, you will screw that big times. My git log shows I touched the holding and holding entry code a gazillion times correcting such problems.

Now types to the rescue: A true track is not a float! A true track is a type! And a true course is a different type!

So here's how it works: You can't compare a true track to a magnetic heading. Because there is no operator for that. You can't add a magnetic wind correction on a true heading. No operator for that.

Compare this code:

float crs = 315.f; // is this 315 true or magnetic ???
crs += mag_var; // did we just correct from true to mag or the other way?
crs += wca; // did we just convert track to heading or heading to track???

with this code:

// MagenticTrack holding_inbd = 315._degm;  
/* You can do this if your compiler supports C++11 user-defined 
literals, which for now only a gcc 4.7 pre-release does */
MagenticTrack holding_inbd = MagneticTrack::fromDegrees(315); 
WindCorrection wca = WindCorrection::fromTrackAndWind(holding_inbd, 
                                                      wind,
                                                      groundspeed);
// operator+ overloading ftw!
MagneticHeading crs_to_steer = holding_inbd + wca;

More verbose, certainly, but compile-time checked to make sense.

Compile-time checked to not fly pretzels.

Thinking progressive as I always do, I of course built the webserver with IPv6 support, and configured it to always start in dual-stack mode, that means it serves the CDU both via IPv4 and IPv6.
I thought I could relax on that basis, and not touch this code again until the IPv6 address space is full.

I was so wrong!
Reports from customers kept coming in, that they couldn't start the CRJ any more. A very helpful customer showed me a gdb stacktrace of what was wrong. Guess what: it couldn't open a listening socket on 0::0, the "any" IP address in IPv6.
No, this guy was not using Windows 98. He was using the latest and greatest Ubuntu Linux. SRSLY, WTF?! It is 2011 and Ubuntu 11.10 has IPv6 support disabled by default?
Next customer with this problem was using Windows XP. Still the most popular MS OS these days. Guess what, no IPv6 enabled by default!

After instructing those guys how to enable IPv6 on their machines, I coded a patch for the server, to fallback to IPv4 only when dual-stack is unavailable. This is released as the 1.3.1 hotfix now.

I wonder how this planet is going to make the transition to IPv6 any time soon, when about 25% of my customers just can't use it without browsing through cryptic knowledgebase articles...

To compile the CRJ plugin, I need Qt of course, and given this entry in the Qt blogs I thought it would be fairly easy to get this to work.

I was wrong.

First try: I checked out the Qt 4.8 branch from gitorious, and configured with -platform unsupported/macx-clang but I soon ran into a compile error complaining about an undeclared identifier "SetRect".

Second try: I checked out the specific git revision mentioned in the blog post, and re-configured. Build stops with the same error.

Thrid try: Given that the most recent clang is the 3.0 branch and that Apple ships 2.1, I decided to get myself a more recent clang. I checked out the llvm sources via svn, then the clang sources in the appropriate subdirectory, configured for a release-optimzed build (to boldly go...) and make'd. Some 10 or 20 minutes later I had a clang 3.0. I edited the mkspecs/common/clang.conf to point to my freshly compiled clang in /usr/local/bin and reconfigured Qt (I checked out master/HEAD before).  Now the built took longer before it stopped, this time everything of QtCore compiled, but when linking, I got an "undefined symbol for architecture i386: ___eprintf". Oh well.

Fourth try: Google pointed me to this thread which indicated I must built the compiler runtime also. So I did another svn checkout (compiler-rt into llvm/projects/), make clean'd, re-configured and built llvm/clang/compiler-rt again. The built aborted mocking about some missing headers for ARM.

Fifth try: I reconfigured llvm with --enable-architecture=x86 instead of the default --enable-architecture=all, which would built all kinds of backend. The next built took somewhat longer and perhaps 30 minutes later I was ready to try again: with the freshly installed clang I went ahead to compile Qt again. This time it actually linked QtCore, but when compiling QtGui it stopped again with a compiler error:

src/gui/kernel/qt_cocoa_helpers_mac_p.h:218:10: error:
cannot initialize return object of type 'NSString *'
with an rvalue of type 'const NSString *'

Apparently, clang doesn't like Cocoa.

Sixth try: I make confclean'd and re-configured Qt to build with -carbon. Unfortunately, the next make stopped at exactly the same location, at the Cocoa-helpers. Apparently this header is pulled in every time regardless whether we actually use Cocoa or not.

At this point, I decided to give up on OSX and try my luck on Linux.

I svn co'd llvm, clang and compiler-rt to my Suse, configured for optimzed built and started make. Short time after that *KABOOOM!*. No, not a compile error. GCC crashed. My compiler trapped during compiling. Seriously, WTF? I was first confused by the print output of GCC, that referred to a source file that I wasn't compiling at all, until it occurred to me that the indicated source was a source of GCC, a GCC function that crashed.

Oh the humanity! I went to the #clang channel on irc.freenode.net and luckily some helpful soul indicated what I should do. GCC would break regularly during optimized clang compiles. The way to go would be to build clang with clang

1. First, build clang in debug mode without optimizations with gcc
2. Then, use the un-optimized clang to build an optimized clang

Luckicly, this guy was spot on. I had encountered this error that prevents GCC 4.5.0 to build clang with -ftree-vectorize. So the non-optimized built succeeded, and then I was able to bootstrap the optimized clang from it.

I checked out Qt master again and configured with -platform unsupported/linux-clang. Build was uneventful, and my minimal testing-Qt (without webkit, Javascript, QtScript, QDeclarative, etc...) was ready within some 30 or 45 minutes.

Configuring Qt-Creator 2.3 to recognize clang as compiler and display its warnings was straightforward.

Now I took a deep breath and compiled my airnav library on -Wall, which is a lot more pedantic than the -Wall of gcc. And bingo!!
The -Wall -Wextra compile however showed some minor warnings that I've never seen with gcc - it complained about an explicit template instantiation outside the namespace of the template. This was fixed changing two lines of code, and after that I got it through -Werror -Wall -Wextra. W00t!

Lessons learned:

• clang is not yet ready to be used on a regular day-to-day basis and still requires lots of fiddling
• Qt's codebase is relatively clean, as it compiles with clang with relatively few warnings
• the Cocoa headers of the 10.7 SDK however are not
• It is great to have yet another reference compiler to check for code-cleanliness

So I reached at least one of my goals: I have another reference compiler I can test my code against: I regularly compile my whole codebase with Visual C++ 10 and gcc 4. Now I have another testing point that reveals more potential issues (portability, unsafe assumptions).

I won't ship clang-compiled plugins to end-users soon, but I will definitely use clang-build plugins myself now for testing purposes.

There are two types of tech support guys:
-the kind, well-behaved, polite and zealous guy who has absolutely no clue and is following his script
-the grumpy, impolite, nearly-autistic nerd who lacks basic communication skills but knows his stuff

I prefer being handled by the latter. Because he is the only one who can actually solve my problem.

To achieve this, I usually start each call or mail to tech-support by such a mass of geek-level detail that I get escalated to the "puke department" a.k.a. "second level support" fast.

So I considered myself safe when filling out the bug report form for X-Plane with a well-crafted stacktrace from the GNU Debugger, showing the source of a memory error in a Freetype component on OSX, showing up at every X-Plane startup.

I would be the happiest person on earth if I had only ONE customer being capable of using a debugger!

But what happened instead, is that I was trapped for the exchange of FOUR(!!!) additional emails before this apparently got passed on to someone who can actually read debugger output (Austin or Ben one presumes).

Tech supporters of the world:
Please, stop wasting your (and MY!!!) time. If you get a mail from a nerd, pass it to a nerd. AND STOP BEING POLITE TO ME! I want a puke to talk to!

AppStore Lion Screenshot

With the .1 update out, I considered it safe to make the move to Lion.

Upgrade itself was smooth and uneventful, but I have a few complaints:

• I downloaded from the AppStore 3 days after 10.7.1 was out, but it installed 10.7. I had to get the 10.7.1 update separately. Don't they update the installer at all?
• Why the **** did they make the Dashboard a separate space? Luckily you can change this in the "Mission Control" settings.
• It is sloooooow. Going fullscreen is not smooth. Switching spaces is not smooth. Snow Leopard feels fast as hell. The Lion feels more like a Lion on Valium. Or like this one.

Other than that, transition was great. XCode 4 was installed in no time, preserving my old XCode3 installation, however I doubt I will ever start the IDE. I only use the command line tools, in combination with QtCreator.

I recompiled all my stuff with llvm-gcc and I look forward to exploring clang. Using the XCode4 tools however means dropping the support for the 10.5 SDK, which means the next CRJ will only run on 10.6+.

Own website vs established shop

First, let's talk about using one of these platforms in the first place. As a newcomer, using a renowned shop platform is a must. You may think your product is good enough to be sold through your personal website only, you can do marketing and advertisement yourself, and you are trustworthy enough so people send you money.
Trust me, you are most certainly wrong!
Buying immaterial things like software online relies on trust, perhaps even more than buying things in real life.
For the customer, buying on your personal website with Paypal button is like buying a used car from "Honest Achmed" in a shabby backyard, whereas buying on X-Aviation or X-Plane.org is more like going into a big Mercedes-Benz showroom and being served by a besuited official.

Sure, people like Peter Hager may be successful selling their planes through their own website, but few people in our community have earned the trust that every product of theirs is top-notch quality.
So, unless you have a track record like Peter, you should rely on the trust that people have in the big online shops, with the thousands of customers already, various payment methods, buzzing support forums, and the strong feeling that you actually get something for your money.

Now that we have decided we must sell through an established selling platform, being X-Plane developers, our choice boils down to the above mentioned "Big Two".

Shop websites

First, the similarities: Both offer a top-notch e-commerce system with product categories, preview pages, shopping cart/checkout, customer database, the whole enchilada. Both offer your customers the option to checkout either with credit card or Paypal.
Considering the overall visual appearance, the X-Aviation shop website wins. It looks tidier and more "Web 2.0"-like with the customer reviews built in. Also the graphics look sleek and modern, the animation is smooth and unobtrusive.
X-Plane.org on the other hand is more like Amazon or the classic GMail. Rather basic in the visual appearance, but well structured and clear. The icons look a bit 1999 though.

Support forums

Also, both offer hosting the support forum for your product - here X-Plane.org is the clear winner. The "Invision Power" forum software they use is simply great. The moderation options are very intuitive to use. Posting multiple attachments and graphics is done easily. The search function is a bit strange though, as you have to be proficient in using the advanced search options to get good results. The quick search tries to be smart but fails often. Another big plus of the IPBoard software is the mobile version. Browsing the X-Plane.org forums on your IPhone or Android is a great experience and feels like a native app. Browsing the X-Pilot.com forums on a mobile device is a pain, as you are constantly scrolling right and left.
The X-Aviation support forum (X-Pilot.com) is a rather simple forum software that is also less intuitive to moderate.
Update 2011-08-25: X-Aviation also uses IPBoard now, which is a huge step forward in usability of their online community. It is a newer software version than the one X-Plane.org uses. However, I've not yet got my moderator rights back which got lost in the migration process. So I can't comment on the moderation options of the latest IPBoard software. The mobile version however doesn't work at all for me. I tapped the link "mobile version" several times, but still get the standard layout on my Android. I heard from IPhone users that it works great there. I messed up more than one support thread when trying to split parallel discussions in a topic apart and literally spent half an hour getting a thread back together.
A big plus for X-Aviation though is that given their smaller portfolio they are able to provide support themselves, as they know all the products they sell a lot better than it would be possible for X-Plane.org with a total of 435 products at the time of writing.
I have complete confidence that when I'm unable to check the forum myself for a few days, Cameron will take care of all the obvious newbie questions, answer all installation-related issues and leave only the really hard-core questions for me to answer. That is something I can't and won't expect from the X-Plane.org store.

So much for the visible, the "customer" side. On the developer side there are huge differences.

Distribution System and Reporting Software

To put it in one sentence: X-Aviation offers a whole distribution system, X-Plane.org offers only a shop.
Part of the excellent distribution system of X-Aviation is a GTK-based wrapper/installer that works the same on Windows, Linux and Mac. It is very user-friendly and goes hand-in-hand with the activation/copy-protection system. I know very little about the technical details, but I know for sure that this system has an unprecedented track record - I have not been able to find a working copy of one of the X-Aviation bestsellers on any of the usual suspect websites. Sure, every system can be broken, but I think X-Aviation set the bar very high on this. If anything can be improved in the installer, then it would be a detection for the folder the user selected. If it tested for the presence of X-Plane.app or X-Plane.exe to make sure the user selected the X-Plane main folder, it would score 100% on my personal scale. So it's only 99%.
Getting all this to work requieres you only to link a ludicrously small static library to your plugin code. This static library is available for all platforms with the gcc compiler, and now -because of my demand- for Windows also with the MS Visual C++ 9.0 compiler.
When sales begin, you can watch them live on the X-Aviation reporting system. The reporting screen is very intuitive and clear, you get the overview over the total sales and earnings on each day, summaries for each month, and a fancy little graph plotting your sales over time, which is extremely helpful if you want to see the impact of marketing like a paper advert. X-Aviation pays out every two weeks, and you may choose to be wired the money to your bank account or to use PayPal.

Compared to that, the X-Plane.org store is rather basic. It's more or less a way you can sell files. They don't provide an installer, a distribution system, or any means of activation or copy-protection. For many X-Plane products this is sufficient, as the typical X-Plane aircraft consists of a single folder you drop into one of the Aircraft/ subdirectories, and you're done. But as soon as you have to distribute other stuff, like the AIRAC data or additional frameworks your plugin requires, giving only a .zip-file to your customers is no longer an option. I resorted to using InnoSetup on Windows and InstallJammer on Linux. Both are very good solutions, easy to configure and the installers look instantly familiar to Windows users. The InstallJammer wizard panes are based on Tcl/Tk and try to resemble Windows Installer, which looks a bit awkward on Linux. For Mac I use Apple Package Maker, which is a huge pain in the ### to configure. Dear Apple, aren't you the company claiming to have the most intuitive UIs? Then go back to the drawing boards with Package Maker, will you?!
Also, it is left up to you, the developer, to think of a way to protect your software against piracy. The X-Plane.org shop offers a system to distribute serial numbers with each purchase though. You can provide a list of pre-computed serial numbers to the shop, that are sequentially issued with the purchases.
The reporting system of the X-Plane.org store also offers a live view and a month-summary, but it lacks many of the nice computations the X-Aviation system does for you, like the earnings-per-month and the neat graph.
You may also choose to be notified of each single order via e-mail. Which I diverted to a separate account, because it totally clutters up my workflow. Payout is at the beginning of each month, preferred payout method is also PayPal.

User base and marketing

Now on to marketing. First thing to note is that X-Plane.org has a HUGE user base. Based on the registered users, the X-Plane.org newsletter is read by nearly ten times the people who read the X-Aviation newsletter. A single marketing action on X-Plane.org can have huge impact. Also, X-Plane.org often has special offers bundling two or three products to be sold at a discounted price. With more than 170.000 registered users, announcements on the X-Plane.org forums reach a lot more readers than on X-Aviation.
Update 2010-08-25: It is also noteable that X-Plane.org ist the 3rd largest Flight sim site behind Avsim and flightsim.com (which are mostly FSX).
Also according to Nicolas' statistics, users spend more time and view more pages per visit than any other flight sim website. Since Nicolas also runs the Avsim store, I trust him he has access to these statistics and knows how to read them.

All things considered, I have to conclude that you can reach more potential customers when selling on X-Plane.org.

X-Aviation in turn is more like a place where they sell hand-picked jewelry. Less users, less potential customers. But customers that are used to very high quality standard. Probably more potent customers, looking for top-notch software. Your product has to be good to be sold on X-Aviation. If the quality of the X-Aviation users makes up for the lack of quantity I don't know yet.

Summary

X-Aviation: Top-notch, state-of-the-art distribution system
X-Plane.org: MASSIVE user base

No, there's no final recommendation. I'm happy to have my product sold on both platforms. I like Cameron as a business partner as much as I like Nicolas, and I don't care that they don't like each other. Perhaps it's "the mercy of late birth", as a former German chancellor put it, that I never engaged in the turf war between them, because the split happened long before I had my first encounter with X-Plane.

So I encourage any author of X-Plane software to find his/hers matching business partner and continue creating and selling great software!

PS: Unlike to my other posts, I allow comments on this. But when spamming gets too worse, I will eventually close them.

I wanted to play "The Rise and Fall of Ruby Woo" which I had ripped from a CD to my Notebook a long time ago and now transferred from my backup HD.

So I selected the 12 tracks in the folder and double-clicked to open, expecting it would launch iTunes and create a Playlist, or something like that. What I didn't realize was that the tracks were .ogg files, not mp3s (I had ripped them with Rythmbox). Apparently, Google Chrome is the application of choice to play ogg files on my system.

So Chrome popped up, opening 12 new tabs, in each one starting a track, all at the same time.

When closing the tabs, suddenly all the chaotic sound got stuck in a loop and a grey window appeared that I never saw before:

Kernel Panic

Reboot was uneventful and my uptime was already gone with the 10.6.8 update yesterday. I had DiskUtility check for errors though. Luckily, no problems.

I was fixing the display of 25kHz spaced COM-frequencies, where the CRJ 1.0.0 software had a stupid rounding error. I implemented the fix on my Linux Notebook, and was satisfied with the result. I pushed the fix to my git repository, pulled on my Windows PC and compiled again. Starting up the CRJ I had an instant crash with the dreaded "X-Plane.exe has stopped working"-window.

What had happened? To display the value on the small RTU display, I use a well-known C99 function called "snprintf()". It is the safe counterpart of sprintf() (Stream print formatted) that takes an additional argument, the maximum number of characters to be written to the destination buffer. What is great about snprintf() is that it guarantees the output buffer is null-terminated, even if when the output is truncated. And that was precisely what I wanted: The output had to be truncated to 7 characters, 3 characters the frequency before the decimal, then the decimal point, then two digits after the decimal, then the null-terminator. If I put in the frequency as 136.375 it should be truncated so the string reads 136.37\0

Fair enough, now why was the CRJ crashing so violently on Windows? The answer is: Visual C++ doesn't have an snprintf() function. There exist the following two "equivalents": _snprintf() and sprintf_s(). The former was what I used - and guess what - the Microsoft _snprintf() does NOT guarantee the null-terminator!!1!

So the frequency on the RTU read something like 136.375!$Dg=73*+#?§ with some random garbage behind the 7th character.

snprintf() is a C99 standardized function, for god's sake! It's not a GNU extension or a Torvalds memorial function. It's flipping C99 AND C++0x!

Google for the rescue! Apparently quite a lot of people on MSDN have already stumbled over the retarded _snprintf function and there is a workaround that behaves consistent to the C99 requirements:

#ifdef _MSC_VER
#include <cstdarg>
inline int my_snprintf(char* str, size_t size, const char* format, ...)
{
    size_t count;
    va_list ap;
    va_start(ap, format);
    count = _vscprintf(format, ap);
    _vsnprintf_s(str, size, _TRUNCATE, format, ap);
    va_end(ap);
    return count;
}
#define snprintf my_snprintf
#endif

Now that's a kludgy workaround that keeps the CRJ flying...

Instead, this is a "fancy engineering stuff" post.

Let's discuss briefly how X-Plane knows where your planes is. X-Plane, as we all know, calculates the forces that act on your airplane. The force that the engine applies to your airframe, for example. When you think back to your 9th grade physics class, you will recall that force is mass times acceleration. Or in other words, if you assume the mass of the airplane constant, force is a direct measure for the acceleration of your airplane.

Now recall that when you integrate acceleration over time, you get the speed. So by knowing the forces that X-Plane calculates based on the effect of the air on your plane, X-Plane knows the acceleration on your plane, and if you step forward a little discrete timestep ("one frame") and integrate this acceleration over time, X-Plane knows the speed of your plane.

Position (or, more accurately, distance) is velocity integrated over time. So when you progress another little discrete timestep and integrate the speed, you get the distance the plane has travelled. Add this distance to the point where your flight started and voila, X-Plane knows where your plane is now.

Okay, why do I care about this? When developing plugins for simulating, say, an FMC, I come across the need to know several parameters all the time, and these are, among others, position, groundspeed and true track (in X-Plane's jargon called "hpath"). The question I was asking myself was "I can get this out of the datarefs, of course. But could I possibly get this data like the real units do, from accelerometers and gyros?"

So what I tried to do is: Get the position out of X-Plane using ONLY a simulated accelerometer. The accelerometer is easy: X-Plane provides three datarefs to get the three local accelerations (sim/flightmodel/position/local_ax, .../local_ay, .../local_az).

So starting with nothing but an initial position and heading, I set up a flightloop callback that is called every frame, and in each callback I did what I know X-Plane must also do: Integrate the local accelerations twice and propagate from the last known position.

The first approach was like this:

• get speed by explicit Euler integration of the acceleration
• get distance by another explicit Euler integration of the speed
• calculate the Place/Bearing/Distance point from the last known location (in Lat/Lon) by using the last known hpath and the distance I just calculated
• Set this PBD point as the new position and start over

Now this proved to be a bad idea: Position of X-Plane and my calculated position diverged rather quickly. After a minute of flight, I was more than a mile off.

I decided to scratch all the fancy great circle maths (needed for the Lat/Lon calculation), and stay in X-Plane's OpenGL coordinate system as long as I could.

My new approach was calculating the position entirely in this coordinate system and use XPLMLocalToWorld() only as a finalizer when displaying the coordinates.

Much better! I was down to like a mile per 10 minutes of flight. Completely useless if you want to cross the pond based on this navigation, but hey, I'm learning here!

Now I began messing with the integration methods. Explicit Euler is a very rough approximation. I briefly thought about using some pre-calculations and using a Runge-Kutta integration, but then I thought I could just save the last acceleration data in a list and use a multistep method. Adams-Bashfort is the most straightforward to use.

So now I had my setup:

• push the acceleration into the list of acceleration history (and drop the oldest out of the history)
• get speed by an Adams-Bashfort integration of the acceleration history
• push this speed into the speed history and drop the oldest speed
• do another Adams-Bashfort integration, this time on the speed history, which gives the travelled distance
• add the travelled distanced onto the local OpenGL coordinates
• transform to world coordinates and write those to datarefs

The result is w00t! I flew the little Cirrus jet in bumpy weather for like an hour, before calculating the difference between my position and X-Plane's. The difference was less than 500 meters. Now this is a navigation system you can fly cross-the-pond with!

So what is all this about? It's the proof that you can simulate navigation in X-Plane WITHOUT using all the data that X-Plane gives you, but you don't have in real life applications. An FMS in the real world can't ask the plane for the groundspeed (unless you have a GPS receiver, of course), it can only ask accelerometers, laser gyros, air data sensors, etc.
What my little experiment shows, is that you can do this in X-Plane and simulate an Inertial Reference Unit that allows you to navigate based solely on the output of the three datarefs, our simulated accelerometer.

However, there is one small problem you have to catch: X-Plane changes it's openGL reference frame as you travel (everytime you see new scenery being loaded, there also occurs a shift in the coordinate reference). So I need a little trick: Watch the datarefs for the reference point, and if they change, do an XPLMWorldToLocal() transform of my estimated position and overwrite my integrated position with these new local coordinates. Note that this does NOT reset the position to the "true" position, it just changes the reference frame in which my second integration is running.

So now on to even more advanced FMS simulations for X-Plane!