Departures and Arrivals, Lua Bug Fixes, G2 Controllers, and Stuff

Every week for the last ten weeks I’ve thought “I should really write a dev blog post” and then…not done that. This isn’t because all is quiet on the Western front – on the contrary, everyone on the team has been really, really busy, and the dev blog is never the loudest thing shouting for attention. But now we have a new RC available, so here we are.

Mi Memory Es Tu Memory

11.53 fixes one bug, and it’s a rare bug, but it’s “exciting” when it happens. It turns out that if a Lua plugin requests a really huge amount of memory, instead of saying “no,” X-Plane gives the Lua program someone else’s memory. This is not good! If the bank gave you someone else’s money, that’d be a bad bookkeeping error. This bug is too, and the consequences of the bug are typically “really insane stuff happens later,” which is hard to sort out. The plugin that crashes may not be the plugin that requested the memory.

X-Plane 11.53 fixes this – large allocations that cannot be fulfilled are denied, which should cause the Lua plugin to halt the affected script without destabilizing the system.

Script authors, if you’re wondering “now can I allocate a lot of memory in my Lua script,” the short answer is “no.” The longer answer is: when your Lua plugin uses a new version of LuaJIT that can use 64-bit addressing, this limitation will go away via a new plugin, without a change to X-Plane. Since the limitation is in LuaJIT, it’s out of our hands.

G2 Controller Support

Since we were doing a bug fix release, we have included support for the HP Reverb G2. For reasons I don’t fully understand, controller support didn’t “just work” in 11.52, so we had to create a new profile.

G2 users should be able to use their controllers with X-Plane 11.53. However you should also read our KB article for any additional issues with controllers, especially with misalignment. This version also includes a CLI option to adjust this if needed.

Tyler Has Left the Building

After almost seven years, Tyler has joined the ranks of Laminar Research alumnae. You may know him from such hits as:

• The X-Plane 11 User Interface
• X-Plane Mobile’s global scenery
• X-Plane Mobile’s mass multiplayer

He will be missed! It took several weeks just to figure out all the things he maintains.

We Need More Jims

A few weeks ago, we posted a developer opening – I am pleased to announce Jim Keir as the newest member of the X-Plane development team. Jim is already fixing our screwed up code contributing bug fixes and learning the insides and outs of X-Plane’s almost 1 million lines of code. Jim brings our count of Jims up to two, which is still less of a namespace collision than our three Dan*s.

Multicore and Plugins

Most of what we are working on is still in the lab and hasn’t escaped yet. A few weeks ago we did have a discussion with developers in our third party developer Slack channel about multi-core and plugins.

The short story is this: in X-Plane 11.50, Sidney added a widget to the plugin admin window that shows how much main thread time they’re consuming, which in turn reveals how much each add-on is impacting FPS.

Plugin authors responded! Lots of plugins moved their CPU processing time to a worker thread. This is mostly great – other cores tend to be underutilized on high-end machines so this gets us more FPS.

Here’s the concern: a lot of plugins are doing this, and they are each moving work to other cores in their own private way. There is no coordination between plugins, and one day we are going to wake up and X-Plane will stutter because plugins were (just for a frame) using all of the cores and leaving too few for X-Plane itself.

We are looking at a mechanism for plugins to use the background processing system that X-Plane has built in. The win would be that X-Plane could play traffic cop between plugins and the sim itself, and prevent background plugin loading from causing frame stutters.

I will write up a Request For Comments (RFC) as a future blog post, so that a wider audience can comment on this.