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!
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 filecommonCookData
: 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 fileparentAppearance
: the appearance this one inherits information fromproxyMesh
: 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'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.
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.
Last updated