CK3 Log Analyzer

This program analyzes `error.log` and sorts errors by mod directory.

✅ Automatically sorts found errors into files and directories.
✅ Option to use a text editor to open error lines.
✅ Built-in function to check mod compatibility.
✅ English and Russian language.
✅ Now includes multithreaded mod indexing (Workshop + Local Mods).

Even though it’s simple, it’s a useful utility. It makes navigating errors slightly easier, though not all. The parser still doesn’t understand error context — you’ll need to open the error line in `error.log` yourself and look nearby to find the context.

Some mods, especially older ones, use outdated pointers, triggers, or functions. This tool may slightly ease your search for bugs and fixes.

Regarding mod compatibility: no fancy tricks here. The parser checks which mods you have and which ones use the same files. It detects `00_holding` wherever possible. If the "other mods" list is too long, double-click it to open a separate window listing conflicting mods. This helps you decide whether to disable them or adjust their load order.

There was an idea to make a real-time parser with directory sorting, but my hardware nearly died from the load, and it worked poorly. So only static analysis.
Launch the game, wait until the main menu loads, then start scanning — it’s preliminary, as more errors will accumulate during gameplay.

That’s about it. Might be useful to someone.

Both variants are included in the folder:

— standard version (single-thread log analysis)., Workshop and Local Mods scanning.

— version with multithreaded mod indexing for faster Workshop and Local Mods scanning.

---

__ Both versions have the same functionality, only the internal indexing method differs. The test version.__

✅ **This hybrid approach proved to be the most stable and efficient solution:**

– No data loss or duplicated errors;
– Predictable output identical on any system;
– Noticeably faster mod indexing (Workshop + Local Mods);
– Simple, reliable, and easy to maintain.

Source code on GitHub [github.com]

Originally, the idea was to make the error log analysis fully multithreaded or even multiprocess — splitting `error.log` into chunks and parsing them in parallel.
However, after extensive testing, this approach was dropped for several reasons:

Errors in `error.log` can span several lines (some messages include full file paths, hints, or multi-line stack traces).
When the log is split into sections, these entries often overlap or are cut in half, which leads to repeated or incomplete parsing results.
The total number of detected errors increased unnaturally (e.g. 13 000 instead of the real ~9 000).

Regex-based parsing of plain-text logs is CPU‑bound and limited by Python’s Global Interpreter Lock (GIL).
Even with multiple threads or processes, most of the time is still spent interpreting regular expressions sequentially.
Benchmarks showed that multithreaded classification offered, at best, a 10‑15 % gain at the cost of twice the memory usage and potential instability.

Merging outputs from many threads, preserving strict line order, and filtering duplicates adds extra synchronization.
The combined overhead completely negated any benefit of multithreading.

The current design uses a single‑threaded, line‑order‑preserving classification that guarantees consistent and repeatable results.
At the same time, the most time‑consuming part — scanning tens or hundreds of mod folders — uses multithreaded indexing, which scales almost linearly with CPU cores.

There’s a recurring idea among players and modders —
a wish for the analyzer to perform deep compatibility checks,
automatically detecting which mods truly conflict with each other:
where one file overrides another, or where changes are only additions.
In practice, this is virtually impossible to implement.
Crusader Kings III (like other Paradox games) uses its own language — PdxScript.
Game data files are not simple text or JSON, but hierarchical structures built from nested blocks and keys.
When mods load, the engine merges these files according to internal priority rules:
some blocks are appended, others are overwritten, depending on key names and the loading order defined in the playset.
For an external tool to analyze such relationships correctly, it would need to:
🔸 Understand the full syntax and semantics of PdxScript
🔸 Emulate the game engine’s loading process and dependency chain
🔸 Reconstruct how all data layers are merged at runtime
🔸 Build a “virtual world‑state” of files, keys, and overridden values
In short — it would require re‑creating part of the actual game engine,
which is completely unrealistic for a lightweight parser intended only for analyzing error.log files.
Therefore, this tool focuses on surface‑level conflict detection:
it compares identical file names and paths across mods, helping to locate the most common and practical issues.
Anything beyond that would demand access to Paradox’s internal code or a true PdxScript interpreter —
something far outside the scope of any public utility.

— A utility for fixing the BOM encoding