Blog

Three Levels of Lua

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!