- Creating liveries/repaints needs to remain simple. Repainting a plane is one of the simplest ways to make X-Plane content – this simplicity should not be lost.
- It should be possible to create a livery without copying airplane content. This is desirable for three reasons: (1) efficiency of implemetation, (2) enabling repaints while retaining content copyright and (3) allowing the author to update the core plane without repainters having to re-copy modified art assets.
- If an aircraft package contains multiple aircraft files, liveries will be available to all of them. If the aircraft files represent different configurations (E.g. P&W vs. RR engines) a livery might be appropriate for one aircraft file but incomplete for another. Requested: some way to “limit” a livery to certain aircraft files in a package.
- The tail number is part of the ACF file, but may change due to paint changes of an aircraft. Requested: a way to specify the tail number per livery.
Airline authors would like to give repainters a choice of “cosmetic” (meaning they do not affect the FM) options for the airplane – this would include things like antenna placement and window location, but would not include things like engine selection or winglets. These cosmetic options would be created by the primary airplane author – the livery repainter would simply select the appropriate parts for the livery in question. (For example, a painter creating a British Airways livery would select Rolls Royce engines to match the real world planes.)
Livery Configuration Files
Proposed: a text file in the livery would provide a storage location for additional per-livery data. This file would be a simple keyed record file (like all X-Plane text files). The file wold have a package specific name like livery.txt, not an aircraft specific name, like ba20_livery.txt.
(This is because the livery might be shared across multiple configurations – file-specific liveries are discussed below. However, consider a Cessna 172, offered in two configurations – with or without G1000. This 2-d panel change would not affect repaints, thus the desire for package-wide liveries.)
Livery configuration files could be written by painters, or (more likely), if a plane author provides a “repainting kit” with starter images, annotated UV maps, etc. then a livery configuration file would be provided in the painting kit that would be customized by the painter.
Configuration File Options
If present, a key would specify what ACF files the livery matches for. If no keys are present, the livery can be use for any file. Example:
If present, overrides the tail number for the ACF.
The object mapping would allow the livery to remap what objects are attached to the plane, by specifying a file name substitution scheme. The intent is that the airplane author would attach the “default” objects for a configuration in Plane-Maker, but provide alternate objects that could be mapped.
# This selects to use the "direct_tv.obj" antennas OBJ instead of the regular # antennas.obj. A painter who wants to have the appearance of direct TV on the # plane might include this mapping. MAP_OBJECT antennas.obj antennas_direct_tv.obj
OPEN ISSUE: this could go in one of two ways:
- The above scheme, which lets the painter remap objects directly or
- A scheme in which the primary airplane author enumerates legal combinations and the painter picks from among them. In this second option, the livery might only contain
CONFIG_CHOICE antennas direct_tv
Where the meaning of the option and its legal configs were defined in the ACF package itself.
- Advantages: slightly simpler liveries – livery authors don’t need to know where objects live and what is meant to go with what.
- Disadvantages: whole system becomes more complex, including complexity in the main package.
Ben says: I was originally in favor of choice 2, but Peter has me leaning toward choice 1 for overall simplicity.
Perhaps the livery should contain authoring information, e.g.
LIVERY_AUTHOR John Wharfing LIVERY_COPYRIGHT Copyright 2008, All Rights Reserved.