Why the Same Mod Conflict Should Not Be Solved a Thousand Times

How frustration with manual Witcher 3 merges turned into W3CR: a system designed to preserve verified decisions instead of guessing them again.

Where it started When I started building a larger mod setup for The Witcher 3 again, I quickly remembered why heavily modded installations can become projects of their own. Installing a few mods is easy. Installing dozens is different: one conflicts with another at the WitcherScript level, a third needs a particular load order, a fourth modifies the same function for a completely different reason, and sooner or later Script Merger can no longer decide automatically which changes should survive.

That becomes especially entertaining when you are not a WitcherScript programmer yourself. Script Merger shows two or three versions of a function and effectively asks which code is correct. With two mods, you can open both pages, read comments and instructions, and try to understand the conflict manually. With dozens of mods, the process starts to feel like a separate technical job when the original plan was simply to build a setup and play the game.

At some point I became stuck on a very simple question: if one person has already understood a specific conflict between specific versions of mods, built a working merge and tested the result, why should the next person repeat the same intellectual work from scratch? A verified decision should be reusable. That idea became Witcher Conflict Resolver, or W3CR.

I did not want to build another Script Merger The obvious first idea was to make something like “Script Merger, but smarter.” The more I looked at the problem, the less I liked that framing. If two mods change the same function, software cannot simply inspect the code and magically infer both authors’ intent. Compilation is not proof either: a merge can compile perfectly while deleting important behavior from one mod or combining two changes that are logically incompatible. I could have built a larger layer of heuristics and tried to guess which answer was probably right. For a tool that modifies somebody else’s mod setup, however, “usually works” was not a standard I wanted. The core principle eventually became almost the opposite: when W3CR does not have enough evidence, it should not pretend that it does.

That led to the main result categories. AUTO_SAFE means the changes can be composed deterministically and safely. KNOWN_RESOLUTION means an exact reusable W3R recipe already exists for those sources. KNOWN_PRIORITY is used when the correct answer is not a code merge at all, but a confirmed override relationship between mods. Everything without an exact safe answer remains NEEDS_USER. That is not a missing feature; it is an intentional boundary. Stopping is safer than generating a plausible-looking mistake.

The most interesting part was not the merge itself Suppose a user manually resolves a difficult conflict and ends up with a working mod0000_MergedFiles. The most straightforward way to reuse that work would be to store the finished merged .ws file and distribute it to other users. That immediately creates several problems: the database would contain third-party source code, the result would be rigidly tied to particular file versions, and after one source mod changes, the old merge might still look reasonable while already being wrong.

W3CR therefore stores a way to reproduce a decision rather than the finished third-party code. This became the code-free W3R format. A recipe records the exact identities and hashes of participating sources, coordinates in the source/token stream, the required operations, and fingerprints of the expected result. When a recipe matches, W3CR reads the necessary text from the user’s own installed files, reconstructs the solution locally, and verifies the result.

In other words, the database does not say, “here is the correct WitcherScript; paste it.” It says something closer to, “for these exact inputs, this transformation was verified; reproduce it locally and validate the output.” That distinction became one of the project’s central architectural ideas: the decision can be shared without turning the database into a repository of other authors’ source code.

What happens when a mod updates? I deliberately chose a conservative answer. If the source semantics a recipe was bound to change, the old decision is no longer treated as automatically proven. The author may have changed something trivial, or may have rebuilt the internal logic of the function. W3CR should not pretend to know which one happened unless it has sufficient evidence.

For that reason the public resolver uses exact matching rather than fuzzy recipe guessing. I have separate maintainer-side tools for investigating version drift conservatively, but overlapping edits still remain unresolved instead of being guessed. The same philosophy applies to priority rules: if an old KNOWN_PRIORITY would now remove API still used by installed participant scripts, the rule is marked stale and blocked rather than followed blindly.

Community Database and the separate Collector Once a decision can be reproduced safely, the next question is how it can help more than one person. That is why W3CR has a Community Database and a separate Code-Free Community Submission Collector. A user first resolves a real conflict in the normal way and obtains a working merge. The Collector then analyzes the setup locally, binds candidate recipes to the exact participating sources, replays the captured decision from those sources, and verifies that the reconstructed result matches the user’s actual merge.

The Collector then creates a small ready-to-send submission ZIP. It contains recipes, hashes and fingerprints, validation results and metadata, but no game or mod .ws source files and no merged source. One point is important because it is easy to misunderstand: the Collector does not upload anything automatically and it does not update the public database by itself. The user sends that ZIP to me for validation. I review the submission, compare it with other evidence when needed, add a confirmed resolution to my maintained Community Database, and then publish the updated database through a new W3CR release on Nexus Mods.

So the Community Database is not a live server that the application constantly talks to, and W3CR itself remains offline. A submission is evidence that can be sent for review; it does not become a trusted recipe just because somebody clicked a button. Independent matching submissions for the same exact sources and result can corroborate one another, while conflicting results are surfaced instead of silently replacing each other.

Why the database is still small W3CR can work with a very small Community Database. It still analyzes conflicts, handles deterministic cases automatically, applies known recipes and priority rules, and leaves everything else to the user. But the long-term idea only becomes significantly more useful when people begin submitting real conflicts they have already solved.

That exposed a problem that code cannot solve. Most users are accustomed either to finding a ready-made compatibility patch or to resolving a conflict in Script Merger and forgetting about it once the game launches. The idea of “I already spent the time solving this, so I will send a reproducible decision to a shared database so the next person never has to repeat the work” is not yet a natural habit. The public database therefore remains intentionally small, although the submission mechanism is working and has already been hardened after the first real external contribution.

Load order is part of conflict resolution too Compatibility problems in The Witcher 3 are not limited to two red blocks of code in Script Merger. Sometimes two mods should not be merged at all; one is simply supposed to override the other through mods.settings. A resolver that treats every incompatibility as a code-merge problem would therefore be solving the wrong problem.

W3CR now has a separate load-order planner. It combines confirmed W3CR rules with declared mod requirements in one graph, preserves unrelated effective ordering as far as possible, assigns unique priorities, and blocks contradictory cycles. If A must be above B, B above C, and C suddenly above A, the program does not invent a compromise. During Backup + Install, the existing mods.settings is backed up, the new plan is applied together with the merge, and a load-order application failure rolls the newly installed result back.

Why Analyze and Build do not install anything The user workflow is intentionally conservative as well. Analyze reads the current setup and classifies what it finds without modifying anything. The user deals only with cases left as NEEDS_USER, after which W3CR builds a staging result. Only the separate Backup + Install step changes the installation, after backing up the previous merged mod and mods.settings. Analyze also records a fingerprint of the relevant mod, source and W3R context. If those inputs change afterwards, W3CR refuses to build from the stale analysis and requires a new one. On paper that sounds like a small safety feature, but these are exactly the details that separate a one-off personal script from a tool that can be trusted with somebody else’s setup.

What W3CR does today At the time of writing, the current public Nexus Mods release is W3CR 0.2.2.6 Alpha. The scope remains intentionally narrow: WitcherScript .ws conflicts, offline operation, exact and conservative matching, and currently a Python 3 + Tkinter requirement. There is still no built-in WitcherScript compiler invocation, and Community Database coverage remains small. Within that scope, the resolver can automatically compose deterministic changes, apply exact known W3R resolutions, use confirmed priority rules, detect stale priority assumptions, plan the complete mods.settings order, protect against stale analysis context, and safely fall back to NEEDS_USER when automatic composition becomes questionable. Recent releases also addressed real multi-mod edge cases where a larger stack could hide a genuine pairwise conflict, adding explicit pairwise validation before N-way automatic composition.

Why I built it I like W3CR not because it is my largest project, but because its central idea is barely about writing code. The starting problem seemed obvious: mod conflicts are difficult, so build a smarter automatic merger. During development, the answer shifted in a different direction: do not try to outsmart the human every single time; preserve verified human work and replay it only when the underlying conditions actually match. That idea led to exact source binding, code-free W3R recipes, result fingerprints, a separate Collector, the Community Database, AUTO_SAFE / KNOWN_RESOLUTION / KNOWN_PRIORITY / NEEDS_USER categories, stale-context protection, and a generally conservative attitude toward anything the system cannot prove. The principle behind the project is simple: the same difficult question should not need to be solved automatically a thousand times. Sometimes the more useful system is the one that learns how to preserve one correct answer. Project: Witcher Conflict Resolver (W3CR) on Nexus Mods