I originally meant to write a post about deprecation and feature evolution a while ago when I accidentally (and temporarily) broke the way textures are located in scenery packs and put it back. In X-Plane 10.04 betas we are now fighting with apt.dat validation, so the topic is perhaps again relevant.
X-Plane is continuously patched. We put out about 4 major patches a year plus numerous bug fixes for the life of the product. One of the implications of this is that even if we are planning to drop a feature, we can’t just go from “it’s there” to “it’s gone” in a patch, because users get grumpy if their content doesn’t work after a free (and hard to avoid) update. No one wants to pick between getting the latest perf tuning and having working content.
The way we try to cope with this is by easing in sim changes that are necessary in the long term but disruptive in the short term. We try to make the stop light go yellow before it goes red. Here are some examples:
- If we are going to drop a file format, we can set the sim to give one of those nasty “scenery pack” warnings with log info before we drop the file format. Now the developer knows that the file format is going away, but the pack isn’t instantly broken for users.
- If we are going to drop an airplane feature, we can support it in the sim but drop it from the Plane-Maker UI (or new file format). Now authors can’t proceed forward on tech without addressing the change, but old content still works.
- If we find a case of invalid data, we can log it as invalid before we simply refuse to load it.
I originally meant to post this back in 10.02 betas when I removed the code to handle the old (X-Plane 7) texture file location system and discovered that a bunch of otherwise current scenery packs still use it. The new (art asset relative) system has been available since version 8 (that’d be 7 years) but X-Plane never warned that obsolete packages were doing something that was going away, so I put the code back with a warning.
We’re running into another version of this with custom airports that put ramp starts, windsocks and beacons in strange places. I suspect that some of this represents accidental bad data and some of it represents intentional authoring – attempts to use X-plane in a manner that we didn’t quite expect. The need for data validation comes from the ATC system – with ATC and AI planes using apt.dat, weird data causes significantly more problems than it used to.
I don’t know what the final outcome will be – we’re still looking at some of the apt.dat files that fail. But my expectation is that:
- When we’re done, apt.dat files that were flyable in 10.03 will be flyable in 10.04.
- Some apt.dat files from 10.03 will give off warnings in 10.04 if they do things that we consider to be illegal or need to be implemented in a different manner.