Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
A list of modding frameworks and libraries, and links to their documentation
In the context of Cyberpunk modding, the core mods are often interchangeable called "(core) frameworks".
If you are trying to troubleshoot your core mods, you can run the log file utility.
For an explanation of what the individual core mods do, see below.
ArchiveXL – TweakXL – Codeware – Equipment-EX
While the game natively supports mods, this would have had us limited to replacing already existing items, but we wanted flying cars. So a bunch of brilliant people drilled deep into the code of Cyberpunk 2077 and created a bunch of tools that let us do more.
The most prominent example of a core mod is the Skyrim Script Extender — fortunately, Cyberpunk 2077 is rather more stable.
Since this kind of mod interacts with the game on such a fundamental level, they are prone to breaking whenever CDPR changes their API. This is the reason why game updates break mods — we recommend to turn off auto-update and manually upgrading once the core mods you need have been brought up-to-date.
Redscript (Nexus | GitHub) is an open-source programming language and toolkit (currently includes a compiler, a decompiler and a disassembler), natively working with Cyberpunk 2077's scripting runtime.
The scripts are compiled into a binary format recognizable by the game engine. The final blob includes original game scripts with all changes from the mods, and creates r6/cache/final.redscripts.modded
Redscript supports importing native types and functions registered by mods based on RED4ext.SDK, allowing modders to extend scripting runtime functionality.
Some examples for existing mod include, but are not limited to
changing combat balance
editing NPC behaviour
altering the interface
adding or removing UI widgets
Requires RED4ext.
Cyber Engine Tweaks (Nexus | GitHub) is a framework with a LUA wrapper, which will let you access anything exposed via RTTI, i.e. all scripted and native types and functions, including those added using redscript and RED4ext. On top of that, it lets you bind hotkeys for custom functions and interact with the game's TweakDB database at runtime.
Changes made via CET's Tweak Browser are not persistent, because the TweakDB gets changed at run-time. You can use TweakXL or create a CET mod to apply your changes each time the TweakDB is initialized.
Lots of mods and scripts run on top of CET, tweaking the game in various ways from changing the weather to adding a wardrobe system before CDPR added one.
The perhaps most prominent example is Appearance Menu Mod (wiki | Nexus), which turns Cyberpunk 2077 into The Sims: Capitalist Dystopia.
RED4ext (Nexus | GitHub) is Cyberpunk 2077's equivalent to Skyrim Script Extender. It consists of two parts:
RED4ext Loader – Loads and manages .dll plugins from red4ext/plugins. Provides essential functions such as game version checking, logging, hooking, and some REDengine 4 specific helpers for plugins.
RED4ext.SDK – Contains the reversed engineered types and helpers to extend the engine. It can also be used independently of RED4ext loader. Originally written in C++, but there's also a Rust binding.
With RED4ext >= 1.13, you no longer need cybercmd. Make sure to uninstall it!
Requires RED4ext.
ArchiveXL (Nexus | GitHub) allows modders to load custom resources into Cyberpunk 2077. Working under the hood, it is the essential tool to add and extend rather than replace. It also includes script extensions to, for example, load UI widgets from any resources than only those available to the current context.
For ArchiveXL specific documentation, check the corresponding sub-page.
Requires RED4ext.
TweakXL (Nexus | GitHub) allows modders to modify TweakDB in the form of .yaml or .tweak files. It also adds a scripting API allowing redscript mods to apply changes during TweakDB initialization or dynamically.
Requires RED4ext.
Codeware (Nexus | GitHub) is a library and framework for redscript and Cyber Engine Tweaks mods. It exposes many engine types and functions that are not available by default and adds new functionalities regarding many aspects of the game, such as:
game events and life cycle
spawning game objects
manipulating world states
building UI widgets
accessing type information
... and much more.
Equipment-EX (Nexus | GitHub) makes use of every single one of the frameworks mentioned above to overhaul CDPR's wardrobe system. Extending it from 6 slots to more than 30, it lets you save an unlimited number of outfits and supports modded items.
Requires RED4ext.
RedFileSystem (Nexus | GitHub) is a library for redscript and Cyber Engine Tweaks mods. It exposes functions to read / write with the file system. It supports UTF8 text and Json formats. Modders can create, read and write files within game's directory. It can be useful to store custom data, for example in a mod's directory.
This will tell you what mods and scripts CET is loading, and if there have been any errors in the process.
If all goes well, it will look like this:
It will tell you which .reds files it has been loading, and if any of them failed.
Please note the warning in the log:
If the mod is working, ignore it
If the mod isn't working, this tells you what to check. You can't have mods installed twice!
If all goes well, it will look like this:
It will tell you which of the plugin DLLs it has been loading.
If all goes well, it will look like this (version numbers are fake):
Tells you which .xl files have been found and processed and what it has been adding into the game files upon startup.
If it loads correctly, you will see something like this:
Note that the example contains a bunch of warnings. That indicates problems with the modded files (which I ignore, since they are working),
Tells you which tweaks have been read and processed, pointing out errors and warnings in the process. If your custom item additions don't work, you might find a hint here.
If it loads correctly, you will see something like this:
Adding stuff to the game, for the major-leagues
Published: August 2023 by
As suggested by psiberx, the general usage documentation for ArchiveXL will be kept in this wiki for ease of use. You can find the readme on github or check the repository's wiki section.
ArchiveXL (nexus | github) is one of the core frameworks of Cyberpunk 2077 modding. Together with TweakXL, It allows you to add things to the game, such as
world sectors (deletions and additions)
custom lipsync maps
Translations (check #how-does-the-game-assign-display-namesfor a guide)
If you want to look up garment appearance slots: The princess is in another castle. Check Different equipment slots instead.
This page will document how to set item properties via tags & suffixes (the vanilla way), or via dynamic switching (new, cool, version >= 1.5).
Let's dive right in.
When adding items, you will normally offer multiple mesh appearances (variants), for example, the same shirt in black, white, and red. This is what you're modding for, after all: making cool things.
On top of having different colours, you also have different circumstances – for example camera states: not even Johnny Silverhand wears his sunglasses in first person perspective.
CDPR deals with this by using suffixes, which are tedious to use. psiberx has since created a better system (dynamic appearances or conditions), which are much easier to use.
For more detail on this, please see the sub-page ArchiveXL: Suffixes and Substitutions
Tags are a way to add extra information to entities or appearances. They are defined on their own sub-page: ArchiveXL: Tags
If you have ever tried to make ten colour variants of an item for two body genders with four different states of feet, then you're familiar with the struggle. Version 1.5.0 of ArchiveXL solves this problem by introducing dynamic variants, allowing you to define rules to hook up your yaml straight to the mesh entity. picking components and even appearances dynamically.
You can find more detail about this on the sub-page ArchiveXL: Suffixes and Substitutions -> #which-substitutions-exist
For a tutorial about this, check ItemAdditions: Dynamic Appearances
If you are a mod user and want to dynamically recolour an item, check the Recolours and Refits guide -> sub-page Emissive -> #switching-existing-colours
Here's an overview of how the dynamic variants work. By comparison, this is the old diagram. Especially for items with many appearances, the new way is much faster.
Published: ??? by Last documented update: August 2 2024 by LadyLea
This page will tell you about tags and how they can be used to influence item behaviour. It also teaches you how #adding-custom-tags can help you conditionally un-hide items.
Tags are used for calculating Garment Support score, see Garment Support: How does it work?
There is an own page for Influencing other items
Tags are a way to tell Cyberpunk that an item has certain properties and should behave in a certain way. This makes the game apply properties to your items, which can then be utilized by the game and ArchiveXL.
To apply visual tags to an item you must add them to visualTags property of your appearance definition or to visualTagsSchema of your root entity template.
Tags are case-sensitive!
| Tag | Effect |
|---|---|
Check #hiding-body-parts-diagram below!
Check the #foot-states section for more tags concerning Toggleable Feet.
Check the #setting-footwear-sounds for shoe sound tags.
Check the #root-entity-tags section below for more tags.
Tags to partially hide default arms and cyberarms are not available, however, you can make use of Chunkmasks with the aid of this component list for Arms and Cyberarms OR you can create your own Custom Tags.
There are a few tags that can be added to the root entity or in the .app file. Here's a list:
This only works for legacy ArchiveXL projects. If you're using ItemAdditions: Dynamic Appearances, please use conditional appearances in your .app file.
This will hide an item under certain conditions. Add the following tag to the root entity:
EmptyAppearance:FPP
You have the following other options to achieve the same end:
force_Hair
A tag that forces hair to show up while wearing a head item. By default, head items turn hair invisible. By adding this tag to the root entity, you can override this process.
force_FlatFeet
A tag that forces female V's feet to be flat. Only works with a foot item as $base in the .yaml: use this if you're making flat shoes and don't want female V's feet to look as if she was wearing heels.
This tag will turn feet invisible for mascV unless the user has switch feet installed. You want to apply this to a conditional appearance in the .app file (&gender=m)
If you don't want your new boots to sound as if V was barefoot, add one of the following tags to the #root-entity:
Custom tags let you set component chunk masks from the .xl file without the need of touching either .app or .ent file.
For this, it is mandatory that you have unique component names. If you include your modder name, it's unlikely that anyone will overwrite them by accident.
PartsOverrides can't un-hide components for you. It can only hide them. If you want to load a different mesh (for example, a de-formed hakama when wearing a kimono or haori), then you're flat out of luck.
By being clever about your submeshes, you can offer different versions of your mesh (cropped! No arms! No legs), and users only need to install an .xl file! No need to have different meshes or even different .archive files.
Not convinced? Pity, but if you find a new use case for those things, do edit it in!
Add custom tags in your .xl file (not in your .yaml!)
Simply add the tag to your appearance's tags array near the bottom of the individual entries.
How suffixes and substitutions work
Published: ??? by Last documented update: Feb 18 2024 by
This page will teach you about conditional appearance switching in Cyberpunk and give you an overview of existing suffixes and substitutions.
ArchiveXL did not invent suffixes. In fact, they are CDPR's solution to a problem, and they are annoying to use.
psiberx has found ways to make this less painful. This page documents these ways.
For a hands-on guide to Adding new items, check the corresponding pages in the Modding Guides section
Dynamic appearances have their own guide (see ItemAdditions: Dynamic Appearances)
There is an own page for Influencing other items
To conditionally hide items or parts of items, check Influencing other items or ArchiveXL: Tags (especially the section about #root-entity-tags)
Sometimes, you want to load different meshes/appearances under different circumstances. Before ArchiveXL 1.5, the only way to do that were suffixes — registering them in the .yaml, then adding one appearance for each variation in the root entity (so for 2 suffixes, you'd have 4 entries, for 3 suffixes, you'd have 8…).
Suffixes are outdated! Do yourself a favour and use dynamic appearances!
Since 1.5, psiberx has made it possible to use conditionals via dynamic appearances, which require a lot less of an overhead. (Personally, I've gone from 96 entries in the root entity down to 9!)
But while the solution has changed (and improved), the problems remain and require handling.
There are two body genders with different proportions, and you can't make them wear the same shirt (at least not without clipping). To solve that, you can do what CDPR did and have one variant per rig.
The suffix for the body is Male / Female, the ArchiveXL string substitution is {gender} and resolves to m or w.
ArchiveXL allows body modders to register a custom body tag, which can then be used for suffixes and for substitutions in dynamic variants. To learn more about this, check ArchiveXL: body mods and refits.
You can check the current foot state by running the following command from CET:
Sometimes, you need to hide parts of the item in first person. – for example helmets, since you don't want to have half a helmet floating in front of your face (unless you consider that immersive; most people don't).
The arm states represent the different cyberware. For example, since you can't hire the forearms for mantis blades, you can roll up the sleeves just for this. The definitions are:
If the arm states aren't working as expected, check if the table above is outdated by comparing the names with the source code.
You can check the current foot state by running the following command from CET:
To achieve gender equality in regard to foot states, you need to use Toggleable Feet. The substitution key for dynamic appearances is feet.
Feet states for male-rigged V are not supported by the base game. You need to install either a body mod, or Toggleable Feet.
If the foot states aren't working as expected, check if the table above is outdated by comparing the names with the source code.
You can check the current foot state by running the following command from CET:
Conditions are a feature of dynamic appearances . They can be used in two places:
Inside your .app file for appearanceAppearanceDefinition.name:
This lets you to select a different appearance based on body gender, camera state... (see the tables above).
By using conditional appearances, you can still make use of partsOverrides to use chunkmask hiding.
For a hands-on example, see ArchiveXL: Dynamic conversion guide -> #step-2-the-.app
Inside your mesh_entity.ent for component.name:
For a hands-on example, see ArchiveXL: Dynamic conversion guide -> #method-1-conditional-components
Substitutions are a feature of dynamic appearances . They can only be used inside your mesh_entity.ent.
Substitutions allow ArchiveXL to load a different mesh based on different circumstances.
For a hands-on example, see ArchiveXL: Dynamic conversion guide -> #method-2-component-substitution
Do yourself a favour and don't use suffixes! They are outdated - use dynamic item additions instead.
For a list of active suffixes, check the tables above.
You can disable suffixes by adding the following line to your .yaml entry:
the base appearance (with no suffix)
the most specific suffix collection it can find
V has a female body gender and you're in photo mode (third person camera). Your base appearance is called appearance_.
Since 1.8.0, ArchiveXL supports substitutions for #dynamic-appearances. You can use them in two places:
inside mesh entity components in the fields name, depotPath and appearance
in the .app appearances for the field name
For a tutorial about this, check ItemAdditions: Dynamic Appearances
If you are a mod user and want to dynamically recolour an item, check the Recolours and Refits guide -> sub-page Emissive -> #switching-existing-colours
Any placeholders will be interpolated at run-time (replaced with the correct value for your current state)!
If any of the placeholders aren't working the way you expect them, check if the table below is outdated by referring directly to the source. (Please update the wiki if that happens!)
Substitution will only become active if the property name starts with an asterisk (*).
For #dynamic-appearances, you can conditionally switch out components or entire appearances by name. You can switch use any of the entries from #which-substitutions-exist
The order works as follows:
How to convert your mod to use dynamic variants... in ten minutes
Published: June 30 2024 by Last documented update: June 30 2024 by
This page will teach you how to convert your existing ArchiveXL mod to the "new" system.
An ArchiveXL mod that you want to convert
We will go through the process step-by-step. I'll explain what I'm doing as I go along.
Instead of one entry per item variant, we only need one entry per item.
Our variants are defined via $instances and generated via substitutions. Let's take a look at this:
You'll notice that the displayNames are different now. I could prevent that by writing my_shirt_localization_name_$(shirt)_$(ribbons), but this is a great chance to clean up the historically-grown mess.
We deleted the appearanceSuffixes (we'd only need them for Gendered preview icons, and we can't be arsed with that)
We defined a list of $instances, which will generate all of our different appearances
We replaced all parts that are different with the corresponding key from $instances. The rest will be magic.
Defines the variants — you'll get a gold star for paying attention, but we're getting to that later (#step-3-the-mesh-entity)
Instead of one entry per variant and gender, we only need one entry in total.
Our appearance's name must still match the .yaml, but only up to the variant separator: we're going with appearance_root_entity_.
By leaving the appearanceName blank, we're telling ArchiveXL to re-use name. If you want to use a specific appearance name (or if you don't want appearance_root_entity_ in your .app), you can put something different here.
We added the DynamicAppearance tag to enable the feature
We deleted all appearances but one
We deleted everything variant-related from the appearance
We deleted the appearanceName, so that ArchiveXL will re-use name for the .app
Instead of one appearance per variant and gender, we will squash everything down so that we have only one appearance per gender. In #lets-simplify-this-even-further, I will teach you how to reduce that even further, but for now, we'll be going step by step.
We deleted all but one appearance per gender
We added the condition &gender=w and &gender=m
We deleted the partsOverrides
Gender matching now happens via condition. The different meshes for male and female body gender are loaded in the different mesh entity files.
For a full list of conditions, see ArchiveXL: Suffixes and Substitutions
Right! You've been paying attention! Let's take a look at that next.
We will only change a single field (meshAppearance).
Before, it was mesh_white_red (the default appearance), and each appearance overwrote it via partsOverride. We're now changing it to dynamic:
Old: mesh_white_red
New: *mesh_{variant.2}_{variant.1}
This is where file validation currently stops working (as of June 2024). If you make any mistakes here, you will always see the first mesh appearance.
By adding a leading *, we told ArchiveXL that this field is involved in magic (substitution in this case)
By replacing white with {variant.2}, we're using the second parameter from the yaml's appearanceName (shirt).
By replacing red with {variant.1}, we're using the first parameter from the yaml's appearanceName (ribbons).
Let's unpack this.
In this example, we have the following mesh appearances:
mesh_white_red
mesh_black_red
mesh_black_blue
By using ! in the appearanceName, we're telling ArchiveXL that everything after is part of the mesh appearance definition:
This is the reason why we've used only appearance_root_entity_ as the appearanceName, and not the whole ordeal.
The + in the variant splits it up. If we didn't have it, we couldn't use variant_1 and variant_2.
Let's compare our setup ( *mesh_{variant.2}_{variant.1}) to the alternative.
yaml:
Our meshAppearance would be *mesh_{variant}.
Without the split, we need to make sure to pass the variant exactly as expected.
Unless you got hopelessly lost, this should have taken no more than ten minutes, and your mod just works(tm).
You now have one root_entity entry, two appearanceAppearanceDefinitions in your .app, and one mesh_entity per body gender.
Currently, we have two mesh_entities:
Each of them points at a different mesh:
Delete one of the mesh entities and rename the other:
Delete one of your appearances, and strip the suffix name from the other, leaving only appearance_root_entity_.
Change the path of your partsValue to the only remaining mesh entity, and save the file.
This will only load one body gender (the one you defined in the mesh_entity).
You should use the other approach where possible; this is only documented here for the sake of completeness.
Just like with appearances, you can also use #conditions with component names.
Pro: Especially with many body mods, you can just put all the logic into the components
Cons: All of these components will be added to the player entity, even if half of them will be hidden. This is bad for performance, especially if everyone does it.
If you want several different body mods or feet state to use the same mesh, you can use ArchiveXL: Resource linking instead.
The best way of dealing with multiple meshes is to have a single component and let ArchiveXL handle all the heavy lifting by using substitutions in the path:
This is our mesh's depot path:
A combination of
Published: ?? by Last documented update: October 26 2024 by AllKnowingLion Minimum required ArchiveXL version: 1.5
This page explains how to enable body mod support in ArchiveXL:
To learn more about body mods, check the page.
Run the following code snippet in CET to see which body is currently installed:
NOTE
The past method of adding the components to each individual appearance . However, you'll want to use the new method (for version >= 1.14), since it is both more robust and less tedious.
Starting with version 1.14, you can use to inject your tags into the existing files!
You can download the , or create one yourself.
Create an .xl file in your Wolvenkit Project's resources folder (File -> New file -> ArchiveXL)
Optional: Name it the same as your current project (e.g. boobs_for_back_problems.archive.xl)
Put the following file content:
If you downloaded the template project, a patch .ent will already be included.
Inside the patch .ent, find the entMeshComponent under the components array.
Change its name to match your body mod, e.g. Body:BoobsForBackProblems -> Body:NewBody
Make sure that your patch .ent is added to the game by telling ArchiveXL about it. Add the following block to your .xl file:
Include only the relevant body gender!
That's it, everything should work now! Let's test.
Launch the game and load into a save
If yes: Congratulations, you've made it much easier for people to add refits for your body!
The process is so simple that there aren't many things to go wrong:
If that doesn't work, check if the component gets added correctly. There are two ways to do this:
If a mod supports body tags, ArchiveXL can detect the current body mod, and conditionally load the correct mesh. Now, everything can be put into a single .archive!
If no body mod is installed, the value will be base_body, so make sure to name your files and folders accordingly!
If you're sticking to the classical approach, you need to add the following lines to your .yaml:
The following body mods support dynamic body switching.
How to change item stats with TweakXL
Last documented edit: Feb 09 2024 by
Changing item stats happens by making changes via TweakXL or REDmod in the .
You can find more information about this on the .
You can change tweaks with
REDMod (see )
Cyber Engine Tweaks (see Scissor's tutorial ())
TweakXL (see )
If possible, you should stick to TweakXL for editing tweaks.
If you want to safely delete a record property, set its value to None.
Published: May 18 2024 by Last documented update: May 18 2024 by
Starting with version 1.14, ArchiveXL allows you to create resource symlinks. This guide will teach you how to avoid duplicate meshes for dynamic substitution that way.
If you want to avoid duplicate material definitions, check .
While has solved one problem, it introduced a new one. If you want to use the preferred approach of mesh path substitution, then you'll end up with a million duplicate files.
Rhetorical question, it's not. But body types don't care.
This is where linking comes in.
Like most other things, you do this by adding a block to your .xl file. The example below will re-use the item for rb (Hyst's realistic butt) for both ebbrb and ebbprb (boobs in various states of push-uppery):
And just like that, we have one mesh instead of three.
Now we can do away with the extra components and simply use body mod substitution — and anything duplicate can be linked.
You can now also give your .mesh files passive aggressive filenames and then use substitution to hook them up to the body mods. The possibilities are endless!
Modify resources in a non-conflicting ways and reuse definitions.
Published: May 18 2024 by Last documented update: July 23 2024 by
The example below uses mesh materials, but these aren't even the tip of the iceberg. By using this technique, we can re-work everything, from CDPR's messed-up material paths up to the character creator.
Until the more comprehensive knowledge drops, this guide will be a placeholder.
This page explains resource patching, a very powerful ArchiveXL feature that lets you modify resources without conflicting with other mods or even game updates. Also allows you to reuse e.g. material definitions in multiple meshes, possibilities are endless!
For the most efficient way to define multiple materials, check out !
While has solved one problem, it introduced a new one. You now have a bunch of meshes inside your .archive, and you have to copy the materials across each of them.
Not only does resource patching fix that issue, it also allows multiple mods to modify the same resource without conflicts! Now you can have multiple mods add appearances to the same weapon and more.
In general, have a file that contains your changes (and only your changes), this is your "patch file". And you should know what file you want to patch, the "target file". Add the following code to your .xl file:
You can patch multiple files with the same or different files, as many as you'd like. (Don't duplicate the first two lines)
Example: If you have many meshes and want to share materials between them, don't define materials in your mesh files, instead have another mesh file with just the materials! Then add the following lines to your .xl file:
And just like that, it will work. All your meshes will have the materials you defined in your material mesh and any change to it will propagate to the patched meshes.
You can patch pretty much any .ent, .app or .mesh file! Give it a try via .xl file.
appearances (added/replaced appearances use materials from patch mesh)
After patching, appearance_black would use metal_base.remt, while appearance_black_2 would still use multilayered.mt.
You can patch appearances, components, entity, visual tags
You can patch definitions (components, parts values, parts overrides, visual tags)
Some things are scattered across multiple files — for example, there are different player entities for first and third person. Fortunately, ArchiveXL solves this problem in the cradle by defining patchable scopes. You can find examples on the github repository:
Use them like this:
This will include all the needed files for patching without the need to specify each of them manually.
If it becomes necessary, you can expand scopes and add your own files to them. For example:
You can't overwrite scopes, and you can't remove anything from them. Only appending is possible!
Changing the game's database entries
For a detailed guide with many explanations of properties, check the second half of
TweakXL ( | ) is a mod by psiberx. It lets you alter Cyberpunk's , changing properties of NPCs and items or even adding new entries.
By placing .yaml or .tweak files in Cyberpunk 2077/r6/tweaks, or .xl files in Cyberpunk 2077/archive/pc/mod.
No matter the file extension, the file contents must be .yaml or .json
Explanation of the database:
Additional information: TweakXL
Preserved for posterity - do not use this
With ArchiveXL 1.14, this information is outdated. It will be preserved for posterity, but you should use the current method under instead.
In any of the files you modded, check your components:
morphtargetComponent?Yes:
Add a tag with the exact name of your body in this component's tag array (for our example, NewBody)
No:
Add a new component (of any type) and give it the following name:
Body:NewBody
If you edit the leg component for female V, you must change both the regular and the flat feet component:
base\characters\common\player_base_bodies\appearances\l0_000_base__full.app
base\characters\common\player_base_bodies\appearances\l0_000_base__cs_flat.app
The files below have been confirmed to work — make the changes stated above to each of them:
The list of files below is known to be incomplete. At the very least it will not cover Male V as they appear in a mirror. Even more so than for Female V, please use the currently recommended patching based method.
If yes, you're good to go!
If not and you have used a component, check if it's added to the playerPuppet, either via CET:
| Tag | Effect |
|---|---|
| Camera mode | Suffix | Substitution | Condition |
|---|---|---|---|
| Cyberware | Suffix | Substitution | Conditional |
|---|---|---|---|
| Character | Footwear | Suffix/Tag | Substitution | Condition |
|---|---|---|---|---|
| Suffix | Explanation |
|---|---|
| full appearance name | |
|---|---|
| Placeholder | Substitution |
|---|---|
| Appearance/Component | Priority | Description |
|---|---|---|
We'll make use of for this.
by running the CET command.
Update
Double-check your .yaml via and make sure you don't have syntax errors (indent matters)
Check
If that still doesn't work, consider using the , which has been tried and tested on May 18 2024 with ArchiveXL
Make sure that your mesh has appearances and materials. If you are using , it's easy to forget a new body's mesh in the list like a gonk. This has never happened to the author, by the way.
Even with the , the process of supporting body mods is tedious. And even worse: you then have to pack everything separately for Nexus:
If you're using , you don't need to register a suffix and can simply match or substitute for the body tag:
Now, you can use the suffixes in your just like camera states or body genders:
If you know something that should be on the list, please edit !
As of 18th March 2024, is compatible again with Gymfiend Body Mod.
Use only one main archive! []
| Mod | Tag name | substitution value |
|---|
:
REDMod can do the same, but doesn't offer you features.
While will let you keep your materials in one spot, why would the chest size be relevant for a pair of socks?
the
After packing your project, by running the CET command.
or via :
hide_Head
Hides head.
hide_Torso
Hides the whole torso (0, 1, 2)
hide_LowerAbdomen
Hides lower abdomen. (3)
hide_UpperAbdomen
Hides upper abdomen. (2)
hide_CollarBone
Hides collar bone area. (1)
hide_Arms
Hides the whole arms, including hands. (There's no easy way to partially hide arms, you would have to create custom tags)
hide_Thighs
Hides thighs. (4)
hide_Calves
Hides calves. (5)
hide_Ankles
Hides ankles. (6)
hide_Feet
Hides feet. (7)
hide_Legs
Hides the entire legs (including feet, 4, 5, 6, 7)
HighHeels
Turns the current (shoe) item into high heels. (Item's yaml $base must be a foot item)
FlatShoes
Turns the current (shoe) item into flat shoes. (Item's yaml $base must be a foot item)
Root entity appearance (without dynamic variants)
name: my_appearance&FPP
.app path: base\characters\appearances\player\items\empty_appearance.app
default
.app conditional appearance: change default appearance name
name: my_appearance&camera=tpp
ArchiveXL will automatically add empty appearances for anything you have not defined
.app conditional appearance: add empty appearance yourself
name: my_appearance&camera=fpp
no partsValues, no components. Do not do this - use the line above this one instead!
First Person Perspective
&FPP
fpp
&camera=fpp
Third Person Perspective
&TPP
tpp
&camera=tpp
None
&BaseArms
base_arms
&arms=base_arms
Mantis Blades
&MantisBlades
mantis_blades
&arms=mantis_blades
Monowire
&Monowire
monowire
&arms=monowire
Projectile Launcher
&ProjectileLauncher
projectile_launcher
&arms=projectile_launcher
Female
Unequipped
&Flat
flat
&feet=flat
Female
Equipped (default)
&Lifted
lifted
&feet=lifted
Female
Equipped with HighHeels tag
&HighHeels
high_heels
&feet=high_heels
Female
Equipped with FlatShoes tag
&FlatShoes
flat_shoes
&feet=flat_shoes
Male
Any
(empty)
itemsFactoryAppearanceSuffix.Gender
This item is gendered
When resolving the appearance name via rootentity.ent, the game will look for appearanceName&Female and appearanceName&Male.
itemsFactoryAppearanceSuffix.Camera
This item has special rules for first and third person camera
When resolving the appearance name via rootentity.ent, the game will look for appearanceName&FPP and appearanceName&TPP.
itemsFactoryAppearanceSuffix.Partial
If the current item has hide_T1part part and slot OuterChest is not hidden, will search rootentity.ent for&Full or &Part
itemsFactoryAppearanceSuffix.HairType
Defines how your item will look if a certain hair type is loaded (e.g., hide the back half of a bandana for long hair).
When resolving the appearance name via rootentity.ent, the game will look for &Short, &Long, &Dreads, &Buzz, &Bald
appearance_
Found first, then ignored because a more specific appearance exists.
appearance_&Male
appearance_&Male&FPP
appearance_&Male&TPP
Ignored: V's body gender isn't male
appearance_&Female
ignored: a better match exists
appearance_&Female&FPP
ignored: you are not in first person camera
appearance_&Female&TPP
best match! The game will use this one!
{camera}
fpp or tpp
{gender}
m or w
{body}
base_body or body mod name in snake case
{arms}
base_arms, mantis_blades, monowire, projectile_launcher
{feet}
flat, lifted, high_heels, flat_shoes (empty for mascV!)
{sleeves}
full, part
{skin_color}
skin color name from customization, e.g. 03_senna
{hair_color}
hair color name from customization. e.g. black_liquorice
my_item!variant&camera=tpp
1
Has the highest priority because it requires a specific variant and one state condition.
my_item!variant
2
Has second priority because it requires a specific variant.
my_item&gender=w&camera=tpp
3
Has third priority because it has two state conditions.
my_item&camera=tpp
4
Has fourth priority because it has one state condition.
my_item
5
Has the lowest priority and will be used when no other elements match the criteria.
hide_H1
Hides an item in the Head slot.
hide_F1
Hides an item in the Eyes slot.
hide_T1
Hides an item in the Chest slot.
hide_T2
Hides an item in the Torso slot.
hide_L1
Hides an item in the Legs slot.
hide_S1
Hides an item in the Feet slot.
hide_T1part
Toggles the partial suffix (&Full →&Part) when applied to Torso item.
hide_Hair
Hides hair.
hide_Genitals
Hides genitals in uncensored mode and underwear in censored mode.
Lush |
|
Lush |
|
Ult |
|
Solo_OG |
|
SoloArms |
|
Song2 |
|
Angel |
|
RB |
|
EBB |
|
EBBP |
|
EBBRB |
|
EBBPRB |
|
Gymfiend |
|
Adonis |
|
Flat |
|
Atlas |
|
This is a tutorial created with new modders in mind. It's not optimal; it's slow, tedious, and redundant. However, it was the only way I could understand how to make YAML tweaks.
This is a tutorial created with new modders in mind. Some terms may not be correct, but you will be able to create a functional tweak with this method. It's not optimal; it's slow, tedious, and redundant. However, it was the only way I could understand how to make YAML tweaks.
Take into consideration that I'm not an expert, but I've helped a lot of people to start on tweaks and this knowledge will allow you to, at least, navigate more easily at first.
For this tutorial, you need:
Visual Studio Code (or Notepad++, but the tutorial will show you VSCode)
A bookmark for YAMLlint (you can check your YAML files for indentation errors)
Patience, lots of patience. Please, read this guide completely and re-read if needed.
After downloading and installing all the requirements (and yes, SAVE that bookmark, trust me), let's start with the basics.
YAML tweaks are like a decompiled version of the .tweaks files that you can find inside the REDmod folder. YAML format is easier to read and understand, but have some differences with REDmod syntax. You can also try and make tweaks using the REDmod syntax inside TweakXL, but personally I have no experience with that yet.
There are some concepts you need to understand before starting:
Indentation organizes code using blank spaces, as shown below:
In the past, using indentation wasn't mandatory and mostly used by pro coders to order their files as a good practice. However, for YAML files, indentation is MANDATORY. If you indent wrong, your mod won't work, simple as.
The best way to indent, in my opinion, is using 2 blank spaces (pressing space bar twice) to make indentations.
"But what about just using tab?" you may think. DON'T. DON'T USE TAB FOR INDENTATION. Using tab for indentation could cause issues, because not all text editors interpret tab in the same way.
Using double space will guarantee your file will keep the same structure everywhere. It even feels natural and VSCode will put nice and useful lines to show your indentation.
Think of records as unique containers grouping multiple properties — which can be other records, or #flats.
Record names must be unique!
You can't create two records with the same name — they will overwrite each other!
You can learn more on psiberx's github readme, or head over to Types of tweak records
Flats are values. They can be numbers (integers <like 1 or 2> or floats <like 1.5 or 2.3>), characters (even entire words) or boolean (True or False). They can be more complex things, for that I suggest you to read what Psiberx has to say about this.
This is where most new modders make mistakes.
Inline is a way to create records without nesting them under a record name, but coded and nested directly in the property of another record. Yeah, I know, it's hard to understand. Let's do some examples.
This example is a named record with other named records nested on it:
This is the same as above but with inline coding:
When to use inlines or whole named records? That depends on your project. Sometimes creating a record with a UNIQUE name will save you more space and work than creating it on inlines every single time. Sometimes it's the other way around. It's ok to even not using inlines at all if you aren't comfortable with them.
Later in this tutorial, you'll see that some records are named to something like this RecordName_inline0, RecordName_inline1, etc. Those inlineX names are created automatically for easier reading and the number can change without ANY warning on every single game update. The number generated will be dependent on the position of the inline record inside another record. Inline means literally "this is IN LINE X".
NEVER useinlineX records as base in your items, that will only create headaches for the future you. Using inlineX records as base for your items is a BAD PRACTICE and could prevent your mod from working on ANY update.
Please, DON'T USE inlineX RECORDS AS BASE FOR YOUR OWN RECORDS.
Let me explain it better with more examples:
In this example, this a record using inlines in update 2.1
In this example, is the same record, but on update 2.2
In this example, MyBigRecord_inline0 will have a completely different value depending on the update.
In update 2.1 the value1 and related to BaseStats.ExampleBaseStat1, but then in update 2.2 the value will be 8 and related to BaseStats.ExampleBaseStat3.
If you used MyBigRecord_inline0 in your item code, your item would stop working as intended. It doesn't matter that popular modders do this, DON'T USE INLINES AS BASE FOR YOUR RECORDS.
Check psiberx's YAML bible about inline records.
You'll see this word a lot inside TweakDB. Prereqs means Prerequisites and, as the name states, is used to check that certain conditions are met to start, for example, something like an Effector.
You can find more about this under Types of tweak records -> #prereq, or find a full list under Cheat Sheet: Prereqs.
Those are records that are used to be activated under certain conditions depending on their Prereqs. So Effector means "Something that activates some Effect". That effect could be almost anything, from stats to visual effects.
You can find more about this under Types of tweak records -> #effector
Tweaks and Scripts are 2 sides of the same coin.
On its own, a tweak does nothing — the engine makes use of the records via scripts.
Think of a script as the instruction, and a tweak as the definition. That way, a script doesn't actually need to understand what it's doing, and all the logic is neatly encapsulated.
For example: Take 500g (the instruction) of Items.Flour (the definition).
In this tutorial we will use Wolvenkit Tweak Browser. There are many ways of Browsing the tweak database, but you can save them for later, when you are more advanced (or feeling bold).
Having clarified some very basic concepts, let's start this guide:
Let's say you want to do a new item that have the Thrusters mechanics from Rogue Boots that you use in certain endings.
What's the best approach to this? Using those Thrusters boots logic in your item.
Unfortunately, most items don't share the same internal name as the name you can see in the description. The best way I've found to deal with this, is going to the community Cyberpunk wiki and looking for your specific item, in this case, those cool Boots.
Internally, that item is called q115_thrusters. Now that we know that, we can search the item in Wolvenkit Tweak Broswer.
Read Spawn Codes (BaseIDs/Hashes) for how to find an item's unique ID.
Open the Tweak Browser tab and pin it. It should look like this:
Paste q115_thrusters into the search bar and click on Filter... and activate Show inline records. This should look like this:
Do a right click into the first item and select Add TweakXL Override. Do the same for the inline0 and inline1, but ignore the rogue and weyland versions, we don't need that, just the first 3 results shown in this image:
Those tweaks should be stored in the left panel inside these folders in the image:
Put the cursor above the YAML files and click on the yellow folder to open the folder containing those tweaks in Windows Explorer:
Open the 3 YAML files in VSCode:
Now, from the latest inline (inline1 in this example), copy the whole contents and paste it below the anterior record (in this case, inline0):
Now, copy the mixed contents and paste them into the base record (the item on this case). This is how it should look:
Those records below the main item record (inline0 and inline1) are the ones that manages the Thrusters logic/mechanics.
You can add them to almost any item, but you'll have to research on your own how to do it on each case. Not all items needs the effects nested in the same places, and not all effects needs to be nested like this.
ALWAYS FIND A WORKING EXAMPLE IN THE BASE GAME IF YOU ARE NEW ON THIS AND IF YOU WANT TO KEEP YOUR SANITY. Trust me.
Now, the importance of VSCode in this tutorial. VSCode has an incredibly powerful and useful highlighting system for text by just doing double click on ANY WORD. With this system, you'll understand how things are nested on ANY item you find. Look at this example:
If you pay attention to the miniature code on the right side and the scroll bar, there is a highlight that will point you exactly where things are nested:
If you move over that highlight, you will finally have your answer.
This tutorial logic can be applied to ANYTHING that can be found in TweaksDB, how many inline records you are going to find will depend on each particular case. I picked a simple example to not extend this too much, but some items have more than 30 inlines... You are warned.
I've tested this method with many users, and all of them have been able to create their mods. This is not a way to do all items you have in mind, because is extremely inefficient, but once you understand how things are nested and how records are structured, you'll have a better time creating items afterwards.
I hope this will be helpful for you.
Thank you for reading, and good luck in your projects!
REMEMBER TO BOOKMARK THE PSIBERX YAML TWEAK BIBLE
You can also use this online tool to see if your YAML file has errors
Changing NPC's info on scan and its archetype.
Created & Published: October 19 2023 by Game Version 2.01
This tutorial will show you how to use REDmod to edit an NPC's TweakDB record, changing their info when scanning them with your Kiroshis. In this tutorial we will edit Panam
If you want to learn more about the Tweak database, check TweakDB: Game database.
the free REDMod DLC (you can get it here)
An IDE to edit .json files. I prefer Visual Studio Code, but you can also use Notepad++
Since we are using REDmod, we need to structure our project accordingly.
Open your in the Windows Explorer.
Find the folder mods. If it doesn't exist, create it.
Inside mods, create a folder for your custom mod — call it however you want. For this tutorial, we will name ours "example mod"
Inside your mod folder, create an empty text file with the name of info.json. This file will tell Cyberpunk how to load your mod.
Copy the following template and paste it into your empty file:
Inside your mod folder, create the following nested folders:
tweaks\base\gameplay\static_data\database\characters\npcs\records\quest\main_characters
Copy the following file to the folder main_characters inside your mod directory:
Cyberpunk 2077\tools\redmod\tweaks\base\gameplay\static_data\database\characters\npcs\records\quest\main_characters\primarycharacters.tweak
Your mod folder should now look like this:
To make changes inside, find an NPC with the properties that you want, and copy/paste the values into the record that you want to edit.
Open primarycharacters.tweak in your IDE and search for "Panam". You will find the following record:
We will take a look at some of the properties.
All existing factions are defined in the following file:
To change an NPC's affiliation, you will need to add the following line to their template:
That's, save your work, deploy your mod and hop in the game to see the results.
If you have any questions, you're welcome to join us on discord.
A tutorial on creating a custom blueprint to add additional attachmentSlots to an item
Created: Aug 01 2024 by Last documented edit: Aug 01 2024 by
This guide will teach you how to create your own blueprint by extending a base game record. At the end, you will have an assault rifle with muzzle, scope, and four mod slots.
A text editor like Notepad++
To learn more about records and flats, check How to YAML: Tweak modding basics -> #records and -> #flats. For the purpose of this guide, it's enough to say that Records can contain other records and flats, whereas flats can only contain values.
A Blueprint is a record of type gamedataItemBlueprint_Record with the following flat:
rootElement is a record of type gamedataItemBlueprintElement_Record.
It has the following flats (properties):
slot is a record of type gamedataAttachmentSlot_Record.
They have the following properties:
childElements is an array of records of type gamedataItemBlueprintElement_Record
prereqID is a record of type gamedataStatPrereq_Record
A blueprint can have 1 rootElement and each of the gamedataItemBlueprintElement_Record can have multiple other gamedataItemBlueprintElement_Record as children
In order for a slot to be usable in the game its parent slot has to already be filled.
We are going to make a custom blueprint that has 4 weapon mod slots for the Power Assault Rifles
At first make a new .yaml file and name it Items.Base_Power_AR_SMG_LMG_4Mod_Blueprint (the naming is not important and you can name it whatever you want).
Inside the yaml file, put the following content:
Now we need to define Items.Base_Power_AR_SMG_LMG_4Mod_Blueprint_rootElement we are going to use Items.Base_Power_AR_SMG_LMG_Blueprint_inline0 as a base for our rootElement and append two records for our 2 new Mod slots
The 2 new Weapon Mod Element records should be of type gamedataItemBlueprintElement_Record
Here we have to create 2 new prereqIDs
And we will need to create our custom AttachmentSlots
You can check the Cheat Sheet: Attachment Slots, or look up Creating custom AttachmentSlots to make your own.
We are going to create 2 attachmentSlots named
AttachmentSlots.Power_AR_SMG_LMG_WeaponMod3
AttachmentSlots.Power_AR_SMG_LMG_WeaponMod4
Now that all the necessary records are defined, we are going to add this Blueprint to the Weapon record
Items.Base_Power_Assault_Rifle as its name suggest is the base for power assault rifles so by doing this all the power assault rifles should now have this blueprint
The tweak part of making the blueprint is now over and we can jump in the game and check the records
We are going to use Preset_Ajax_Pimp as you can see the modSlots are not being shown in the game
For this, we are going to need to do some scripting lets create a new .reds file in the script folder and name it AR_SMG_LMG_4Slot.reds
We need to wrap multiple functions to make this work, so at first we are going to add a function that has our AttachmentSlots in it
And another function that checks for these slots
Now we wrap these 3 functions and add our slots to their return value
If we check the game now we can see that our slots are added but they are not shown correctly
We need to fix the slot Icons the tooltip names and the slot name
For the icons we wrap these 2 methods you can also use custom icon paths
For the tooltip names we are going to wrap this method
And for slot name
Now the UI is almost complete now we have to register these 2 slots to all the mods that can be equipped on the other 2
And now its done all of our power assault rifles now have 4 mod slots
How to manipulate vendor inventories
Published: ??? by manavortex Last documented update: Jan 28 2024 by manavortex
To find a list of all vendor IDs, check Cheat Sheet: Vendor IDs
Your mod will be one or multiple .yaml files under r6/tweaks. If you want to release your mod on Nexus, we recommend using and creating the files under the folder.
Courtesy of Neurolinked and psiberx. For more context, read up on Discord.
Create the following tweak file (a yaml in r6/tweaks/your_optional_subfolder:
Appearance Menu Mod
Appearance Menu Mod has its own documentation on their official Discord server.
You can find guides related to AMM by using the Wiki's search function. The Modding Guides section contains the following and more:
Open Wolvenkit and (for example, I have one project dedicated to research called TEST, which I use every time I need to search something on Wolvenkit), then open it.
| property name | value in Panam's template | explanation |
|---|---|---|
fullDisplayName
Which text is displayed in scan tab?
displayName
Which text is displayed in dialogues and choices?
archetypeData
ArchetypeData.SniperT2
base template (how she fights)
