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.
Re scripting, I think Sandy has pretty much already done this – I use the python interface a lot!
Users who find python too complex will probably have little luck with any scripting I think and I say this as someone with zero “proper” programming knowledge. Python and Sandy’s plugin allows you to do pretty much anything, starting with a simple template and just adding the logic of your custom systems.
The big issue with this scripting systems remains the user support. Every week there’s a bunch of new users who wouldn’t bother to RTFM and therefor forgot to install python, sandys plugin, the script or any combination of those.
A shortcut to a working scripting system could be to integrate Sandy’s plugin with the sim more and add some native checking for correct python versions etc on the user’s computer. That could hopefully get us past some of the newbie installation confusions and nobody needs to re-invent the wheel.
Oh btw, you mention sounds at the top of your post. Just want to say that if Laminar is serious about attracting FSX users and devs, that’s where the next major development has to come imho.
Thanks,
Nils
Nils – Sandy’s python plugin is great…but…I think it is MORE complex than what I am envisioning. Python is a real computer language, and is thus both more powerful and more complex than what I have in mind. (It also has certain versioning complexities that make distribution more tricky.)
I imagine a scripting system that is significantly LESS powerful and therefore does NOT require installing a run-time, etc.
Re: support, this is my support policy for authoring now (and it’s going to come off as pretty harsh, because it is and it has to be):
Once I know that a part of the sim is debugged, if a user has a “problem” with making third party content, I basically say “I can’t debug your model.” So for example, if a user can’t get his or her key frames right on an animated OBJ, I’m just not going to step in..the tools are there, tons of other people are making them work, and the code hasn’t changed.
I think a scripting system would have to be of similar nature…all you can do is make it simple, make examples, test it so you know it’s not bugs, and then if people can use it, they use it.
At some point the authoring systems cannot become so easy that we have functions like XPLMDoWhateverIWantForMe…creating cutting edge planes will always require some work…so a scripting system should make systems modeling possible and not cumbersome, but it doesn’t have to make it 3-year-old-can-do-it easy.
Hi,
I love Ben’s idea. Why? Because I have some interesting aeronautical knowledge, but cant transfer it into X-Plane, just because I am not a computer programmer.
If we had such a “pilote plugin” and with it, a little program with a nice user interface, allowing to write very simply the required scripts, it would be, I guess, a great revolution and would open new doors too for cockpit builder (like I am) returning from MSFS to X-Plane.
Seems to be the right direction to go. Glad I read this. If it means we can script landing lights attached to gears to have a cutoff / cut-on when retracted / deployed (provided the switch is on) – or things like that – it’d be a nice improvement that most builders could use.
vonhinx