Page Comparison

The Witcher 3 REDkit allows you to join forces with other community members and collaborate while creating mods!

Want to start a group project and combine the talents of different people? Let’s say you know some experts in creating entities, others making textures, some great sound engineers and level designers - the Editor supports sharing your homemade pieces of the mod with other modders to collectively craft even bigger and more impressive projects!

Workspace Setup

The REDKit REDkit searches three locations on your local PC for assets (game files to use):

• First there is the “local r4data” folder: It includes all the files that are shipped with the editor and is located at the locations where you installed the editor in (e.g. C:\Steam\steamapps\common\The Witcher 3 EditorREDkit\r4data)

• Second there is the uncooked depot. This is a folder you choose at first start of the REDKitREDkit. The editor will extract files (textures and meshes) from a local game installation into this folder. Creating the depot is required for the editor to run.

• Third there is the local mod workspace. This is your local mod project and can be any folder on your PC. You chose to open a mod project on app start.

The editor layers each of these three locations above each and “virtually overrides” the respective lower level. The resulting virtual file system is what you see in the asset browser.

Example 1: The REDKit REDkit ships with the quest graph for Blood and Wine. In your mod project you edit this file. This means you have two files with the same name (and relative path) on your PC: one time in the local r4data folder, and your edited file in your local mod workspace. Upon start, the Editor loads the mod workspace file only and displays this file in the Asset Browser.

Example 2: During the first setup, the REDKit REDkit uncooked the character textures for Triss. The textures are not shipped with the Editor, so the only location of these textures is in your uncooked depot. When you start editing these textures, you “check out” the texture file and will now be present in your mod workspace.

Collaborating on projects

This virtual file system has many advantages, also when you want to collaborate on a big mod project or use shared assets that the modding community created.

It is recommended to use a Versioning System, such as git and a provider to store the shared assets/mod project on a server (e.g. GitHub or GitLab etc).

A. Making a mod collaboratively

That way you all work on the same codebase. When someone wants to get the latest files, they can pull the assets from the server, and when they are finished editing the assets, they can push to the server again.

When cooking the mod, the REDKit REDkit will cook (process) the whole mod folder with all downloaded assets.

B. Making a mod with shared assets

Since you are only using shared assets and not edit them, these assets can be treated as if they were vanilla game files. When the shared assets are updated, you simply pull the latest changes into the folder. In your workspace you have your own files that may or may not depend on the shared assets.

When cooking with the REDKitREDkit, it will only process your mod files.

C. Advanced tricks when working on big projects

The virtual file system allows for some advanced use cases as well, such as modifications of vanilla game files or multiple asset sources.

Moving depot into r4data

• Since the files inside the uncooked depot are in fact simply vanilla game files it is safe to move all files in the uncooked depot into the r4data folder!

• This will leave you with a completely empty depot with which you can do all sorts of things.

• One idea could be to clone the projects shared assets into “uncooked” depot, overriding (but not overwriting!) the vanilla game files.

• Each group member may then work in their own workspace separately and without “polluting” the project files. That way they can “check out” shared assets or work on small parts of the project.

Example: A big group of modders work together on a massive “total conversion” of the game (e.g. porting The Witcher 2 , or adding Star Wars in the Witcher 3 Engine). Since this project may require changing many vanilla files to suit their needs, the group set up a GitHub repository with thousands of files. The project also has “working groups”, where one subgroup works only on meshes, the other group implements quests and the third group creates terrain. In order for all theses groups to work on the same files, they set up their local files as described above. When the terrain group finishes a part of the map, the quest group may for example simply download the latest terrain from their repository (the files will be put into their uncooked depot) and they can already without conflicts start implementing quests in their workspace. When the quest group has finished a quest, they push their local changes to the server, and another group can then pull these changes into their depot … and so forth.

Many repositories in sub-folders inside the depot

Another way could be to clone many different repositories into subfolders of the depot. That way no files have to be moved and many independent sources are supported (e.g. one repository contains only new Star Wars models, the other repository contains only upscaled generic textures, another only contains ported The Witcher 2 files).

This only works with new assets since the relative path includes the subfolders! But it is a simple way to collaboratively work with many different files and sources and keeps your project tidy.