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.

  1. Stop retrying the failing launch. Record the game build, operating system, Steam branch if used, active DLC and the action that failed.
  2. 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.
  3. 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.
  4. 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.
  5. 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 / evidenceCandidate locationWhat to keep
Windows data folder%localappdata%low\Ludeon Studios\RimWorld by Ludeon StudiosPlayer.log at the root, or Logs\Player.log on the reported newer layout; use the failing-session timestamp
Windows active-mod configurationSame data folder → Config → ModsConfig.xmlCopy 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.logCopy the matching session; if absent, inspect the build's configured log location
macOS configuration candidate~/Library/Application Support/RimWorld/Config/ModsConfig.xmlCopy 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.

ObservationWhat it establishesNext move
Yellow version warning onlyDeclared version support may differCheck author notes and installed build; do not name it the crash cause yet
Fresh unmodded test failsFailure is not isolated to this mod collectionPreserve log and investigate base installation/platform
Base works; dependency-complete small set repeats the errorA narrower reproducible combinationKeep the exact versions and report the first relevant exception
Old colony fails, fresh colony does notSave state or removed content may matterKeep 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.

  1. Close the game; preserve save, list, configuration and log.
  2. Start a new test colony without third-party mods.
  3. Add the smallest relevant mod and dependency set.
  4. Reproduce the exact failing action.
  5. Record pass/fail; expand or reduce the set without breaking required dependencies.
  6. 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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. Steam Support: verify installed files (Official)

    Source checked September 11, 2026. Game options and platform support should still be checked in your installed version.

What changed in this revision

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 guides

No affiliate links or paid placement. Commercial disclosure.