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).

CMake Linux Hack

Beginning with its most recent version (3.25 at the time of writing this post), CMake provides the LINUX variable, which I used in my previous post. Of course, developers on Linux tend to use the version of CMake they can install from their distribution’s package manager. On Ubuntu 22.04 LTS that would be 3.22, and even on the most recent Ubuntu version (22.10) we’re at 3.24 — meaning this variable is not available in these CMake versions.

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.