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.
Ben and Chris:
Your comments regarding ramp start locations for use by ATC and AI seem to point out that several types may well be necessary, and I assume that may eventually be the solution to AI and to ATC starting positions. In my custom scenery packs, and in several others I know of, sometimes it is desired to be able to position an aircraft inside a hanger as a selectable spot, or at another space restricted spot on the ramp. But in many cases, these locations are for small planes, and are not suitable for AI, since all types of aircraft can be selected specifically or randomly for this traffic. I would not like to loose this positioning ability, but I can see that a second super-position category will probably be needed to cope with ATC requirements and AI operation with all sizes of aircraft.
This kind of thing has already been implemented. It’s coming with WED 1.2.
It’s rather unpleasant to have to click “Understood” 50 times on launch. Why not a notification that ATC will be disabled for certain airports in custom scenery where such insurmountable problems arise: once as a dismissible dialog, then written in the log as many times as necessary to point out the culprits.
Imagine if your bank disabled your local ATM (Automated Teller Machine) because there’s a problem in some other ATM at the other side of the continent.
Agreed on having to click on the dialog multiple times. I chose the wrong error function. The right one only complains once per SCENERY PACK, the one I chose complains once per error found. The error has nothing to do with ATC however so disabling it wouldn’t be helpful to anyone.
Yeah, couldn’t but notice the parade of erroneous beacon and windsock positions when I first started up the latest beta! It did appear that the majority of these were occurring in a handful of packages with multi-airport apt.dat files. I suspect the authors are adding the items while zoomed in on one airport layout but the items are being added under another airport in the .wed hierarchy tree without the author taking note of the significance of this. Perhaps something to think about for the WED interface/data validation?
I have converted several of my New York Upstate Custom Airports to a fully WED 1.1b4 managed build from their former generation using a combination of WED 1.1 in conjunction with Scenery Editor 2.04. I have thus far used the global apt.dat files from 9.7 in procuring the individual apt.dat files for several of these airports in 9.7, and have copied these several packs into 10.04 custom scenery to use them there. Could I just as well have used the newer default apt.dat from 10.04 to obtain these files? It appears that the airports in question have identical content, as I look at them, but can the latest (and perhaps enhanced) apt.dat files from XP10 be used without creating a problem?
So… do you intend the error function to complain once per SCENERY PACK or once per launch then write up all the errors of each SP in the log by the next update?
There is another strategy I’d like to throw out there for your consideration, which is to not get the error to complain and require your thousands of customers to click ‘Understood’ but disable the scenery internally if the error is fatal, writing the appropriate error in the log. One enhancement could be to inform of the event while the splash screen is active, hence making it self-dismissing.
For say, 10 SPs used by 10,000 users in ten days, that would be a million mouse clicks saved. Trivial though it may be for an individual, there might be karmic implications for others 😉
The intended behavior is:
– one user visible alert per scenery pack per run of X-Plane.
– one log message per error per scenery pack per run of X-Plane.
I think if we disable the scenery pack, that’s actually harsher; the user can remove the scenery pack if they want, but if we “remove” it for him, then there is no WAY to use the scenery pack until the condition is cleared.
…which forces the user to deal with it by contacting the author or someone who could modify it. Another alternative is to ignore the ramp or windsock within the scenery. But, okay, the plan is the norm, understood.
Yes. The goal is to get the user to take the only action he or she can do without being an expert: tell the author “there’s something weird about this scenery…can you do something about it.”
Re: ignoring it, the issue with any data quality issue is the same: when we provide a quiet and polite message (e.g. just in the log) about a problem, the problem tends to grow and spread in the community. If, on average, authors were more aggressive about chasing down a “clean log” we wouldn’t have to be so noisy while running, but years of X-Plane point to the contrary.