Why Not Ignore Problems?

Tom had a good question that others have asked me too: why not ignore missing scenery resources? Why does X-Plane act so cranky?

Ignorance Is Bliss

We have tried the other approach: ignore missing art assets. ENV based scenery in version 7 did not require custom objects to actually be available - missing objects were ignored.

When I was working on the ENV reader for version 8 (the ENV code needed to be retrofit into the new rendering engine) I found to my surprise that virtually every ENV-based custom scenery pack I looked at was missing at least a few of the OBJs that the ENV referenced! I don't know how this happened - it seems that in the process of working on scenery, authors started to "lose" objects and simply never noticed.

Quality Control

When we developed DSF we had a chance at a clean slate: there were no DSFs in existence so we could set the rules for art assets any way we wanted. So we picked the harshest rule possible: any missing art asset was illegal and would cause X-Plane to refuse to load the scenery package, with no way to ignore the error. Why be this rude?

• Missing artwork failures are 100% reproducible - you don't have to try your package more than once to see the problem. If you are missing an art asset, you will have the failure every single time you run.
• The error is found on load - you don't have to fly over the art asset to discover that it is missing.
  
• Therefore if an author tests a scenery package even once, even in the most trivial way, he or she will discover the missing art asset.
• Once the error is fixed, it is fixed forever, so a scenery pack that passes this quality control measure in development will be just fine "in the wild".
• This rule has been in place since 8.0 beta 1 for DSFs, so there are no legacy DSF files that would have this problem.
  

Libraries

There is one special case worth mentioning: a scenery pack might reference an art asset in another scenery pack, and that other scenery pack might not be installed. This is why the library file format allows for "export_backup". (Read more here and here.) Export_backup is your scenery pack's way of sayingg "only use this art asset if you can't find it somewhere else. It lets you provide emergency art-work in the event the other library is not installed.

What should you use as an emergency backup art asset? It could be anything - a big floating question mark, an empty object, a poor approximation of the desired art asset. But my main point is that responsibility for location of art assets lies with the author of a pack - so if you make a scenery pack, be sure to provide backups for any libraries you use.

(If you use OpenSceneryX, the library comes with a "developer pack" - read more here. Basically they already built a "backup" library that you can put in your scenery pack to avoid nasty messages from X-plane when OSX isn't installed.)