Capture the setup before attempting a fix
Record the game version, active expansions, mod release identifiers and active load order. Keep a separate copy of the colony save and relevant configuration while the game is closed. A screenshot of the mod list can help, but a complete exported list is easier for someone else to reproduce.
Copy the error log before repeated restarts replace useful evidence. Use the file-location table below, then verify that the log's last-modified time and opening version lines match the failed session. Review a separate shareable copy for private paths or identifiers; keep the original untouched.
Write one reproducible action: 'load this test colony, select this building, then click this command' is better than 'everything is broken.' Include whether the failure also happens on a fresh colony.
References: Ludeon forum: how to report a mod bug
Collect the evidence packet without deleting configuration
On Windows, paste the listed folder into File Explorer's address bar. On macOS, use Finder → Go → Go to Folder. These are candidate locations from the linked mod-project documentation, not a universal promise for every build. Copy files out; do not replace ModsConfig.xml with a file supplied for someone else's mod collection.
The Windows report linked below found Player.log under Logs rather than at the older data-folder root. If the root copy is missing or stale, inspect that subfolder. Match the timestamp and version to your failing launch before using either file. Missing an old path does not prove the game produced no log. For Linux/Proton or a custom data folder, use your installed launch configuration and current mod-manager documentation; this table does not claim those layouts.
- Stop retrying the failing launch. Record the game build, operating system, Steam branch if used, active DLC and the action that failed.
- Create a separate diagnostic folder with a date and short symptom. Copy the matching Player.log before another launch; if the game is still running, copy immediately, then keep a second copy after it closes if more errors were written.
- With the game closed, copy ModsConfig.xml and the relevant save from your actual save folder. Keep an untouched original backup outside the experiment. A mod-list screenshot alone does not preserve the complete active configuration.
- Write a small manifest: filename, modified time, installed build, active-mod order and the action that produced the error. If a previous-session log exists, label it separately instead of substituting it for the failing session.
- Use a fresh test colony for isolation. Before sharing, redact personal information from a duplicate log and send it only through the relevant author's requested channel. Do not delete Config or unsubscribe from everything as a diagnostic shortcut.
| System / evidence | Candidate location | What to keep |
|---|---|---|
| Windows data folder | %localappdata%low\Ludeon Studios\RimWorld by Ludeon Studios | Player.log at the root, or Logs\Player.log on the reported newer layout; use the failing-session timestamp |
| Windows active-mod configuration | Same data folder → Config → ModsConfig.xml | Copy while the game is closed; retain the active order, not only subscribed Workshop items |
| macOS log candidate | ~/Library/Logs/Ludeon Studios/RimWorld by Ludeon Studios/Player.log | Copy the matching session; if absent, inspect the build's configured log location |
| macOS configuration candidate | ~/Library/Application Support/RimWorld/Config/ModsConfig.xml | Copy the file; do not paste in a replacement mod list |
References: RimWorld Access: reporting bugs and log locations · RimWorld Access: configuration locations · RimSort issue 2552: Windows log moved into Logs
Separate a 1.7 version-label warning from a runtime failure
Ludeon's October 12 announcement says 1.7 changes the engine from Unity to Waylith and initially offered it on an unstable branch. It also says some mods can appear yellow because their version metadata has not been updated. Record the version you actually launched; do not infer it from a guide date or assume everyone in a discussion is on the same branch.
A yellow label without a reproduced error belongs in the compatibility-check branch: read the author's release notes and test only a disposable colony. An exception after a specific action belongs in the reproduction branch: preserve the first relevant error, dependencies and steps. Neither a yellow label nor a successful title-screen launch proves that removing a content mod from your old save is safe.
| Observation | What it establishes | Next move |
|---|---|---|
| Yellow version warning only | Declared version support may differ | Check author notes and installed build; do not name it the crash cause yet |
| Fresh unmodded test fails | Failure is not isolated to this mod collection | Preserve log and investigate base installation/platform |
| Base works; dependency-complete small set repeats the error | A narrower reproducible combination | Keep the exact versions and report the first relevant exception |
| Old colony fails, fresh colony does not | Save state or removed content may matter | Keep the original save and compare with its original mod setup |
References: Ludeon: Waylith and update 1.7 announcement
Check compatibility before changing load order
Read the author's supported game version and required DLC. Then inspect dependencies and any explicit 'load before/after' instructions. Installing the right mod for the wrong game release or missing expansion is not something a generic alphabetical sort will repair.
For a beginner colony, avoid combining several large overhauls that modify the same system. Examples include multiple work-priority replacements, combat overhauls or overlapping species/content frameworks. This is a risk-category recommendation, not a blacklist of specific projects. Keep one purposeful change until you understand its effect.
A popular or highly rated mod can still be incompatible with a new patch or another mod. Treat recent author release notes as more informative than lifetime subscriber count.
Create a controlled test
Use a fresh test colony, not the valued save, to establish that the game and chosen official expansions run without the third-party mod set. If the baseline fails too, investigate the game installation or platform problem first. If it works, add the suspect mod with all its required dependencies.
For a large collection, work in dependency-respecting groups. Removing half the files blindly can create new missing-dependency errors unrelated to the original problem. Keep a note of each tested group and the exact result so you can reproduce it.
When you find a minimal failing combination, test it again once. That confirmation is valuable to the mod author and prevents blaming a mod for a one-off symptom.
- Close the game; preserve save, list, configuration and log.
- Start a new test colony without third-party mods.
- Add the smallest relevant mod and dependency set.
- Reproduce the exact failing action.
- Record pass/fail; expand or reduce the set without breaking required dependencies.
- Send the minimal reproducible report to the appropriate author.
References: Ludeon forum: installing mods and reporting issues · Ludeon forum: how to report a mod bug
Do not confuse launching with safe removal
A content mod can leave references in an existing save. Removing it may allow the title screen to load while breaking a pawn, building, item or job later. Do not overwrite the original save merely because the first minute appears fine.
If the author explicitly documents safe removal, follow that procedure on a copy and inspect the affected systems. If no safe removal is documented, the conservative recovery is a pre-change save with its matching mod setup. Keep both copies until you have confirmed which state is usable.
Steam verification can check game files if the clean baseline fails, but it is not a guarantee to uninstall added mod files or repair a colony that depended on removed content.
References: Ludeon forum: installing mods and reporting issues · Steam Support: verify installed files
Write a report someone can act on
Use this structure: game version; operating system; active DLC; exact mod versions/load order; steps to reproduce; expected result; actual result; whether a fresh colony reproduces it; and a relevant log excerpt or author-requested file.
Report a mod-specific issue through that mod's requested channel. Do not send an enormous unsupported collection to a developer as proof of a base-game bug. Distinguishing a clean-game failure from a mod interaction makes the report substantially more useful.
Before you play
- Untouched save backup and mod list preserved.
- First relevant log captured and reviewed before sharing.
- Clean baseline tested with a new colony.
- Dependencies retained while narrowing the set.
- Original save not overwritten during removal experiments.
Frequently asked questions
Can I fix everything by sorting mods?
No. Order is only one variable. Unsupported versions, missing DLC, dependencies and overlapping changes need separate checks.
Which mods are safe to remove mid-save?
That depends on each mod and what its data changed. Follow the author's explicit removal instructions; this guide does not certify any collection.
Sources & revision notes
Editorial revision: October 24, 2026; not a gameplay test date. The reference notes identify source limits and version differences.
- Ludeon: Waylith and update 1.7 announcement (Official)
October 12 announcement read October 24, 2026. Supports the engine transition and version-metadata warning distinction; its initial branch status is not a live check of the reader's installation.
- RimWorld Access: reporting bugs and log locations (Community)
Mod project's own documentation read October 24, 2026. Supplies Windows/macOS log candidates and the need to preserve a log before relaunch; it is not Ludeon certification of all current paths.
- RimWorld Access: configuration locations (Community)
Mod developer instructions read October 24, 2026 for Windows/macOS ModsConfig.xml locations only. GamerWin does not recommend installing this project's configuration as a general repair.
- RimSort issue 2552: Windows log moved into Logs (Community)
First-hand Windows report dated October 19, read October 24, 2026. Corroborates a newer Logs subfolder; not a universal path guarantee or a GamerWin test.
- Ludeon forum: how to report a mod bug (Community)
Source checked September 11, 2026. Game options and platform support should still be checked in your installed version.
- Ludeon forum: installing mods and reporting issues (Community)
Source checked September 11, 2026. Game options and platform support should still be checked in your installed version.
- Steam Support: verify installed files (Official)
Source checked September 11, 2026. Game options and platform support should still be checked in your installed version.
October 24, 2026: replaced the instruction to find log paths elsewhere with a copy-only Windows/macOS evidence-packet workflow, a timestamp check for the newer Logs subfolder and a build-aware distinction between yellow 1.7 metadata warnings and reproduced errors. Older forum references are background only; no collection was played or removal certified safe.
How we research and correct guidesNo affiliate links or paid placement. Commercial disclosure.