REDdeck

01Goal and the rules that follow from it

02How Cyberpunk mods are installed

Read on 2026-10-11 from a reference machine whose game folder Vortex manages (361 deployed files from 16 mods). A Cyberpunk mod is a set of files dropped into known places under the game folder. There is no plugin list like Bethesda games have; the folder is the registry.

03What Vortex solves, and what to keep

Vortex is an Electron app (React, Redux, TypeScript, GPL-3.0) with one extension per game. The Cyberpunk extension (version 0.12.1, by KellieAtTheLab) is 64 source files and defines 34 installer types, one per mod layout it knows how to recognise and fix up. Vortex itself keeps mods in a staging folder under AppData, hardlinks them into the game folder, and records what it did in vortex.deployment.json. The user is right that some of its complexity is unavoidable: the problems below exist whether or not the UI shows them.

04The UI

One view in the REDcode activity bar, or its own activity bar icon when REDcode is not installed. The main part is a list. Selecting a mod opens its detail panel in the editor area, a webview in the HUD style. The status bar shows one thing: whether what is deployed matches the list.

What each part does

• Checkbox turns a mod on or off. Nothing happens on disk until Deploy. The Deploy button shows how many changes are waiting, so the state is never a mystery.
• Add mod accepts a .zip, .7z or .rar, a folder, a bare .archive, or a Nexus link pasted in. Drag and drop onto the view does the same.
• Nexus opens the mod's Nexus page, checks for updates, and is where the API key lives. Without a key, the button still opens pages in the browser.
• Status is one short phrase in plain words: deployed, off, not deployed yet, update available, 1 conflict, needs RED4ext, file changed in game folder.
• Kind chips say what is inside, so a user learns the ecosystem by looking at the list.
• Detail panel (on select): description and Nexus page, version and update, the files it deploys and where, conflicts with the winner marked, load order position with up and down buttons, its REDmod info if any, Remove.

Plain words

05Architecture

Standalone, and loaded by REDcode

The extension lives in its own repository, REDdeck, under MIT, and is packaged and published on its own. It activates on its own events (its view, its commands, an nxm URI). REDcode's extension pack lists it, so installing REDcode installs it. When redcode-core is present, it does two things: it contributes "Install into REDdeck" to the project's packed output, and it hands its bridge client to reddeck through the exported API, which turns on archive-level conflict detection. When it is absent, REDdeck still manages the game; conflicts are then detected by file path only, and the detail panel says so.

The library

// %USERPROFILE%\REDdeck (default; user can move it, ideally onto the game's drive)
library.json                      // game path, game version, order, settings
library/
  trauma-team-subscription/       // one folder per mod, files laid out exactly as they deploy
    mod.json                      // name, version, kind(s), nexus {modId, fileId, md5}, enabled, added, files[]
    archive/pc/mod/TraumaTeamSubscription.archive
    archive/pc/mod/TraumaTeamSubscription.archive.xl
    r6/scripts/TraumaTeamSubscription/...
  testmod/                        // installed from a REDcode project: mod.json says source: project, path
downloads/                        // original archives kept for reinstall; md5 named
deployed.json                     // mirror of <game>\reddeck.deployment.json

Because each mod folder is laid out exactly as it deploys, "what will this do to my game folder" is answered by listing the folder, and a person or an assistant can inspect or fix a mod with a file explorer. The classifier's job is only to produce that layout once, at add time.

Deployment

• Deploy computes the difference between the manifest and the enabled mods, creates hardlinks (same drive) or copies (otherwise, chosen once at setup with a one-line explanation), writes modlist.txt from the archive order, runs redMod.exe deploy if any enabled mod is a REDmod package, and writes the manifest. Progress in the status bar, details in the Output channel.
• Undo deploy removes every file in the manifest and nothing else, then removes folders it emptied.
• Changes outside REDdeck. On Deploy and on view refresh, each manifest entry is checked. Hardlinks are checked by file identity like Vortex does; copies by size and mtime. Two cases reach the user: a file changed in the game folder (keep it, which imports it into the library, or put the mod's file back, the default) and a file missing from the game folder (put back silently, which is what the user meant by enabling the mod). Vortex's other two cases, the library file changed or removed, are the user's own edits in the library and simply redeploy.
• Conflicts between mods are resolved by order in the list: higher wins. Deploy links the winner. The detail panel shows what lost and why.
• Game version is read from the executable's version resource at every refresh. If it changed since the last deploy, the frameworks group shows which ones have a newer file on Nexus for it.

06Mod kinds and the classifier

Instead of 34 installers, one classifier with a short rule list. It walks the extracted archive, finds the deepest folder that contains a known top-level name, and maps every file to a target under the game folder. Files it cannot place are shown to the user in a tree with a guess, not rejected.

A mod can be several kinds at once; Drive an Aerial Vehicle on the reference machine is archive, reds, cet, tweak and audioware together. Kinds are chips, not categories, and a mod is never split into several entries.

07Conflicts, the part Vortex cannot do

Conflicts are information, not errors. Most are intentional (a texture replacer over a body mod). The UI marks them, explains the winner in one sentence, and offers reorder. It never blocks Deploy.

08Nexus Mods

09Living next to Vortex

• Detect. If vortex.deployment.json is in the game folder, REDdeck opens read-only: it lists what Vortex deployed, explains that two managers cannot deploy into one folder, and offers "Import from Vortex". The user runs Vortex's purge, then REDdeck deploys.
• Import. Vortex's staging folder (%APPDATA%\Vortex\cyberpunk2077\mods) holds one folder per mod already in deployable layout, with the Nexus mod id, version and timestamp in the folder name for mods that came from Nexus. Import copies them into the library, keeps the Nexus ids, and marks them on or off by reading which ones appear in the deployment manifest. Collection folders (collection.json only) are skipped.
• Never both. REDdeck refuses to deploy while Vortex's manifest is present, and writes its own manifest under a different name so Vortex refuses in turn.

10The REDcode and REDnode loop, and AI

11Risks

12Roadmap

13Open questions

• Library location. User profile by default, or next to the game by default so hardlinks always work?
• Should REDdeck manage the frameworks (install RED4ext, CET and redscript itself) or only recognise them? Managing them is friendlier and is what Vortex does.
• Launching the game. A "Play" button that launches with -modded when REDmod packages are on is obvious and friendly. Steam launches it through REDlauncher, which complicates this. Worth a small investigation.
• Which mods do you run on the big PC? A real list drives the classifier's test cases.
• Collections stay out, or is importing a collection's mod list (without Vortex) worth it later?