What Goes Where

The moral of the story is: just because I dismiss an idea by email doesn't mean it won't get coded.  In particular, one user requested a generic instrument that could display text from datarefs.  While my initial reaction was "no way", I ended up changing my mind.  The text instrument will be available in 920 - it displays a string as long as the input dataref is of type "data bytes".  The first intended use is to let you build an FMC interface out of generic instruments - we'll make datarefs that provide the display strings.

My initial negative reaction was due to the nature of the request: I get a lot of requests for "can you implement feature X in subsystem Y?"  One of the biggest questions about any feature is: where does it go within the maze of SDKs that X-Plane supports?  So if you specifically want it in a particular place, the answer is more likely to be no.

In particular, most people want feature X in the subsystem they are already using.  So 3-d modelers want a feature in the OBJ format, airplane editors want an ACF feature, panel creators want a new instrument, and off we go.

I can't put a feature into the sim without considering compatibility, and the cost of compatibility goes way up if a feature is in the wrong place in the code.

Put It In a Plugin

A lot of the time my response is "a plugin can do that."  Now I know that that's a blow-off answer; plugins make all things possible, but they don't make them easy.  Not everyone is a programmer.  At the same time, plugins often anticipate sim features by years: consider that the first planes to demonstrate key frames, 3-d cockpits, and per-vertex normals used plugins, with the sim developing the feature later.

My decision to include a text instrument is based on the idea that it makes sense to partition which "SDK" a feature goes with based on the nature of the activity.  As of this writing, custom systems modeling has to be done in a plugin - no other interface provides this.  But panels can be built almost entirely using the built-in panel editor; with 920 generic instruments provide a huge amount of flexibility.

So the purpose of the text instrument is to keep things this way - imagine that an artist is building a panel (using generic instruments) around the datarefs written by a programmer (using a plugin to do systems modeling).  Without the text instrument, the programmer has to write some graphics code (for the first time) and there's one part of the panel the artist can't manipulate.  This is a case where since the artist could already do 95% of the job, it makes sense to expand generic instruments so they can do it all.

(That's not entirely true - there will always be custom displays so complex that they can only be programmed.  But the 920 generic instruments make most things straight forward.)

As a final note to the rant: we are not going to provide any systems modeling capability as part of generic instruments.  Generic instruments are how you visualize the simulation, not how you configure it.

To give a trivial example of why I don't want systems modeling code in the generic instruments: it would be unfortunate if the pressurization model changed because the 2-d panel scrolled such that the pressurization instruments were no longer on screen!