Liveries Part I: Contracts

Any time two independently varying components need to interoperate, a contract is required.

Because X-Plane varies independently of third party add-ons (we release patches, you make new add-ons), any extensible part of X-Plane implies a contract. That contract basically says what legal things the add-on can do and how X-Plane will react.

We have to consider this "contract" with third party add-ons any time we modify the sim, and in some cases it means we can't change things. How this applies to liveries will become clear later.

Libraries and PNGs

There was some discussion on X-Plane.org about whether it should be possible to share and/or override PNGs via the library system independent of their objects. I say "no" for this reason:

The library system connects independent third party add-ons, that is, components that vary separately. Therefore there needs to be a "contract" any time the library is used, between the package requesting something from the library, and the package fulfilling it.

My concern with PNGs is that a library PNG would have to have a fixed layout. But realistically the kinds of PNGs that people want to share get reorganized on a regular basis. In particular, people want to reference the default sceney PNGs. But where we have a contract, we are limited in what we can change, and reorganizing the default scenery is critical to our ability to grow our content. I agree with Aussie's comments on x-plane.org that fixed-layout PNGs don't add a lot of value to the library system.

File System Vs. Text Files

There are a number of design trends in all of X-Plane's third party add-on systems. One is the use of the file system to specify modifications to the sim. For example:

• Put a "cockpit" folder in your aircraft, we'll try it first.
• Some files in the aircraft folder must have certain names.
• Sometimes putting _LIT after a texture causes it to be used as a lighting map.

On the other hand, I've gone a very different route with the scenery system:

• Libraries are looked up via a text file, not via filename.
• In all scenery cases, the lit texture is specified in a text file, not by filename.

What's the difference? Well, the file system way seems to be simpler for most users to understand. The text file mechanism is a lot more flexible. (Consider: we have versioning info in a text file, we can have each line in the text file clearly identify a feature, and so there is no risk of a file name being mistaken for a feature.)

Whether we use file names or text files to control extensions, doing so creates a contract, so we must ask: can we easily extend or safely modify the contract later? Can we express what we want using filenames (or text files)?

In the case of the scenery system, I think we need the full expressiveness of text files. Imagine if we wanted to provide a new kind of lighting that uses a different format of texture. Or a way to control at what time of day the lights get turned on? Or what if we want seasonal varying textures, and the rules for how seasons affect the light map aren't simple? In all of these cases, a file name convention rapidly becomes unworkable.

On the other hand, the airplane system has done reasonably well with filenames. Based on what I see, the problems with airplane distribution mostly come from a lack of features (no livery support, no plugins built into airplanes), not file names as a convention running out of flexibility.