Appearance: .app files

All the dirty detes on appearance files

If you want to modify an .app file to change an NPC's appearance, check here!

To learn how to influence items inside appearances, check PartsOverrides: Changing other meshes

Appearances

The real meat of the file: a list of appearance definitions, loaded via root entity.

appearanceResource

• baseEntityType: name that exists in the base type map and mapped to the correct .ent file

• commonCookData: the .cookedapp file that stores a copy of the data for faster loading

appearanceDefinition

A list of appearance definitions to be called from a root entity file. The definitions are independent from each other (unless parentAppearance is used? Confirmation needed) and load meshes and effects via components.

• name: the appearance's name that is listed in its .ent file

• parentAppearance: the appearance this one inherits information from (can be used for randomisation, see below)

• proxyMesh: the .mesh file loaded for rendering the vehicle at a distance (confirmation needed)

• resolvedDependencies: pre-loaded resources. You will usually want to delete these if you're adding items from scratch.

• looseDependencies: lazy-loaded resources (confirmation needed)

Components

A list of components that are part of your current appearance. There are various types of components, which are documented here.

Components that you add in the root entity will be shared among all appearances in the .app.

partsValues

This only works for player equipment and weapons (April 2023)

Allows you to add one or more component entities into your appearance. They will be treated as if the components were part of the appearance's components array.

partsOverrides

Overrides component definitions via name. They can be defined in the appearance's own components array or loaded via component entity.

You can use them to change the appearance or visibility of components outside of the current .app file (for usage instructions, see PartsOverrides: Changing other meshes).

You can't un-hide something via partsOverrides — you'll have to use custom tags for this.

If you leave the depotPath empty, then the component override will be handled by ArchiveXL. You should probably do this, which is why file validation will tell you about it.

For example, the base game isn't smart enough to omit an empty or unchanged mesh appearance name, overwriting your dynamic variants.

Randomisation with parentAppearance

Several appearances can be grouped by using the parentAppearance property. For instance in the appearance below when you spawn service__sexworker_ma_prostitute_poor_01 → appearanceName = prostitute_poor_01 it selects a random appearance from 9 predefined appearances with parentAppearance = prostitute_poor_01.

Overall there's at least 3 ways to randomize appearance:

• based on visualTags in character record

• based on crowdAppearanceNames in character record

• based on parentAppearance in appearance definitions

They can be combined: for example, visual tags selects initial appearance like service__sexworker_ma_prostitute_poor_01, then it's randomized again on the meshes based on parentAppearance = prostitute_poor_01

commonCookData

This has been removed with 2.1 — the information below is preserved for historical reasons.

To save a few processing cycles, CDPR doesn't evaluate .apps on load, but instead keeps a pre-cooked cache under base\cookedappearances. CommonCookData is the lookup path for such a file. As long as the file in question exists and isn't empty, your changes might not register, or components that you removed will still be displayed.

Once you start modding, you'll want to install the cookedapps nulled mod to prevent such issues.