Appearance: .app files
All the dirty detes on appearance files
Last updated
All the dirty detes on appearance files
Last updated
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
The real meat of the file: a list of appearance definitions, loaded via root entity.
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
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
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)
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.
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.
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.
For example, the base game isn't smart enough to omit an empty or unchanged mesh appearance name, overwriting your dynamic variants.
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.
You can use them to change the appearance or visibility of components outside of the current .app file (for usage instructions, see ).
If you leave the depotPath empty, then the component override will be handled by ArchiveXL. You should probably do this, which is why will tell you about it.
