Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Game components: materials - how they work and what they are
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
What do the different files do? How do I mod them?
Please see the individual subpages in the menu to get to the content, or use the "Next" button at the bottom of the page.
All inclusive list of REDengine file formats
Created by @manavortex Published April 10 2023 Game version: 2.1
For an exhaustive list, see the W2RC File Format Table.
This file contains a list of appearances with their associated components. To load them, you require a root entity .ent. The .app files also contain extensive parameters for wounds and dismemberment, determining which meshes to use for different types of garment an NPC might be wearing, and even the physics behavior of these meshes.
Holds a list of components.
The entry point for the game to display an NPC or prop. It is a collection of components that the entity is comprised of, determining their parameters or referencing the files that have said parameters. For instance, NPC .ent files have over a hundred components each, such as entAnimatedComponent (references the correct .anims, .animgraph and .rig files), entTemplateAppearance (references all .app files that are applicable to the entity) and entEffectSpawner (references all .effect files for decals or particles that the entity can spawn). Many of these components have configurable parameters, and the .ent file itself has many under the "entity" section. Many of these parameters, however, are merely the initial state of the entity and are modified in gameplay (such as the boolean isRagdolling).
From ArchiveXL item additions, this kind of file is usually called a root entity.
For player items, an .ent file can serve as a wrapper, splitting components out of the .app file by putting them in their own file.
Not a file type but an internal data structure and part of .ent or .app files. Components are how the game adds anything to the in-game world, from pag3d data over player interaction prompts to explosion sounds.
A 3d object, holding appearances, materials, and rigging. Meshes for inanimate objects also tend to contain the physics parameters of these objects, whereas NPC meshes tend to contain some garment parameters.
A mesh can have several submeshes, which can be displayed or hidden via chunkmasks.
A material definition for a shader. You can assign those to CMaterialInstance entries in your mesh and then define their qualities by changing their parameters.
This file holds world environment information and -properties. Due to its complexity, information is grouped on its sub-page.
A regular texture file. Can be exported to .png via WolvenKit, edited, and imported back into the game. The type of texture is often indicated at the end of the filename. For instance, diffuse textures are specified as "_d" and normals are specified as "_n".
If you stick to the game's naming schema, Wolvenkit will auto-detect the right import settings for you.
Can be either blue or yellow (inverted), both exist. For a guide how to make your own, see here.
Cyberpunk normal maps are swizzled (a technique originally employed in DTX-5).
The red channel stores the X axis
The green channel stores the Y axis
The blue channel is empty, since the Z-data will be calculated from red and blue.
Texture atlases contain multiple textures that the game may choose at random (such as blood splatters, as seen in fx_blood_splatter_2x2_01_d.xbm) or play sequentially (as seen in splash_texture.atlas_n.xbm, used by the game for the blood puddle animation). Texture atlases won't always have "atlas" in their filename, but can still be quickly identified by the size of the grid. For instance, "3x3" in the filename means a grid of nine textures. In the asset browser, right-clicking on the file and selecting "Find Files Using This" will take you to files that allow further customization of how the game interacts with the grid.
<explanation>
The following data only applies for archives created with WolvenKit
All the dirty detes on appearance files
commonCookData
: the .cookedapp file that stores a copy of the data for faster loading
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)
This only works for player equipment and weapons (April 2023)
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.
Extension | Description | Fully Parsed |
---|---|---|
Extension | Description |
---|---|
Name | Type/Size | Info |
---|---|---|
Name | Type/Size | Info |
---|---|---|
Name | Type/Size | Info |
---|---|---|
Name | Type/Size | Info |
---|---|---|
Name | Type/Size | Info |
---|---|---|
Name | Type/Size | Info |
---|---|---|
If you want to modify an .app file to change an NPC's appearance, check !
To learn how to influence items inside appearances, check
The real meat of the file: a list of appearance definitions, loaded via .
baseEntityType
: name that exists in the and mapped to the correct .ent file
A list of appearance definitions to be called from a 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
A list of components that are part of your current appearance. There are various types of components, which are documented .
Components that you add in the will be shared among all appearances in the .app.
Allows you to add one or more 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 .
You can use them to change the appearance or visibility of components outside of the current .app file (for usage instructions, see ).
You can't un-hide something via partsOverrides — you'll have to use 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 will tell you about it.
Once you start modding, you'll want to install the mod to prevent such issues.
Different per material — see parameters/[2] for a list of properties
e.g. BaseColor, Metalness, NormalStrength or VectorField, FresnelColor, Albedo
IsGamma
Override in-game gamma (lighting)? - Set to "false" for normals - Set to "true" for diffuse/albedo and any parts of the UI
Animation databases that rename and organize animations for use in scripts and other files such as animation graphs
Audio
Pathfinding/AI
Animation and physics graphs, used for visual scripting of all animations associated to an entity, as well as physics behavior of dangling objects such as necklaces
Collections of individual animations and their data
Mesh appearance configurations, as well as wound/dismemberment configurations
?
Terrain related
?
?
A.I. behavior graphs, can be used to influence NPC reactions to various stimuli
?
Bink video
Bink video
Camera curve preset
?
Character editor preset
Minimap
Quest related
Cutscene related
See mlsetup
See anims
See app
Configuration for credits
6-sided cube texture
Determines the curve graph values of things such as fall damage and level scaling
?
?
Master file for visual effects such as particles and decals. Holds parameters and has a second tab for editing the associated .particle file.
Entity, master file that contains all components and parameters of which an entity is comprised
Environment definition
?
?
Behavior parameters for attacks, weapons and explosions. Highly influential on gameplay.
?
?
?
Font
Foliage brush
Destructible foliage element
?
Game main configuration file
?
Animation database that determines which animations should play based on various enum inputs (see associated .csv to see which parameter corresponds to what number)
?
?
Hit detection for different body parts, as well as visual feedback based on whether the material is flesh, metal, cyberware, etc.
Hair profile
?
UI animation
UI texture atlas
UI character related
UI font
UI
UI settings
UI
UI
UI
UI
UI
UI
UI
UI
Quest info
Quest info
?
?
?
?
?
?
?
?
Pins on map
Mesh/model, often containing physics settings (for inanimate objects) and some garment parameters (for NPCs)
Instanced external shaders/materials
Masks for multilayer supershader
Setup file for multilayer supershader
Template file for multilayer supershader
Blend shapes/shape keys
Base shader
navmesh
AI navigation meshes
?
Audio
Audio
Parameters for particles and decals, can be configured in the second tab of .effect files
Nvidia PhysX physics parameters, also present in many .mesh files
Nvidia PhysX physics parameters, also present in many .mesh files
Physics Material definitions. Governs bullet penetration, A.I. visibility through different materials, friction, etc., but tweaks to it are only partially applied in-game
Point of Interest Map pin
?
Quest
Quest progression
regionset
?
Similar to mt, difference is unclear
Resource list
Rig/skeleton for animation, definition of bone groups and ragdoll physics
Cutscene
Cutscene versioning
?
?
Skin profile
?
Terrain
The world in manageable pieces
Terrain
Links all the sectors
Terrain
Multiple textures
?
?
?
Leftover mesh file with RED3 extension
Leftover mi file with RED3 extension
?
Texture
Texture
Standard CSV file, spreadsheets containing definitions for various parameters and enums that are used in other files
Audio file
Header
See specification of Header below.
Custom Data
WolvenKit only. See specification of custom data below.
Files
data
Raw file data
File List
See specification of file list below.
Magic
char[4]
Constant: "RDAR"
Version
uint32
Currently 12
IndexPosition
uint64
Offset of beginning of file list
IndexSize
uint32
Size of file list
DebugPosition
uint64
Always 0
DebugSize
uint32
Always 0
Filesize
uint64
Size of file (excluding Filesize)
CustomDataLength
uint32
WolvenKit only
Magic
char[4]
Constant: "LXRS"
Version
uint32
Currently 1
Size
int32
Size of uncompressed data
ZSize
int32
Size of compressed data
PathCount
int32
Number of custom paths
PathStrings
zstring[PathCount]
Custom file paths
FileTableOffset
uint32
Always 8
FileTableSize
uint32
CRC
uint64
Checksum of ???
FileEntryCount
uint32
Number of files
FileSegmentCount
uint32
Number of file segments
ResourceDependencyCount
uint32
Number of resource dependencies
FileRecords
File Record[FileEntryCount]
See specification of file record below.
FileSegments
File Segment[FileSegmentCount]
See specification of file segment below.
ResourceDependencies
uint64[ResourceDependencyCount]
NameHash64
uint64
FNV1A64 hash of the filename
Timestamp
int64
Windows filetime of file creation
NumInlineBufferSegments
uint32
Number of inline buffers
SegmentsStart
uint32
Index of the first file segment
SegmentsEnd
uint32
Index of the last file segment
ResourceDependenciesStart
uint32
Index of the first resource dependency
ResourceDependenciesEnd
uint32
Index of the last resource dependency
SHA1Hash
uint8[20]
SHA1 hash of the file
Offset
uint64
Offset of the data
ZSize
uint32
Size of compressed data
Size
uint32
Size of uncompressed data
To be done: exhaustive info about environment definitions and weathers.
env has extra feature, it controls weather probability, the .envparam is the exact same as .env but only contains lighting changes, so it works with any weather rebalancers without compatibility patches, since the lighting part is overridden by envparam, but not the weather probability
Quote: someone on Nexus
What's a proxy appearance, and how do I get rid of it?
This page explains what Level of Detail is and how it works.
To learn about Level of Detail (LoD), check the corresponding wiki page.
When displaying a complex object, the game loads between 1 and e^x components, each of which includes extra logic. That's all fine and dandy as long as you're up-close — but as soon as you're far away and the details vanish in the distance, it's a complete and utter waste of processing power.
That is where proxy appearances come in: instead of all the complex components and the complex shaders, you will see a single mesh with a bunch of baked-in textures.
All modern computergames do this in one way or another.
Fun fact: the human brain works the same way. Unless you have aphantasia, you can try it out: For an object at the edge of your vision, imagine it with as high-fidelity as you can. After a minute of that (your brain needs time to render), look at the object and compare.
If a proxy appearance fucks up your NPV, here's how you can disable it:
Open the appearance's components array
Find and delete the AppearanceProxyMesh
component (it will be of the type entSkinnedMeshComponent
)
Find and delete the AppearanceVisualController
component (it will be of the type AppearanceVisualControllerComponent
)
For each component with a mesh, set the forceLodLevel
property to 0
How does collision work? How to add or remove it?
Colliders are added via .phys files. For cars, those get added by the chassis component:
All the dirty detes on entity files
Serves as the top-level container for entities and their properties within the game. Most things that you can see, touch, or interact with have an .ent file somewhere in their hierarchy. Examples are player equipment, weapons, NPCs, interactables (doors, vending machines…)
For the purpose of modding, we distinguish between two different kinds of entity files.
For player equipment (weapons and armour), you can use mesh entities to encapsulate parts of your item. You load such .ent files via partsValues
, which will be added to the corresponding appearance as if the components had been in the .app file itself.
As of April 2023, partsValues
will be ignored for anything but player equipment.
This is good practice to avoid repetition, and also to make it easy on yourself if you want to change paths later in your project (imagine having defined 20 appearances with 5 components each, and then wanting to rename your mesh folder…)
This file is how the game handles item uniqueness. For that reason, you should have one root entity per item. If you put multiple entries into the same file, then you can't wear them simultaneously (for e.g. EquipmentEx).
From ArchiveXL item additions, this kind of file is usually called a root entity.
An entity file can define multiple appearances, which can point to different .app files.
How you split your .app files is largely a matter of taste. At CDPR, they usually shove everything into one file.
If you are registering an item via ArchiveXL, you can define suffixes via appearanceSuffixes: [ … ]
in the .yaml file.
Your item will inherit the suffix setup from the $base
component. In the example of Items.GenericHeadClothing
, that will be
These bad beans can be the reason why your item is invisible!! You can and should disable the suffixes if you don't need them.
To do so, add an empty array to the yaml entry:
Published: Mar 02 2024 by Last documented update: Mar 02 2024 by
There is almost nothing here yet. Perhaps you'd like to and help?
For more information on car collision, see
To see a minimal example in action, see the guide for .
The minimal way of adding something (e.g. meshes) to the game. This entity can be directly spawned (e.g. ) or referenced from within.
The entry point for the game to display an or . This kind of entity only defines those that are shared among all appearances. Meshes are defined in the , where they can be assigned different properties (e.g. materials) per appearance.
For , root entities are used as the defining key (one entity => one item, which can have multiple appearances)
Names support , allowing you to load different appearances based on body gender or camera mode. These are only used for player equipment and look like &FPP
For more information on this (and for a better way of implementing this), check
In a , you can give the game a list of appearances and have them mapped to an by entry name. While that's pretty good already, have you ever wanted to be more specific — for example, "for a male character, use this appearance, but for a female use this other one?"
This is where suffixes come in. You append them to an appearance's name in the , and the game will pick the correct appearance (and the correct, and the correct mesh!) based on the best match.
Find step-by-step walkthrough on using suffixes in the .
For a full list, check
This page contains documentation for the most common component types. WIP.
See the Comprehensive Component Hierarchy List for all possible components used in the game, organized by hierachy. Use for researching and documenting components.
For a json dump of all existing components and their properties, check DrPresto's github repository.
For a hands-on guide on how to safely change components in .app files, look here.
Components are not a file type but an internal data structure and part of .ent or .app files.
Components are how the game adds anything to the in-game world, from pag3d data over player interaction prompts to explosion sounds. Entities and Appearances use components in order to slim down what data each game object has to carry, adding or removing them as needed.
In general, these should be globally unique so you can target them via partsOverrides. Feel free to ignore this (almost everyone else does), but do read the next section.
Body component prefixes affect how the game calculates garment support and you're strongly encouraged to stick to those naming conventions to make use of it. Please see the corresponding wiki page for a list.
Common component properties explained. For a more detailed list, please see Documented Components.
Only used for mesh components.
For documentation of this, see the ChunkMasks section on Submeshes, Materials and Chunks.
Relative path to a resource within the game files. Used to load dependencies — meshes, rigs, animations, effects.
How (and why) to split up meshes
In Cyberpunk, you can assign one material per submesh.
Material assignment is done in the .mesh file's appearances
array via chunkMaterials.
The chunkMaterial entries correspond to material entry names.
You can see which submesh is wich in the #mesh-preview tab.
At first, this seems a bit counter-intuitive, but keep in mind that Cyberpunk's entire material system is geared for flexibility. By altering a single submesh material, a black Arasaka helmet with red lights and a Hello Kitty hologram can become a black Militech helmet with red lights and a Hello Kitty hologram!
To learn how materials work, check the parent page: 3d objects: .mesh files
In Blender, our helmet would look like this:
You can create more submeshes by splitting off parts of a mesh, and incrementing the submesh index.
You want red and blue glowing tubes on the example helmet.
Split parts of submesh_04_LOD_1
into submesh_04_LOD_1.001
Re-name submesh_04_LOD_1.001
to submesh_05_LOD_1
Export the new geometry and import it into Wolvenkit
Your mesh will now have six submeshes instead of its previous five
For each appearance that you have defined, add a chunkMaterial entry. If you skip this step, the new submesh will have no material assigned, and be invisible.
To hide parts of the body, you can also use ArchiveXL tags. See #hiding-body-parts-diagram and the corresponding wiki page for more information.
Imagine you want to hide the helmet's glowing parts (because you are being stealthy). You could just define another appearance where the glowing tubes are turned off — but you would have to add one for every variant you make. arasaka_hellokitty_glow
and arasaka_hellokitty_noglow
, the same for Militech, NightCorps and NCPD… ain't nobody got time for this.
That's why CDPR came up with chunkmasks.
The mesh is loaded via component in an .ent or .app file. Here, you will find the chunkMask
attribute, which looks like this:
The numbers in the dropdown correspond to the submeshes: unchecking an entry will hide it, regardless of the assigned materials.
You can only use chunkMasks to hide submeshes. If you want to conditionally show them, you have to use custom ArchiveXL tags (see ArchiveXL: Tags -> #adding-custom-tags)
To learn about hiding other items with chunkmasks, check out #partsoverrides-hiding-chunks
You have two options, (for NPCs, including V) and RedHotTools.
You can download Appearance Creator Mod on Nexus. It requires Codeware, Cyber Engine Tweaks, and all of their requirements.
With ACM installed, make sure that the target is under the cursor in the middle of the screen (you can use photo mode to look at V). Then, find the correct mesh/component in the UI and click on the correct button:
Find RedHotTools -> #installation-guide for instructions on how to install this.
See #inspecting-chunkmasks for a guide.
Documentation on .mesh files and their properties.
This page contains information on .mesh files and their properties.
See WKit Blender Plugin: Import/Export -> #meshes for a guide on export/import
To edit a mesh's appearance, check Changing materials, colors and textures
To learn about mesh materials, see Textured items and Cyberpunk materials
To hide parts of a mesh under different circumstances, check First Person Perspective Fixes
To stop copy-pasting so much, check ArchiveXL: dynamic materials
In the context of Cyberpunk, a mesh is the file that defines the and the of an object in the game world.
A mesh can have several submeshes, each of which has own material assignments. You can learn more about this on the sub-page for Submeshes, Materials and Chunks.
Mesh files for inanimate objects also tend to contain extensive physics parameters governing their physical weight and general behavior.
Meshes are loaded via Components (e.g. #entgarmentskinnedmeshcomponent). Components are defined either in mesh entity files or in an .app file, where each appearance has its own components array.
For more information on this, please check Submeshes, Materials and Chunks -> #chunkmasks-partially-hiding-meshes
There are two ways of adding shadows to meshes:
To make a mesh cast a real-time shadow, set the component's property castShadows
to Always
.
Depending on your geometry, this can impact performance.
Many meshes have dedicated shadow meshes, which have a much lower level of detail and will be hidden by default. You can open any clothing item's mesh entity to see this in action.
You can see which submesh is which in the Mesh Preview
tab after opening the mesh file:
With the boxes on the left, you can toggle submeshes on and off.
Submesh numbers correspond directly to a component's #chunkmask property. For technical reasons, the chunkmask dropdown supports up to 64 entries — just ignore the missing numbers.
This section describes how materials are assigned inside each mesh. To learn more about submeshes and chunkmasks, check Submeshes, Materials and Chunks.
This page only contains mesh-specific information. Find more details on materials under Textures, Materials and Shaders.
An appearance
is the entry point into a mesh.
One appearance
has a number of chunkMaterials
, which tell Cyberpunk how they are supposed to look:
Wolvenkit will follow these entries to materialEntries, where they are defined:
The index
property in materialEntries will finally point at the material's instance, where you can find its properties. Depending on isLocalInstance
, that can be one of several places — find a list in #step-3-material-definition.
Summary:
Assign material for submesh in appearance -> chunkMaterials
Register the material by name in materialEntries
Define the material in either localMaterialInstances.materials
or externalMaterials
Here's an overview:
You can find more information on this under Submeshes, Materials and Chunks.
You assign materials based on the "chunks" (the individual submeshes) inside a mesh. Open the mesh file in Wolvenkit and open the "appearances" array, then make sure that each of your submeshes has an entry inside the array.
Materials are registered in the array materialEntries
inside your mesh:
While you can mix external and local materials, you can not mix preloaded and non-preloaded ones. For details, see below.
Many of CDPR's early meshes use preloadLocalMaterialInstances
instead of localMaterialBuffer.materials
. As far as we are concerned, you can use the two interchangeably, but:
If you are using a mix of local and external materials, you must use the corresponding lists:
If you mix the two, the materials outside of preload
… will appear as transparent the first 1-2 times you trigger your item's appearance.
A material's actual definition (instance) can be in a CMaterialInstance
inside the mesh or in a .mi
file in the project. Wolvenkit will display material names as defined in the materialEntries
, making it easier for you to see what's what.
For more details on material instances, check Textures, Materials and Shaders -> #definition-material
The materials themselves are inside the array localMaterialBuffer.materials
(or preloadLocalMaterials
in case of older meshes).
You can't go wrong by using those. However, if you don't have any properties that are unique to your mesh or appearance (for example a custom normal map), you might consider creating and using an external material instead.
A material instance looks like this:
You can find a guide about texture editing and adding custom textures in the Modding Guides section.
For an overview of materials that you might want to use for something, check here.
For how to find out which properties a material has, check here.
A relative path to an external material, usually encapsulated in a .mi file. Use this if you don't need to add extra properties.
Shady biz
This page explains how meshes are casting shadows.
There are two different ways to cast shadows: real-time (generated) shadows, and proxy shadows.
Most in-game items use both.
Your mesh casts an actual shadow.
Due to the less complex geometry, a shadow mesh is much less prone to raytracing glitches, and it will be much eaiser on performance.
Shadow meshes are usually added as entMeshComponents
.
Your average shadow mesh has only one default material with a blank local instance of engine\materials\metal_base.remt
. If the shadow mesh is loaded in a scene, it will lead to white, marshmallow-y overlays.
To make sure that it's only used for shadow generation, check the renderMask
:
Creating shadow meshes
To create a low-poly mesh, you can build a cage, subdivide it a few times and use a Shrinkwrap modifier to shape it like your mesh. Then, you can reduce the poly count by decimating.
Published: January 06 2024 by
Published: ??? by Last documented edit: May 01 2024 by
Property | Description |
---|---|
local | external |
---|---|
Published: Mar 02 2024 by Last documented update: Mar 02 2024 by
Find information about shadows in the environment under
To learn more about , check the corresponding wiki page.
The real-time shadow will be extremely detailed, but it can impact performance, and it can glitch out or cause spectacular raytracing bugs. es avoid these issues.
You activate real-time shadows by checking the following properties in your (which you can find in your or file):
The proxy shadow, by contrast, will use an invisible mesh to cast a shadow (the shadow mesh
). It has a lower than the original and often features a simplified geometry or even a .
index
numerical index of corresponding material in target list (as defined by isLocalInstance
)
isLocalInstance
Selects the material target list.
True: local material in localMaterialBuffer.materials
or preloadLocalMaterialInstances
False: material reference inexternalMaterials
or preloadExternalMaterials
For more information on this, see the page for local/external materials.
name
unique name of material, used to select the material via chunkMaterial
localMaterialBuffer.materials
externalMaterials
preloadLocalMaterialInstances
preloadExternalMaterials
Hierarchy of WolvenKit.RED4.Types.entIComponent
Full list of components, organized by hierarchy, useful for researching and documenting new components. For a json dump of all existing components and their properties, check DrPresto's github repository.
For a hands-on guide on how to safely change components in .app files, look here.
If you decide to document a component, make a new expandable entry on on the Documented Components page, followed by the discovered behavior and usage and link back to that in this list.
AIObjectSelectionComponent
AIOffMeshConnectionComponent
AISignalHandlerComponent
entAnimationControllerComponent
entAnimationSetupExtensionComponent
entAnimGraphResourceContainer
entEffectAttachmentComponent
entExternalComponent
entMorphTargetManagerComponent
entFacialCustomizationComponent
entIMoverComponent
gameRootTransformAnimatorComponent
moveComponent
entIPlacedComponent
entAmbientSoundEmitterComponent
entBaseCameraComponent
entRenderToTextureCameraComponent
gameuiHolocallCameraComponent
entVirtualCameraComponent
gameCameraComponent
gameFPPCameraComponent
gameFreeCameraComponent
gameScreenshot360CameraComponent
gameTPPCameraComponent
vehicleTPPCameraComponent
vehicleVehicleProxyBlendCamera
gamePhotoModeBackgroundCameraComponent
gameWorldSpaceBlendCamera
entDynamicActorRepellingComponent
entISkinableComponent
entCorpseComponent
entInstancedAnimationComponent
entIVisualComponent
cpConveyorComponent
entClothComponent
entDebug_ShapeComponent
entDecalComponent
entEffectSpawnerComponent
entEnvProbeComponent
entFogVolumeComponent
entISkinTargetComponent
entMorphTargetSkinnedMeshComponent
entCharacterCustomizationSkinnedMeshComponent
entPhysicalSkinnedMeshComponent
entLightBlockingComponent
entLightChannelComponent
entLightComponent
cpGameplayLightComponent
gameLightComponent
vehicleLightComponent
entMeshComponent
entDebug_MeshComponent
entEditorMeshComponent
entPhysicalMeshComponent
entAppearanceProxyMeshComponent
entBakedDestructionComponent
HudMeshComponent
entParticlesComponent
entPhysicalDestructionComponent
entVectorFieldComponent
entVirtualCameraViewComponent
ScriptableVirtualCameraViewComponent
gameBinkComponent
entMarketingAnimationComponent
entPhysicalTriggerComponent
entPhysicalImpulseAreaComponent
entTriggerComponent
entPlaceholderComponent
entSimpleColliderComponent
entSlotComponent
gameHitRepresentationComponent
gameOccupantSlotComponent
entSoundListenerComponent
entStaticOccluderMeshComponent
entTargetPointComponent
entTransformComponent
entVisualOffsetTransformComponent
entTriggerActivatorComponent
gameaudioAcousticPortalComponent
gameAudioEmitterComponent
gameaudioSoundComponentBase
gameaudioSoundComponent
gameaudioVehicleAudioComponent
gameWeaponAudioComponent
gameEntityStubComponentPlacedProxy
gameEnvironmentDamageReceiverComponent
gameinfluenceBumpComponent
gameinfluenceComponent
gameinfluenceHeatAgentComponent
gameinfluenceObstacleComponent
gamemappinsMappinComponent
gameMovingPlatform
gameNavmeshDetector
gamePingComponent
gameprojectileComponent
gameprojectileSpawnComponent
gameStaticAreaShapeComponent
gameStaticTriggerAreaComponent
gameTransformAnimatorComponent
mpInteractionActivatorComponent
senseComponent
senseSensorObjectComponent
senseVisibleObjectComponent
vehicleChassisComponent
WidgetBaseComponent
IWorldWidgetComponent
AdvertisementWidgetComponent
StreetSignWidgetComponent
WorldWidgetComponent
WidgetHudComponentInterface
WidgetHudComponent
WidgetMenuComponentInterface
WidgetMenuComponent
workWorkspotResourceComponent
entLocalizationStringComponent
entRagdollComponent
entTransformHistoryComponent
entVertexAnimationComponent
entVisualControllerComponent
entWetnessComponent
gameAIDirectorTensionAnalyzeComponent
gameAttachmentSlots
gameaudioMusicSyncComponent
gameBraindanceDissolveComponent
gameComponent
AICAgent
AIHumanComponent
AIVehicleAgent
AITargetTrackerComponent
TargetTrackingExtension
cpTestComponent
ElevatorController
EntityStubComponent
gameAttitudeAgent
gameDeviceCameraControlComponent
gameDeviceComponent
PSD_Detector
PSD_Master
ScriptableDeviceComponent
ActionsSequencerController
ActivatedDeviceController
BarbedWireController
ActivatedDeviceNPCController
AlarmLightController
AOEEffectorController
ArcadeMachineController
PachinkoMachineController
BaseAnimatedDeviceController
MainframeController
RetractableAdController
SlidingLadderController
BaseDestructibleController
BasicDistractionDeviceController
BlindingLightController
ReflectorController
CleaningMachineController
ConfessionBoothController
ExplosiveDeviceController
C4Controller
ExplosiveTriggerDeviceController
SensorDeviceController
SecurityTurretController
SurveillanceCameraController
FanController
NetrunnerControlPanelController
SmokeMachineController
BillboardDeviceController
CandleController
ChestPressController
CoderController
ConveyorController
DataTermController
DisplayGlassController
DisposalDeviceController
DoorController
MovableWallScreenController
WindowController
DoorProximityDetectorController
DropPointController
ElectricLightController
GameplayLightController
ExitLightController
ForkliftController
FridgeController
GenericDeviceController
GlitchedTurretController
HoloDeviceController
HoloFeederController
InteractiveAdController
InteractiveSignController
IntercomController
InvisibleSceneStashController
JukeboxController
LadderController
LaserDetectorController
LcdScreenController
ApartmentScreenController
MasterController
AccessPointController
ActivatorController
AOEAreaController
BaseNetworkSystemController
DoorSystemController
DestructibleMasterDeviceController
DestructibleMasterLightController
DeviceSystemBaseController
PersonnelSystemController
SecuritySystemController
SurveillanceSystemController
DisassembleMasterController
ElectricBoxController
FuseBoxController
FuseController
LiftController
MaintenancePanelController
NetworkAreaController
RoadBlockTrapController
SecurityAlarmController
SecurityAreaController
SecurityGateController
SimpleSwitchController
SmartHouseController
SoundSystemController
TerminalController
ComputerController
SmartWindowController
ElevatorFloorTerminalController
TrafficIntersectionManagerController
VentilationAreaController
MediaDeviceController
HoloTableController
RadioController
TVController
WallScreenController
MovableDeviceController
NcartTimetableController
NetrunnerChairController
OdaCementBagController
PortalController
ProximityDetectorController
RoadBlockController
SecurityGateLockController
SecurityLockerController
SpeakerController
StashController
StillageController
ToiletController
TrafficLightController
CrossingLightController
TrafficZebraController
VehicleComponent
AVComponent
CarComponent
MotorcycleComponent
VendingMachineController
IceMachineController
VendingTerminalController
VentilationEffectorController
WardrobeController
WeakFenceController
WeaponTrainingController
WeaponVendingMachineController
WindowBlindersController
gameEntitySpawnerComponent
gameEntityStubComponent
gameInventory
gameMasterDeviceComponent
gameScriptableComponent
AdamSmasherComponent
AIRelatedComponents
AICustomComponents
CentaurShieldController
AIMandatoryComponents
HitReactionComponent
HitReactionMechComponent
StatusEffectManagerComponent
AIPhaseStateEventHandlerComponent
AppearanceRandomizerComponent
AreaEffectVisualizationComponent
BossStealthComponent
CombatHUDManager
DEBUG_VisualizerComponent
DetectorModuleComponent
DeviceConnectionHighlightComponent
DeviceDebuggerComponent
DeviceTimetable
DiodeControlComponent
DisarmComponent
DisassemblableComponent
DrillMachineScanManager
DroneComponent
DurabilityComponent
EntityAttachementComponent
Example_FxSpawning
FastTravelComponent
FollowSlotsComponent
FxResourceMapperComponent
gameAINetStateComponent
NPCStatesComponent
GameplayRoleComponent
InputDeviceController
InspectableObjectComponent
InspectionComponent
MinotaurMechComponent
ObjectMoverComponent
OdaComponent
PhotoModePlayerEntityComponent
PlayerPhone
QuickSlotsManager
ReactionManagerComponent
ResourceLibraryComponent
RewireComponent
RoyceComponent
SampleComponentWithCounter
SampleCounterDisplayComponent
SasquatchComponent
ScannerControlComponent
ScavengeComponent
SimpleTargetManager
StimBroadcasterComponent
TankTurretComponent
TestScriptableComponent
TrapComponent
UpdateComponent
VendorComponent
WeaponPositionComponent
WorkspotMapperComponent
gameSquadMemberComponent
SquadMemberBaseComponent
gameStatsComponent
gameStatusEffectComponent
gameVisionModeComponent
scnVoicesetComponent
vehicleCameraManagerComponent
vehicleController
vehicleGarageComponent
vehiclePersistentData
gameComponentsStateSaveComponent
gameCrowdMemberComponent
CrowdMemberBaseComponent
gameDoorComponent
gameEthnicityComponent
gameFootstepComponent
gameHumanoidBody
gameImpostorComponent
gameinteractionsReactionComponent
gameITriggerDestructionComponent
gameBodyTriggerDestructionComponent
gamePuppetTriggerDestructionComponent
gameLadderComponent
gamemountingMountableComponent
gameMovingPlatformMountableComponent
gameObjectMountableComponent
gamePuppetMountableComponent
vehicleVehicleMountableComponent
gameMultiEcsManagerComponent
gameMuppetComponent
gameMuppetBlackboardsComponent
gameMuppetInputStates
gameMuppetInventory
gameMuppetLocomotionComponent
gameMuppetPhysicsComponent
gameMuppetRawInput
gameMuppetStats
gameMuppetUpperBodyRequestsComponent
gameMuppetInputHandlerComponent
gameNarrationPlateComponent
gameNetrunnerPrototypeComponent
gameObjectCarrierComponent
gamePhantomEntityComponent
gamePhotoModeBackgroundViewComponent
gamePhysicalDestructionListenerComponent
gamePlayerCommandConsumerComponent
gamePlayerControlledComponent
gamestateMachineComponent
gamePlayerMappinComponent
gamePlayerTierComponent
gameScanningActivatorComponent
gameSimpleOccupantSlotSpawner
gameSourceShootComponent
gameTargetingActivatorComponent
gameTargetingLocalizedEffectComponent
gameTargetShootComponent
gameTPPRepresentationComponent
gameuiICharacterCustomizationComponent
gameuiCharacterCustomizationBrokenNoseController
gameuiCharacterCustomizationPersonalLinkController
gameuiICharacterCustomizationBodyController
gameuiCharacterCustomizationBodyController
gameuiICharacterCustomizationBodyPartsController
gameuiCharacterCustomizationBodyPartsController
gameuiCharacterCustomizationFeetController
gameuiCharacterCustomizationGenitalsController
gameuiCharacterCustomizationHairstyleController
gameVisionActivatorComponent
gameWeakspotComponent
moveIMotionPlannerComponent
moveMotionPlannerComponent
moveDroneMotionPlannerComponent
movePoliciesComponent
worldTrafficLightListenerComponent
Apart has prepared a reference project with an import-ready inkatlas. You can download it here.
This page explains the .inkatlas
file and its logic.
Learn how to make Your own inventory preview icons
Make a custom Atelier icon
Make your own inkatlas with Python: find the script on The Magnificent Doctor Presto's github. Check Running Python Scripts if you don't know how to use this.
Make your own inkatlas with Photoshop CC (Adobe Creative Suite required): find the plugin on deadlymustard's github
The .inkatlas is a map file that slices textures into sprites (slots), which are then used by the game for pretty much everything that is a picture - from your HUD to peoples' phone avatars to item preview icons in shops or custom atelier images.
Unlike other games, Inkatlas files don't slice by pixel coordinates but by percentage as a float value between 0 and 1 . The starting point is the TOPLEFT corner, the ending point is the BOTTOMRIGHT corner.
Each slot (inkTextureAtlasMapper
) has four coordinates. This is a single slot across the entire inkatlas:
For example: two sprites in column will be written as: (y 0,5; x 0) X (x 1; y 0) for upper sprite and (y 1; x0) X (x 1; y 0,5) for lower
inkTextureSlot
sEach inkatlasa has three different inkTextureSlots, which support different texture resolutions. For the purpose of modding, it is enough if you work with inkTextureSlot 0 (the first one in the list).
If an existing xbm is hooked up, the Part Mapping
tab will appear, where you can check which parts of your image correspond to each slot name.
As of Wolvenkit 8.11.1, this requires reopening the file.
You target sprites (slots in the inkatlas) via the atlasPartName
property:
Any atlasPartName in the yaml
must correspond with the name of a part in the inkTextureAtlasMapper. If the corresponding entry can't be found, an empty icon will be displayed.
You can see which sprite is targeted by any given entry in the Part Mapping:
What's a hair profile, and how do I use it?
This page collects basic information about hair profiles.
Via hair profiles, it's possible to quickly and easily create a large variety of hair colour variations without the need of having colour textures. That happens via two arrays:
Determines the strand to strand colour by using the Strand_Gradient
texture. The gradient serves to empathize/de-empathize contrast among the black/white scale.
Together with the gradientMap
, this is used to generate varieties of unique hair materials.
Is applied to the Strand_Gradient
texture to determine the hair colour from start to top. Via gradientStops, the colour positions from root to tip of the strands are determined.
Details about in-game textures
This wiki page contains documentation about xbm files and their properties.
Would you rather…
As of 2024, the toolchain assumes.png
as your default format. You can
This means that all features of the DDS format are included, and they are nearly completely compatible out-of-the-box.
Any CR2W file includes a section telling the engine how to read it, the header. Most of the file encodes texture data, but the header for textures includes:
size
texture format
dimensions (e.g. if your texture data is 1024x1024, but the header says it's 512x512, then the engine will resize it)
The setup section of the XBM file is in essence an extension of the header.
It contains settings that, more than just describing basic information about the texture, such as:
bit depth
texture type
format
gamma correction
streamability
mip chains
EntSlotComponent and EntEffectSpawnerComponent
This page will tell you how effect components work and how they interact with each other.
You will see two kinds of effect component types, which always occur in pairs.
If you want the position of your effects to follow the movement of parts of the object you can set the boneName
an existing bone of your object
In this case the relativePosition
will be relative to the bone's position
Usually called fx_whateverTheEffectIs
, this component defines and registers effects which can then be placed via slots.
In the entEffectSpawnerComponent
, delete:
the placementTag
entry that you want to get rid of
In the entSlotComponent
, delete:
The entry in slots
referencing the previously deleted component by name.
In the entEffectSpawnerComponent
, add:
a new placementTag
at the end of the array with the name of your new entry (e.g. fx_candle_slot_04
)
a new entry under placementInfos
(by duplicating the last entry), setting the placementTagIndex
to the numeric index of the placementTag
you created in step 1
In the entSlotComponent
, add:
a new entry in slots
with the name that you created in Step 1
If you are making effects into equipment, having the same autoSpawnTag will make it so equipping one will despawn the other one.
eventRUID in the ent component must be the same as the effect particles ruid, and ideally should be unique across everything. You can right click on a RUID field and choose "Generate new CRUID" to generate a semi-random new CRUID and then copy it across so they match.
Material Instances and external materials
Put yourself in the shoes of a hypothetical modder.
You are creating a mod that offers multiple versions of the same item (e.g. toy props or hair)
You have created a base material
You duplicate and re-duplicate the material for each of your variants, changing the properties that defines the colour
You wish that there was less copy-pasting involved
Take any of them from the game, move them to your custom directory, and group all the properties that you keep copy-pasting into the .mi.
Then, in your material, you can now use your .mi file as baseMaterial
, and only change the properties that are actually different!
Instead of copy-pasting six properties, you now copy-paste only two.
For this, I first created a plastic_base.mi
with all the common properties, and then created one additional .mi file for each shade of plastic, setting plastic_base.mi as baseMaterial, leaving me with the following folder structure:
If I decide that my plastic is too shiny, I can edit _plastic_base.mi
instead of touching every template individually. Pretty neat, isn't it?
And if one of my items happens to have a custom normal map and/or texture, then I just add them in the values
array of my material and call it a day.
But we can take this approach even further! If you don't have any properties, your mesh doesn't even need materials! You can simply use the externalMaterials
list instead. You do this by unticking the isLocal property in the materialEntries definition:
You can of course mix and match local and external materials! Just make sure that the materialEntries indices are pointing at the correct material.
However:
If you are using preloadLocalMaterials
, you need to use preloadExternalMaterials
instead of externalMaterials.
Find templates (by ) in the wiki github's file section
Check -> for a guide on importing/exporting
Learn more about ->
Last documented update: Apr 06 2024 by
textures?
Learn about ?
Use on your mesh?
.xbm
files are simply CR2W (REDengine) representations of .dds
files. Regardless, you still need to .
mipmapping (lower-resolution versions of the same texture for and streaming)
See the for all possible components used in the game, organized by hierachy. Use for researching and documenting components.
For a json dump of all existing components and their properties, check
For a hands-on guide on how to safely change components in .app files, look .
Your favourite kind of mesh component is the , as it does not have any physics properties that can crash the game.
The 's physics properties can be responsible for crashes if you edit the linked mesh.
This is the good kind of mesh component, the one that will work without trouble, as opposed to .
See
Like , but with a physicalMesh
and physics.
Usually comes together with an (they're usually named collar
for clothes and dangle
for hair and accessories).
The physics will cause crashes if you alter the mesh file (yes, even if it's just a refit). As an alternative, you can use a regular mesh component together with .
Adds physics to garments and hair meshes. This is the "safe" way of doing it, opposed to , which can cause crashes.
Used for components on low levels of details such as and .
Please see for details
Published: Feb 09 2024 by Last documented edit: Mar 4 2024 by
For an overview on existing effect materials, check
For a guide on how to use effects, check
Usually called fx_slots
, this component allows you to place your effects in the world. It requires the definitions in the to work.
the corresponding entry in placementInfos
(see the yellow arrows on the screenshot under )
Please check -> for a detailed guide!
Last documented update: May 01 2024 by
As of May 2024, you can also use , which is a more flexible implementation of the same basegame mechanic. However, you may want to understand this, because CDPR are using it a lot.
A .mi file encapsulates a material in a reusable template file, which you can use a .mi file as base material
in a .
It is possible to use multiple .mi files in a row. For an example of this, check the player's .
For more information of this, you can look at ->
For a collection of example .mi files, check .
Let's take it another step further – we can make a bunch of different colours to re-use across your files. An example for this are hair files, or the plastic materials I've used in my .
Defines visibility of individual submeshes |
meshAppearance |
castShadows castLocalShadows |
forceLODLevel |
Crowd generation, and how to influence it
Inside the communityTemplate, this file defines appearances for crowd pools:
You can use Find Files Using This
from the context menu of the corresponding .app or .ent file and follow the daisy chain until you find the .community file.
(as of October 02 2032, this is still broken)
As of 8., Wolvenkit only lets you search for files, not in them. For that reason, we'll have to use a workaround.
I have completed step 1 -3 for you and put the results on my Mega.
Delete the original .community files (you'll re-add them later)
Use Notepad++ to search inside the directory for your appearance name
If nothing shows up, try partial matches
Note the names of the files under .raw
search for the file name in Wolvenkit, then add it back and make your edits
Documentation on .streamingsector files
StreamingSectors are the files that define the world in Cyberpunk, they tell the engine what goes where, and define everything from the meshes you see and how you can interact with them, to the locations of lights, sounds and fx. They call up the NPCs, they define the minimap.
The fundamental bits of the structure are 2 main lists, the nodes, and the nodeData. The nodes define the assets that make up the sector, and the nodeData tells the engine where to put them. Theres a nodeRef list as well, which seem to be the link that quests use to tie in to triggers etc via the .scene files. Theres also some bits that define variants, that seem to be how sectors change after missions, not worked those out yet.
Streaming Sectors contain the world's data, holding a node tree that includes all its models and entities.
Other than the world environment, streaming sector files can also define
navigation
sound
collision
illumination
as there are several types.
The world is broken up into a grid, with several sizes of squares available (bit like graph paper with major and minor grid lines). The size of the grid in use is dependent on the Level of Detail (LOD) of the sector file your looking at, which is the last digit of the filename.
Chunk sizes are as below.
For every location, there can be multiple overlapping levels of LOD sectors with progressively more detail as you go down the levels.
For instance, Lizzies bar is located at approximately -1200, 1562, 22:
Filenames are structured as sectortype_X_Y_Z.streamingsector
. If you preview a sector in wkit, the axes are shown as Z=-Y and Y=Z.
From those co-ordinates we can calculate the sector files for interior/exterior sectors by dividing by the grid size for the LOD and rounding. (ie 1200/32=38 etc)
At the level 0 files the whole building isn't covered by 1 sector, so you end up needing 4, conversely the exterior level 2 is several city blocks.
For example, the loft apartment uses these files:
interior_-24_-16_1_1.streamingsector
: inner walls, floors, collision
interior_-48_-31_2_0.streamingsector
: interior decoration, clutter
Note that the numbers are simply duplicated and rounded down. No, I don't know how you round down 2*16 to 31 either.
Some locations are partially defined in quest sectors, where parts of the location are locked away behind story triggers (for example half of V's apartment, as a lot of decoration will only be shown after completing quests). The exact process isn't fully understood as of May 2023.
A steamingsector can split its nodes into ranges called variants. A variant is used to display/enable an amount of nodes in a specific situation (like during or after a quest). All sectors and their variants need to be declared somewhere; this place is the streamingblock.
We will see how they are declared and how they are linked together.
The game contains only 3 streamingblocks that gather more than 26300 sectors.
We will focus on the main one and take a look at the first sector inside (exterior_-18_3_-12_0
).
When creating a mod with sectors, you will need to create your own block that will list your new sectors.
This sector has 10 variants, in this case, each one is related to a quest state.
numNodeRanges
indicate the number of node ranges the sector contains; it always corresponds to the number of variant + sector's default range (so here 10 variants + 1 default).
When opening a variant definition, we can find the range index (to find the right range inside the sector file). rangeIndex
cannot be 0, 0 is used as sector's default range.
Variant's name is only used to identify the variant within the streamingblock.
enableDyDefault
is self-explanatory; it indicates whether it should be enabled by default.
The sector file uses 2 arrays to define ranges: variantIndices
and variantNodes
.
variantNodes
contains as many empty arrays as variants (in this case, 10).
variantIndices
contains as many values as ranges needed (10 variants + 1 default range)
A variant indice indicates the range starting nodeData index. This range goes from the index specified to the start of the following range. If we look at variant indice #7, the range starts at node index 14 (included) and ends at node index 46 (excluded).
A sector always has a default range (variant indice 0); this default range indicates which nodes must always be visible/enable, whatever are the variants state. In our example, the default range goes from 0 to 1, so only the first node is always enabled.
Here is an overview of files relations:
Loads a
Selects an entry from the mesh's array
Enables/disables
Force
add to your project
Last documented update: January 27, 2024 by
If you want to know how to find a streaming sector, see .
For a list of interesting locations, see .
For guides how to modify streaming sector files, see .
For a (partial) list of node types and what they are, see .
LOD | Interior | Exterior |
---|
I've left the detail of the process below for record, but if you just want a list of sectors I've created a python script to find the ones that a set of co-ordinates are in. You can find it . Simply enter the co-ordinates in the player_loc dict in block 3 then run all blocks. You'll be given 2 lists containing of all the interior and exterior sectors which contain the co-ords within their bounding boxes. The list also shows the distance from the centre of the sectors to the co-ords given.
LOD | Interior | Exterior |
---|
The link between quests and sectors' variants is not well-researched as of Jan 2024 - if you know anything more about this, please get in touch via or update the wiki!
0 | 32 | 64 |
1 | 64 | 128 |
2 | 128 | 256? |
0 | -38_49_0 | -19_24_0 |
1 | -19_24_0 | -9_12_0 |
2 | -9_12_0 | -5_6_0 |
Theory on the quest system
Updated: 07. 04. 2024 by Deceptious
This is the theory page. If you want more hands-on advice, check the Quests section under Modding Guides.
Quest facts are just a value (signed integer) and a name (string).
Quest facts are chosen by the developer/designer/modder.
While you are moving through the world of Cyberpunk, the game will track your progress in your save game via these quest facts and their values.
Quest facts do not exist until they are explicitly set. Until they are set they are assumed to be 0.
Any/all quest facts can be 'read' at any point. They can then be tested against a set value [<, <=, ==, >=, >] and this test can form a Pause or Condition. [If they havent been set/defined yet they will return as 0.]
There is no strict naming convention, but typically quest related facts start with the quest code [Ex: mq055_... sq027_...]
Facts that are used in a similar way will also have a similar naming sceme [Ex: radio_on, tv_on; judy_default_on, panam_default_on]
Editing quest facts might solve your immediate problem, but will almost always cause additional problems much later in the game, which are impossible to predict. E.g., while you can fix the missing phone call right now, this might break an elevator during the final quest. (I am not making this up)
Cyberpunk's quest facts don't actually do anything, they simply store a value that can be checked later - it is this later check, and logic that is set to follow, that actually does something. For an example, check the box below.
Quest facts are most often set and used in .questphase
(and .quest
) and .scene
files. They can also be manipluated in scripts [Ex: Changing cyberware at a Ripperdoc sets certain facts] and also directly in the code.
None of them, they are independent entities. However they can, in some are cases, be compared to each other [<, <=, ==, >=, >]
For a json dump of facts grouped by .quest, .questphase and .scene, follow this Discord Link.
Written by Published: 09. 12. 2023
This page gives you an overview about lights at a glance.
To learn about shadows in the world, check Environment: Shadows
To learn about shadows for equipment items, check Meshes, Shadows, and Shadow Meshes
For a guide how to add lights to AMM props, check AMM light components
For a quick overview on lights and their properties, check Cheat Sheet: Lights (currently WIP)
If you want to learn more about blocking light, check Occluders and light blocking
IDK either! But maybe someone edits the wiki :/
Cyberpunk uses three types of lights:
The light is a sphere and is equally bright in every direction
The light is a cone. The sharpness is defined by its inner and outer angle.
The light is a square (like a light panel).
Published: Feb 09 2024 by Last documented edit: Feb 09 2024 by
Explanations of what is known about .behavior files, which govern aspects of NPC A.I. and connect to various related TweakDB records.
The functionality of .behavior files is still being studied so the information below may contain some errors.
Behavior files are node graphs (currently browsable only in list form) responsible for determining A.I. responses to various stimuli based on specific conditions. For instance, the hit_reaction.behavior file works in tandem with other files to establish how NPCs react to certain kinds of hits, and determines which NPC types are excluded from which behaviors.
Here is an example of the GuardbreakReactionTask node being established in state 4 of hit_reactions.behavior.
That node can be replaced with any other node compatible with the script slot, so you can make something else happen, or make the game crash, or an exciting combination of both.
The .behavior files can also point to different .behavior files. Here we see state 5 of hit_reactions.behavior referencing wounded_entry_se.behavior, which details some of the wounded actions such as walking with an injured arm. State 5 also calls the PainReactionTask script:
Navigating these files in list form can be confusing, so let's go step-by-step into state 2, which is the Knockdown state:
This goes down quite a few layers. The task node is what happens in that particular layer, and the child nodes take you into the deeper layers. In this case, the knockdown animation is being cached for potential ragdoll. Here's what that looks like:
When the child node is uncollapsed, it shows its own nodes, which may contain a condition for its task to occur:
This particular condition calls a TweakAIActionCondition node, which connects to a TweakDB record. The record being used checks if the victim of the knockdown is a civilian not currently engaged in combat. Remember that conditions may be set inverted, so that the opposite condition is what triggers the task. TweakDB records may also contain their own conditions inside them, inverted or uninverted, so it's good to uncollapse them and take a look.
When you open the child node affected by this condition (above it), it uncollapses into a TweakAIAction node which connects to a TweakDB record. The actual record requires that you scroll down quite a bit to get to it. You will come to hate this node.
The record seems to determine that if a civilian is knocked down while out of combat, they should stay down indefinitely, which is consistent with how it works in the game:
You may have noticed that the record itself contains an activationCondition entry. That's one place in which you'll find conditions set by TweakDB records, so again, you should verify those on every TweakDB record you see, regardless of whether it is under a task node or a condition node. And remember to also check if any of those conditions are inverted, and if there are sub-conditions elsewhere in the record. This is your life now.
Now we go back to the other child node of state 2, which determines what happens if the knocked-down NPC is anyone other than an out-of-combat civilian. When this child node is uncollapsed, it disgorges two more child nodes, and the Inception theme starts playing.
The first of these great-grandchild nodes just calls the KnockdownReactionTask, which you can replace with any other compatible task to see what happens.
The other great-grandchild node is another TweakAIAction node. The TweakDB record it connects to is seemingly what makes armed NPCs shoot aimlessly during the knockdown animation. This record has several other conditions inside it with sub-conditions so let's not make the mistake of uncollapsing it.
Instead let's go back one layer, because there was still one child node next to the child node whose child node we were just checking. The following image will hopefully clarify that cursed sentence:
This child node, which is mercifully the last of its dynasty in state 2, leads to a TweakAIAction node. If you scroll down to about the depths of the Mariana Trench, you will find the TweakDB record it's connected to. It deals with how NPCs stand up from being knocked down.
Out-of-combat civilians are excluded from this behavior, tragically condemned to remain forever horizontal should they be sucker-punched by a player wanting to test their new gorilla arms. This exclusion was determined in the first child node of state 2, in case you understandably forgot by now.
It is important to note that .behavior files do not exist in isolation; the hit reaction system, for instance, is reliant on multiple files and functions. This synergy has to be taken into consideration when editing or replacing nodes in .behavior files, and the conditions established in these nodes or in the TweakDB records they use must be verified. They may, for example, exclude bosses from certain behaviors, so deleting those nodes can cause considerable issues.
How occlusion controls what you see (and what you can't see)
Occluders hide stuff from you. I haven't understood this well enough to document it, but I've been begging people for months and nobody writes anything, so I'm dumping the corresponding Discord posts here in case anyone wants to clean them up.
Original post by Deceptious on Discord:
Assuming that the PVS system (a whole other element) is loading whatever is on the other side of that door way, just removing the door isnt enough, if there's an occluder over the whole thing, everything behind it is being ignored (like on the right)
Everything in the game is already inside something, those somethings are the sectors The game only loads sectors relevant to where the player currently is: The Potential Visible Set, PVS
And it then only tries to render what it needs to, so even if its loaded, if it's hidden behind the player, or behind an occluder it wont bother
Once it's ignored all the stuff it doesnt care about because it's determined you cant see it, it can start to question if you're even close enough to see it, and if so, what LOD?
Some objects/entities might have their own occluder meshes for visibility testing (testing if something else behind it is hidden or not), because testing behind an actual model is more complicated then a basic shape, similar to having lower poly shadow casting meshes
Objects that are being tested, to see if the camera can see it behind an object/occluder probably dont use their actual mesh for the test either, way too complicated So it will probably just use a bounding box This is why sometimes, in games, moving characters can pop-in when moving from out of cover, if the bounding box wasnt big enough, and a limb (or maybe they dive/slide) comes out of the bounding box, the box might still be occluded, but the whole character isnt, so they effectively enter frame and are kept invisible until the BB enters the frame too and thats when you'd get the pop
You have to add a node to the world sector:
This page explains how the level of detail is handled in environment files.
To learn how components (equipment) casts shadows, check Meshes, Shadows, and Shadow Meshes
Many world objects are automatically hidden if you move away from them, freeing the engine resources that had been used to render them.
Hiding an object will also hide its shadows and occluders.
The distance at which this happens is controlled by the forceAutoHideDistance
property of each world node:
This probably corresponds directly to the nearAutoHideDistance
in the proxy mesh ndoes below?
There is a specialized node type for world proxy meshes: the worldGenericProxyMeshNode
. (Which raises the question if there are specialized / extended worldXXProxyMeshNodes?)
This page explains how shadows are configured for nodes in streamingsectors.
The shadow properties of the environment are configured in the properties of each node inside the .streamingsector
file:
Shadows are only cast as long as a mesh is visible.
A global shadow will not render small details — these will only be included if the castLocalShadows property is active.
Published: Jan 19 2024 by Last documented update: Jan 19 2024 by
Published: Mar 02 2024 by Last documented update: Mar 02 2024 by
Published: Mar 02 2024 by Last documented update: Mar 02 2024 by
To learn how components (equipment) casts shadows, check
What are CNames? How do they work?
Strongly recommended flags: Default
Represents a mandatory dependency that will be loaded together with the and is stored together with it. If reference fails to load, the resource holding it also fails to load.
If you use Soft
flag, you risk causing game crashes. The only acceptable use of Soft
flag in combination with rRef
is for dynamic paths used in ArchiveXL that start with *
character.
Compatible flags: Soft
Represents a dependency where the is only pointing at a resource.
Used by: #rref
Indicates that the engine should load the requested resource together with the .
Default is a recommended flag when you're unsure which flag to use.
Used by: #rref
When a resource is flagged as embedded, it is directly included in the holder resource. However, resources flagged as embedded might not work as expected if they live in inplace resources.
Used by: #raref
This flag is used for resources that are not immediately mandatory. It seems to be a more flexible reference that does not load the resource immediately but points to where it can be found when needed. It's used in root entities for referencing .app files, for example.
Unknown, but probably a legacy artifact from Witcher3
Unknown, but probably a legacy artifact from Witcher3
Unknown, but probably a legacy artifact from Witcher3
Published: Jan 05 2023 by
What is LoD and how does it work?
This page explains what Level of Detail is and how it works.
To learn more about Proxy Appearances, check the corresponding wiki page.
A high-detail mesh has a low Level of Detail, and vice versa. This is both intuitive and obvious, which is why there's an info box telling you about it.
The further away something is, the higher it's LOD will be (the less detail you will actually see, and the less detail will be rendered).
.streamingsector: forceAutoHideDistance
For equipment and weapons, that is completely fine, because you don't need them (melee weapons aside, read on).
For NPVs, you'll want to get rid of proxy appearances as well — we really can't be arsed to create custom ones.
Please don't.
First of all, the high LODs occasionally store other properties. For melee weapons, they are used to calculate the hitbox (or so we think, Mar 2024). For vehicles, they're needed for damage deforms.
And second of all, without proxy meshes, your GPU will catch fire if you look at Night City's skyline. Yes, even the Tesseract.
As of May 2024, we don't know for certain what the numeric properties stand for (maybe the distance from player at which the level of detail gets activated?).
LODs corresponds to renderLOD
s. LODs without an entry in renderLOD
will never load.
To learn more about Proxy Appearances, check the corresponding wiki page.
A proxy mesh is used as an extremely low-level stand-in to be loaded for distant objects. They will almost always have proxy
in their path or file name, and use a PBR material such as metal_base with low-resolution textures.
Example: Take a look at Johnny's proxy mesh under
Shadow meshes are used to generate shadows at low performance cost. You can find more detailed documentation on the page about Meshes, Shadows, and Shadow Meshes.
This lets you override the level of detail
Published: Mar 02 2024 by Last documented update: Mar 02 2024 by
That is due to Wolvenkit: the property will drop any submeshes for lower resolutions.
You can see submeshes and their LODs in the :
Details about the game's video format
This wiki page is about the .bk2 file format used in the game.
The .bk2 file format is used in many games including Cyberpunk 2077. It stands for Bink 2 and can be played and/or converted to regular video format or single frames using RAD Video Tools.
I wanted some screenshot of a Cyberpunk ad to print as a poster for a friend. That's how I ended up on this journey to find how to get a readable video from the game files.
WolvenKit (obviously)
RAD Video Tools (available here, 2mo)
For example in this wiki page, I'll use the NiCola ad as an example. You will want to have a WolvenKit project created for easy access to the video file.
In Cyberpunk, all the video files have the .bk2 extension. Thus, you can just search .bk2 in the search bar of the asset browser. Since I want the NiCola ad, I'll here search for nicola > .bk2
(See this wiki page for more about searching files).
Then add the file to your project for easy access
Assuming you have installed RAD video tools correctly (see Prerequisites), you should be able to open the file and it will play
For this, you will have to open RAD video tools from the search bar/start menu/whatever if you don't use Windows.
Then, navigate to the .bk2 file and press on Convert a file (see screenshot)
Then, in the opened window, you can configure the output, file format and location. You can then press convert on the right side of the screen.
And now you have the video you want in the format you desire. You can also export individual frames if you want to!
Now you have everything, if you want to know more about the Bink Converter you can watch this video. Everything here have been found in the Discord community after a quick search in there.
How do effects work? How do I mod them?
See Effect componentsfor effect explanations by component
See FX Material Properties for animated materials
While explosions are definitely effects, lights are something else => Lights explained
This page is a stub, but this wiki is a community project! Please sign up and , we'd love to have you!
An effect's duration is defined in the .effects file:
You can find a particle's lifetime for the individual entries in the modules
array:
These are probably (?) overwritten by effect durations?
Published: Feb 11 2024 by Last documented edit: Feb 11 2024 by