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!
I’ll post more about scenery soon; this will be short and not terribly topical.
The X-Plane Plugin Wiki used to have no login requirements – anyone could just click and edit. All was good for a while, and then I logged in one day to find some of the most highly used pages stuffed to the gills with the phrase “Nigritude Ultramarine” over, and over, with links to other sites.
You can read about this phrase, why it was invented and what was going on here.
Our response was to put a user login requirement on the site, and we haven’t had a spam problem since (knock on wood) although we do seem to get what appear to be bogus signup requests. (They don’t really hurt anything, they just clog the user database. I’m not sure why anyone would sign up if they don’t intend to actually do anything.) But a few thoughts on Nigritude Ultramarine and people’s attempts to get junk spam sites into the top of Google’s search listing:
- I was pleased to see a real site (this FAQ) as the number two search hit for the term…this real link from a real blog to them can be sort of a contribution to their page rank.
- I have faith that Google will continue to fight the technology arms race against seach engine optimizers…Google has gobs of money and an immense motivation to do so.
- Apparently link farmers, in an attempt to raise their page rank, have been using bots to automatically steal blog content. I haven’t seen this myself yet and I’ve never had an X-Plane query go to a junk site. But some blogs I read have complained of this happening.
Only mildly related, there is an X-Plane Wiki, and I’ll try to point people toward it next week; I’ve been posting things there rather randomly in an attempt to get underdocumented stuff written down somewhere.
If you have a third party add-on and you haven’t tested it against X-Plane 9, well…honestly it’s probably a little bit too late to fix compatibility bugs now. We’re in RC, and only changes to fix critical bugs are going into the sim; everything else will have to wait for 9.1.
So if you have an add-on and you haven’t tested it against 9.0, for crying out loud, do it now! Submit the bug anyway – if we can’t fix it for 9, we can fix it for 9.1. But…after almost 14 weeks in beta, we’ve got to close this build up.
BTW a minor side note on fuel pumps…
In X-Plane 864, an airplane will run even if the electric fuel pump is off. (However, if the fuel pump failure is triggered and the electric fuel pump is off, either by switch or electrical-system failure, then you’re out of fuel.)
X-Plane 900RC1 restores this behavior; in beta 25, an electrical failure would turn off all sources of fuel. This is wrong for a plane like the C172 where gravity can feed the engine.
In the long term X-Plane does need a more complex abstraction (e.g. does this plane have gravity feed or engine drawn fuel, or engine driven pumps, etc. etc.) but for now the 864 model, while inaccurate and incomplete, causes less problems than beta 25, which was simply wrong for a number of planes.
Sandy and I are working on a major revision to the plugin SDK (all the old stuff will work, we’re just adding new things) that should be available in X-Plane 9 soon. The new “2.0” SDK APIs include some new functionality for working on scenery.
- Plugins can find the height of the ground at a given location, which is necessary to draw in the 3-d world in a realistic way (e.g. vehicles that drive on the ground in a sloped airport environment).
- Plugins can load and draw OBJ files using X-Plane’s built-in facilities. I’ve posted OBJ drawing code in the past, but this makes things even easier.
- Plugins can lookup virtual paths in the library to find artwork from scenery packages.
This makes a number of scenery-system concepts available to plugins.
I’ve been resisting OBJ-drawing support in the SDK for a while, but a few things changed my mind:
- We’ve moved as much drawing in X-Plane to OBJs as possible and it’s been a big win. A lot of the dynamic elements are OBJs, they’re used in scenery and cockpits and airplanes. Using OBJ files means our artists (who are not programmers) can customize just about every aspect of the sim. So by providing a file format with a rich tool chain to plugins, hopefully we are helping third parties streamline content development.
- With pixel shaders, X-Plane’s 3-d drawing environment has become complex and hard for third parties to safely augment. By encoding drawing at a higher level via pre-built OBJs (which can be animated via plugin-driven datarefs) we can insulate plugins from drawing-environment changes.
If you create plugins, airplanes, or scenery for X-Plane and haven’t tried your add-ons with X-Plane, please do so soon!! It’s much easier for us to fix backward-compatibility problems while we’re still in beta. Beta 14 introduced some bugs (that should be fixed in beta 15 real soon) but I think we’re reaching the point where you can do compatibility testing.
We’re working on a public Linux beta – see here.
Read the info here:
//www.xsquawkbox.net/xpsdk/phpwiki/index.php?NewVersionAnnouncement
Please note that if you are a scenery author and not a programmer, this will not directly affect you at all. (But see the section on compatibility – old plugins will still work!)
Version 9 will also feature a lot of new datarefs – this should make things a lot easier for authors doing animation.
The new API will allow programmers to access the terrain mesh. This means that add-ons that want to add dynamic graphics content by drawing (e.g. drawing in baggage trucks) will be able to place that content “on the ground” no matter what the surface of the airport area. I think this will allow for some interesting new add-ons.
