I seem to be having the same conversation with lots of third party developers via email, so I’m going to write up some of my recent thinking on Lua – if nothing else, it will save me typing the same thing over and over.

One thing was very clear in the X-Plane 10.20 beta: while authors can’t agree on Gizmo vs. SASL*, the entire authoring community is surprisingly united around Lua as a scripting language – it’s everywhere in the payware add-on market.

But Lua is being used for a lot of different things – and these levels of usage are paralleled in Gizmo and SASL; my opinion on the use of Lua must be qualified by which usage we are talking about.

  1. The simplest level is “datarefs and math”.  At this point, to fully utilize the aircraft SDK, an author needs to be able to create and do very simple math with datarefs – something that is not possible inside an OBJ or panel.**  Right now we don’t have an easy way to do this basic dataref math.  Writing a C plugin and compiling for 3 platforms is a huge hurdle to jump just to wire up an animation to a custom rotary switch.
  2. Gizmo and SASL both provide ‘add-on’ SDKs – custom sound APIs, particle systems, physics, gauges – basically replacement SDKs for parts of the sim’s own extension system where authors wanted more than we provide.  This stuff isn’t Lua at all – the underlying systems are coded in C++ and thus can only be maintained by the C++ developer who writes the Lua-based plugin.  The development cost (in man-hours) to do a particle system in Gizmo or SASL is abotu the same as it would be to build it into the sim.
  3. Some authors have written fairly huge scripts in Lua – for example, doing complete systems simulations or navigation code in Lua.  (At least, that’s what I am told, e.g. the JAR A320 – I haven’t read the Lua scripts myself.)  This is “Lua as language for a huge program.”

This is my current thinking on these three tasks:

  1. Datarefs and math are a great use of Lua – it lowers the bar for authors, it’s exactly what scripting languages in games are meant for, and the underlying code in C++ is finite, limited, and therefore not a maintenance problem.  I don’t know what LR’s relation to Lua, Gizmo, SASL, or scripting is yet, but I have been saying for a while (internally in company discussions) that we need something easier than C for this.
  2. I think that if an authoring SDK is limited in X-Plane, we (LR) need to make it better.  In the most useful cases where people are doing things with Gizmo and SASL, we sometimes have on our road map features to add to X-Plane that are similar.  (But note that these features aren’t necessarily coming soon – authors get a time to market advantage by using these outside SDKs.)  I consider this plugin code to be a possible maintenance problem.  For example, you can write graphics code in a plugin, but it may not integrate well with next-generation rendering engine features.
  3. I don’t see huge plugins or huge scripts as something LR should get involved in.  If you want to make a truly huge or complicated add-on, that’s great, but it’s a big undertaking and it just takes a development team.  I don’t know if Lua is good for huge development; the people who say no (people like me) have no serious Lua experience, and the people who say yes have no serious C++ experience.  So far I’ve only heard from people who have lived on one side of the grass.

Anyway, one thing is clear: having LuaJIT work in a plugin is a necessity for X-Plane now; with 10.20 we’ve sunk the engineering cost to make this happen.  I do not yet know how else (or if) we will leverage Lua.

* Don’t even bother to comment on Gizmo vs. SASL – I will delete any attempts to start a Gizmo vs. SASL discussion so fast that your head will spin around 360 degrees!

** No math in OBJs or panels.  An OBJ is a 3-d model – it is data that you view, not a simulation to be executed!  We do not want to mix visualization with simulation or data with code!

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

8 comments on “Three Levels of Lua”

  1. XP needs a scripting system. Further disadvantages to the multiple Lua plugins are that they aren’t maintained by Laminar hence subject to the availability of their authors (some might view that as a good thing); it’s not system-wide (the plugin must be dropped into every aircraft folder), and yeah, it isn’t tied in very well with XP technology like graphics.

    All modellers want to do is add custom behaviors specific to a particular aircraft and fill in the some of the holes of the sim: 3D rain, sound for significant events and switch types, damage modelling and whatnot. I like what the SDK can do with the XP’s limited FMS when tied-in to Lua. It’s easy to do custom FMS displays, insert or delete waypoints, find navaids or frequencies. However, parsing large files and doing heavy maths to find intercept points, or overriding the autopilot to add missing FMS functions like heading to altitude or DME might be better done in C++ by Laminar with SDK hooks for high level abstract languages like Lua.

    1. Maintained by LR is a double-edged sword. You guys have been waiting for a new sound system from us for … how long? LR is a bottleneck because there’s one of us and a gajillion of you.

      The other double-edged sword is deploy-per-plane vs deploy-everywhere – I am actually a fan of deploy-per-plane because it makes versioning a million times easier. If the plugin is global, it must remain compatible with all past versions, no matter what new feature is desired. Eventually you end up with a ‘major version’ upgrade that breaks things to avoid huge backward-compatibility costs.

      By comparison, if the plugin is per-plane, then that version _never_ breaks even if other planes use newer technology.

      Cheers
      Ben

  2. Pingback: “Three Levels of Lua” by Ben Supnik | Aerosoft Sim News

  3. You should really try to avoid fundamental changes that would make current complex planes broken. The increasing instability of the development cycle is what keeps more developers from working for XP, and also for users it’s a test for patience. I really love XP, and I try to spread the word about it, but sometimes I just wish for a Sim that is simply working, without fearing that it might be broken soon again.

    Take the Carenado A36 for example, which has a Lua driven avionics. I don’t want to be in its developers skin when you tell the public: sorry, you have to rework your plane again, because we did not tell you in advance of our plans. This feel of uncertainty is really bad.

  4. Just to give you a recent example about how suitable LUA can be for huge development projects: The PC game “Natural Selection 2” is almost entirely written in LUA, not just the game logic, but the whole engine, as far as I know. It is probably one of the most moddable commercial games ever made, because the source code and editors are delivered with the game. I think they’ve optimized the speed how the LUA code is executed on the low level as well. And we’re not talking about a little 2D jump’n’run here, this is a triple-A 3D engine with full dynamic lighting and stuff like that. Maybe that changes your point of view about LUA a bit. 🙂

  5. The Lua system is not designed for 64-bit. If it were designed for 64-bit, it should have not any limitation regarding memory, i.e. be able to store data anywhere in RAM, not just the lower part as current Lua is demanding. I think Lua is poorly designed from scratch, otherwise it shouldn’t behave like this.

    I’ve seen several ports from 32-bit to 64-bit without memory issues like Lua has.

    Just my point of view.

Comments are closed.