Sunday, December 14, 2008

Liveries vs. Configurations

I want to revisit the question of whether (and how) the livery system should be extended. In particular, it is my opinion that the livery system should not be extended to allow:
  • Replacement of OBJs used for modeling the airplane or cockpit.
  • Alternate or modified ACFs*.
  • Generally, the livery system shouldn't be used for changing the plane's behavior - it's just paint!
I have commented previously in three parts that the livery system is meant to make easy the integration of third party paint without (a) violating copyright, (b) requiring byzantine installation instructions or (c) requiring the painter and original author to coordinate. I have received requests from a number of very talented airplane authors, asking for the livery system to cover a whole range of new features, most of them involving configuration. I will try to explain in this post how I think should should be handled.

First, to be clear: an aircraft file is the .acf file that contains the X-Plane specific data needed to simulate the plane; the aircraft package is the folder containing that .acf file. A livery is a painting scheme for the 3-d model of the airplane, and a configuration is an instance of a plane with certain features, e.g. with or without G1000, with P&W vs. Rolls Royce engines, etc.

Configurations of an aircraft should be created by putting more than one aircraft file
(.acf) in a single aircraft package. Because the graphic and sound resources needed for the aircraft are accessed relative to the .acf file, you can build a family of aircraft with some common aspects and some unique aspects to each plane.

Files used by an aircraft fall into three broad categories:
  • Files found by a fixed formula using the .acf name, e.g. be20_paint.png. Let's call these "file-specific".
  • Files found by a fixed formula without using the .acf name, e.g. the contents of the aircraft plugins folder. Let's call these "package specific".
  • Files that are explicitly named in the .acf file, like airfoils and OBJs. Let's call these "flexible" (since this naming scheme could be used in any way).
Here's how the important files in an aircraft break down:
  • The aircraft paint scheme is file specific.
  • The aircraft panel background is package specific (but you can effectively have each file use a different panel background by setting the panel type differently for each plane).
  • Sounds are actually either, which effectively makes them flexible. Non-generic instruments are package-specific.
  • Objects, generic instruments and airfoils are flexible.
In other words, if you can live with duplicating your aircraft paint files (and I suspect that in most cases either the plane is built by objects, or the modifications in each configuration warrant paint changes anyway), then every other feature can be set to package or file specific, allowing you to build a group of aircraft around a single real-world plane.

Now if there are aspects of a multi-configuration aircraft package that don't work right now, we can look at possible changes to the sim to make this work. But it appears to me that just about everything necessary to make multiple configurations is already available in the sim now.

As a final note, the question here (livery vs. multi-file aircraft pack for configurations) is one of file formats, and thus of data organization and contracts between authors and programmers. It is not a question of user interface. The user interface can be reshaped to make multi-aircraft packages look like liveries, or liveries look like multi-aircraft packages. But I suspect that most of the interest in extended liveries is on the file-format side.

* The one exception for liveries is the tail number -- given the strange state where the tail number, as painted into the livery, is also written into the ACF, it wouldn't be bad to be able to override this property. Some people are already doing this using plugins.

5 comments:

Anonymous said...

Hi Ben,

as you mentioned the tail number issue I would like to expand it to livery specific configurations files for plugins, this would allow to have different options for your acf when loading another livery, like tail number or loading configuration. Only problem here is for the plugin to find out which livery is used, or even better, which livery folder is currently used. Any solutions for this in the future ?

Regards
Jan
(twinpropflyer)

Benjamin Supnik said...

Hi Jan,

First...time to move this to the Wiki. :-)

http://wiki.x-plane.com/Next-Gen_Liveries_RFC

Second...yes - we are indeed missing the ability for plugins to be livery aware. I was thinking of solving this problem with a very simple mechanism: a dataref that indicates (by name or number or both) the current livery. :-) That this dataref is not in 921 is actually an omission on my part.

Cormac Shaw said...

Hi Ben,
I would suggest that if an exception is being considered (with good reason) for Tail Numbers, then ATC Callsign should be treated similarly for the same reasons.
- Cormac

Benjamin Supnik said...

Hi Cormac,

Hrm - it seems to me that ATC callsign should:

- Not be in the ACF
- Not be in the livery

In that I could take a United gray & white livery of B738 and go fly and take on the callsigns UAL2828 an then UAL301 in two consecutive flights.

In particular, tail number is only callsign for GA...hence the tail number decal on the panel to help forgetful pilots (at least, I guess that's what it's for) which is how liveries leak into the ACF file.

To me, the callsign would be picked when you file a FP or call in for flight following.

Benjamin Supnik said...

Hi Cormac,

Hrm - it seems to me that ATC callsign should:

- Not be in the ACF
- Not be in the livery

In that I could take a United gray & white livery of B738 and go fly and take on the callsigns UAL2828 an then UAL301 in two consecutive flights.

In particular, tail number is only callsign for GA...hence the tail number decal on the panel to help forgetful pilots (at least, I guess that's what it's for) which is how liveries leak into the ACF file.

To me, the callsign would be picked when you file a FP or call in for flight following.