Scripting: A Line In the Sand

I thought I had already blogged about this, but I can't find the old posts, so here goes. The big question: why can't we have "X" in the OBJ file format or as part of generic instruments?

I get a lot of requests for "more power" in the OBJ or generic instrument system - the ability to play sounds, to do simple math operations on datarefs, more show-hide filters, the ability for a generic instrument to change a dataref in response to another dataref instead of a mouse click.

And invariably I say "No! Go write a plugin!", which I realize is a fairly rude thing to say to a non-programmer. First, let me explain why I say no, and then what we can do about this.

Keeping Systems Separate

These feature requests fall into two broad categories: "systems programming", which is really anything that has a side effect (play a sound, change a dataref, apply some logic), and "visualization" (e.g. a user needs more flexibility to better visualize the sim's state.

I definitely do not want any kind of "systems modeling" code inside OBJs or generic instruments. To give a trivial example: imagine that you could make a generic instrument that would set the generators to on when the landing gear is raised.

What then happens if this generic instrument is off the bottom of the screen when the landing gear is raised? Does the generic instrument get to perform its logic? Both OBJs and generic instruments are fundamentally "visualization" systems - both will short-circuit for performance when they are not visible. If we put systems modeling code into them, then the sim has to evaluate a potentially large number of otherwise unimportant (non-visible) objects and instruments to do system behaviors.

In computer programming, there is the notion of a "model-view-controller" design. The basic idea is to keep the code that changes the model, the model itself, and the code that lets the user see the data model, all separate. Keeping them separate keeps operation consistent - the model does not change its behavior depending on how you look at it, which is very important for consistent simulation.

So for all systems modeling, my answer is always the same: not in viewing code!

Expressions and Visualization

Some requests are simply requests for more visualization complexity - there is only so much you can do with key frames, animation, and a few filters.

I do have to admit that on some level, it is perfectly reasonable to ask for infinite power to visualize data in OBJs and generic instruments.

On the other hand, there would be a real cost to having programming-language complexity in what are otherwise relatively simple-to-use parts of X-Plane (e.g. the simplest model is just an export from ac3d...). My solution for both problems (systems and visualization) is a scripting system, but in the case of visualization, it is about not reinventing the wheel and keeping complexity limited to one place (the scripting system).

Scripting

Plugins have the power to solve all of these problems - they can change almost any aspect of the sim. But they are also very difficult to create; you need to be a programmer who knows a language like C or Pascal, and you need to know how to use the development tool for each platform you want to support. That's a huge amount of specialized knowledge just to customize a few systems.

Basically we need to have a line in the sand. At some point, when the systems to visualize information (OBJ, generic instruments) are not powerful enough, we need to make programming easier, rather than make modeling and authoring more complex.

What we need is a scripting system. The scripting system would provide a relatively simple text-file syntax to do simple scripting of systems and instruments for airplanes.

Such a scripting system should be implemented as an open source plugin; it should not be built into X-Plane. The advantage of this would be:

• Anyone could improve or add features to such a scripting system, not just Austin and myself.
• People could freely customize the scripting system as needed for specific projects.
• By having the code be part of a plugin and not the sim, backward compatibility would be improved - even if the "official" version of the scripting plugin changed, you could always include an older version with your plane that worked exactly the way you want.

Who should work on this scripting system? I don't know. Probably not me -- I am not very good at making simple systems; see also what a complex disaster the panel and instrument system has become!

When a user requests that I add a feature to the generic instrument system, there is an implicit request - that Austin or I take programming time to do the feature. So for now I can only say that if/when I take time to do some of these feature requests, it will be in the form of a scripting system, not as extensions to the generic instrument and OBJ systems. This will give us better long-term compatibility and extensibility (via an open source plugin) and will keep systems modeling code separate from the visualization system.