In my previous post I mentioned that the scenery tools are separate code with a separate release schedule from X-Plane. This implies that the updates to the tool won’t be in sync with X-Plane. (The same thing is already true for the AC3D plugin and all of the wonderful third party tools that people have written.)
X-Plane’s scenery compatibility strategy is “backward but not forward”. In other words, if you open old scenery with a new X-Plane and it won’t open or looks different, that’s a bug (please tell us). You should never have to modify your OBJs or scenery if they are correctly made, and the definition of “correctly made” shouldn’t get more strict over time.*
Why no forward compatibility? Well, it’s possible to have syntactic forward compatibility (have X-Plane read a file it doesn’t understand because at the time of release the spec didn’t exist) but it’s not possible to have X-Plane display that file with any kind of sanity.
You could say “just leave out stuff you don’t understand”. Well, imagine if we had done that with apt.dat — imagine if X-Plane 840 tried to display an 850 apt.dat by simply skipping what it didn’t understand. Since taxiways are fully replaced with a new code, 850 layouts would have no taxiways at all if shown in 840. This is certainly unacceptable.
The only way around this would be to require all new features to have “fallback” content, e.g. have the file contain two copies of all taxiways. Since the structure of 850 and 810 taxiways are so different, this would basically require the author to do twice as much work…similar problems happen for animation commands, and missing datarefs.
So the content has to be older than the sim. What about tools?
Well, first, I don’t write the tools with forward compatibility. Since they are all free a user can easily get the newest tools to work (in a sane manner) with new content.
The tools do have to support old file formats though – we don’t usually post old copies of the tools (the AC3D plugin is an exception, since old versions work with old host copies of AC3D). Instead the tools are designed to support restricted file formats. For example, the AC3D plugin will export to OBJ7 or OBJ8 – authors targetting X-Plane 7 can export to OBJ7.
WED only exports apt.dat 850 files – this is by design from day 1, and it will not ever be an apt.dat 810 editor. (Use TaxiDraw if you need to do this.) However, as new X-Plane features emerge (and I am sure they will), WED will have options to target future X-Plane versions, or restrict the export to only features supported by older versions, perhaps with a warning if the WED document contains features that will be lost in an old export.
* One problem we have with this is: X-Plane isn’t a strict validator of scenery file formats, so it is possible to have mistakes in scenery that were always illegal by definition of the file format, but X-Plane doesn’t notice at first. When I detect a case like this, I try to make the problem a “warning” rather than have X-Plane quit, so that authors can get information on buggy files without users suffering too much. X-Plane will print only one warning per package per scenery load to keep things streamlined.
