Dataref Caching Revisited

Earlier this year I wrote about caching datarefs. Back then we only looked at caching single datarefs, which quickly leads to bloated code once applied in a wider context. So here we are again, taking a closer look at caching many datarefs efficiently.

What About Trees

“Are we going to leave those poor little Datarefs here in this horrid, dark, dank, tree-infested — I mean… charming, quite charming, forest?”

— unknown dwarf coder

Continue reading

Configuration File with XPPL

In this blog post we’re looking into using XPPL to enhance a plugin with a configuration file. Working with XPPL’s configuration module is follows this five-step sequence:

1. initialize a configuration context
2. register configuration properties
3. load the configuration file
4. access the configuration values
5. clean up

First, we need a configuration context. Since we will need to keep it alive throughout the whole plugin life cycle, we declare it as static, global variable:

Introducing XPPL

Are you tired of (re-)writing the same boilerplace code for every X-Plane plugin project — over and over again? Well, at least that’s how I felt when I started my fourth or fifth plugin. Sure, I reused a lot of my boilerplate code, but with every project, I refined and enhanced it. Backporting those changes to older plugins became a tedious task though; therefore I started the X-Plane Plugin Library (XPPL).

Cache Your Datarefs

Nearly every X-Plane plugin accesses one or several of X-Plane’s datarefs at runtime. It’s not uncommon to find code like this:

1void set_data(float value)
2{
3    XPLMDataRef dref = XPLMFindDataRef("what/ever/data/ref/we/need");
4    XPLMSetDataf(dref, value);
5}

Admittedly this works. However, there are a couple of reasons why the code above is not the best idea, if you’re seeking to write a solid and well-performing plugin:

Talk to the Log

Making an X-Plane plugin “talk” to us is one of the boilerplate tasks when setting up a new plugin project. X-Plane has its own log file, log.txt, which is found in X-Plane’s root folder. The file gets reset every time X-Plane starts, so there’s no need to rotate or trim it from time to time. As a plugin author, we have the choice to either write our own log file, or to jump on X-Plane’s bandwagon and use its logging system for our purposes. While I can see the benefits of having a dedicated logfile for a plugin, personally I prefer to use X-Plane’s built in logging mechanism – there are technical reasons, but mostly it’s a comfort and usability decision: most X-Plane users will immediately think of the central log.txt file when a developer asks them to provide their log file (e.g. when reporting an issue).

X-Plane Plugin Boilerplate

X-Plane has a well-documented, accessible API, making it relatively easy to write plugins for the simulator. In this post I’m going to demonstrate how a basic plugin boilerplate can look like, and how to build it on different platforms.

Let’s get started with some basics: X-Plane plugins are dynamically linked libraries, which are loaded by X-Plane at runtime. They have to provide an API as defined by the X-Plane SDK, so X-Plane can access the plugin via defined entry points. The API documentation explains all this, and also provides examples for basic and more advanced plugins. For this post I am going to use a very barebone plugin which does nothing except existing in X-Plane.