Difference between revisions of "User:Trisscar"

From RimWorld Wiki
Jump to navigation Jump to search
(adding mod order reasons stuff)
 
(One intermediate revision by the same user not shown)
Line 33: Line 33:
  
 
There are some "ifs" and "buts" in this statement, but it's largely true
 
There are some "ifs" and "buts" in this statement, but it's largely true
 
 
Saved Game Files:
 
%appdata%\..\LocalLow\Ludeon Studios\RimWorld by Ludeon Studios\Saves
 
  
  
Line 85: Line 81:
  
 
> Verify Integrity of Game Files...
 
> Verify Integrity of Game Files...
 +
  
 
Change Game Version with Steam:
 
Change Game Version with Steam:
https://gfycat.com/heartfeltdarlingboa
+
 
 +
> Steam Library
 +
 
 +
> Right Click RimWorld
 +
 
 +
> Properties
 +
 
 +
> Betas
 +
 
 +
> "Select the beta you would like to opt into:"
  
  
Line 101: Line 107:
  
 
https://rwom.fandom.com/wiki/Mod_Order_Guide
 
https://rwom.fandom.com/wiki/Mod_Order_Guide
 +
 +
 +
--------------------------
 +
 +
 +
''
 +
'''An explanation of how this works code wise;'''
 +
 +
"Keep in mind that not all mod conflicts will be solved by shuffling load order around. Sometimes mods are just incompatible until the mod authors put in effort to fix their mods.
 +
 +
Sometimes mods will just be incompatible.
 +
 +
As with most things, the truth is a bit more fine-grained. It's true that "Core, Mod 1, Mod 2, Mod 3" is the load order, and the last mod "wins", but the actual load order is a bit different.
 +
 +
- XML
 +
 +
- xpath
 +
 +
- C#
 +
 +
The game first loads all XML (defs, mostly) from Core, Mod 1, Mod 2, Mod 3
 +
 +
Then it applies all xpath patches from Mod 1, Mod 2, Mod 3
 +
 +
Then it loads the C# from Mod 1, Mod 2, Mod 3
 +
 +
Core doesn't use xpath or load any C#, so they're not in that list. The C# for RimWorld is already loaded by that point, roughly speaking.
 +
 +
So if Mod 3 overwrites something in XML, but Mod 2 overwrites it in xpath and Mod 1 overwrites it in C#, it's Mod 1 that wins -- even though Mod 3 and Mod 2 come after it in the load order.
 +
 +
There are a few things that matter with load order:
 +
 +
- Does the mod require a different mod? Examples of that are mods that require HugsLib, Proper Shotguns, Turret Extensions, Alien Races, JecsTools, whatever. If you are missing a dependency, you'll notice: You get a nice red error saying something like
 +
Could not find type named TurretExtensions.CompProperties_Upgradable from node <A lot of XML> and missing a dependency like that will put the entire game in a corrupted and unplayable state.
 +
 +
And then there is another insidious thing some XML mods do: overwrite (abstract) bases. For that, I refer you to https://github.com/RimWorld-CCL-Reborn/AllYourBase. This is something that's still unfortunately very frequently done, and it can cause havoc.
 +
 +
The C# summary slightly diverts from the truth. It even depends on how they instantiate the mod; there are two or three possible hooks and they happen at different times. Most mods that mess about with Defs will all have to do it in the second or third hook.
 +
 +
There's inherit from mod, which happens before Defs are loaded. Generally mods can't screw around with Defs in there.
 +
 +
There's the staticconstructoronstartup annotation which happens after Defs are loaded. This is where mods would screw around with Defs, for the most part.
 +
 +
Finally there's Hugslibs' ondefsloaded, which is exactly like a staticconstructoronstartup, but it runs after the staticconstructoronstartup utility is done.
 +
 +
and fwiw: that's just the Defs side of the equation
 +
 +
I won't even mention the harmony conflicts (which are way harder to detect) or runtime conflicts (which sometimes get logged, but not nearly always)
 +
 +
take the world edit mod: I can't remember which page it was, but basically if you click next somewhere and from there on you get redirected to world edit's version of whatever the next screen would've been.
 +
 +
There's like.. almost zero chance of detecting that programmatically"''

Latest revision as of 08:49, 30 December 2020

testing:

---Troubleshooting things---

"My game broke/crashed/the UI is gone/froze, what do I do?"


You should:

Verify with Steam (if you use it).

Clear your configs (instructions below).

Check your mod order (instructions also below).

Make sure no mods updated since you last played, if a game that was running fine suddenly broke the next time you loaded it.




Basic Load Order Rules:

Mods must be loaded beneath any and all dependencies.

eg: most mods depend on Core to function and must load below it

Mods should not/cannot be loaded with other incompatible mods.

How do we know which mods are incompatible? Reading mod descriptions, asking people who know things, and trial/error

In the instance of multiple mods that change the same thing, whichever is loaded last will take precedent

There are some "ifs" and "buts" in this statement, but it's largely true


Local Mods:

Windows: C:\Program Files (x86)\Steam\steamapps\common\RimWorld\Mods

or C:\Program Files (x86)\RimWorld\Mods

Mac OS X: Right-click the RimWorld application and show package contents cd Library/Application\ Support/Steam/steamapps/common/RimWorld

Linux: ~/.steam/steam/steamapps/common/Rimworld/Mods;


Config Files:

--RimWorld configuration files and most mod settings are kept in this folder, and removing them will reset all settings to default.

--"Clearing configs" refers to deletion of old/all configs in the aforementioned folder

--Old mod config files are not automatically removed and may cause errors.

--Save the "ModsConfig.xml" as this is your mod load order, and if you remove it you will lose your modded load order. %appdata%\..\LocalLow\Ludeon Studios\RimWorld by Ludeon Studios\Config


Steam Default Install Location: C:\Program Files (x86)\Steam\steamapps\common

Steam Default Mod Install Folder: C:\Program Files (x86)\Steam\steamapps\workshop\content\294100


Verify Game Files with Steam:

> Steam Library

> Right Click RimWorld

> Properties

> Local Files

> Verify Integrity of Game Files...


Change Game Version with Steam:

> Steam Library

> Right Click RimWorld

> Properties

> Betas

> "Select the beta you would like to opt into:"


Load Order:

Rimpy is a useful tool that works outside the game, to make it easier to sort your mods. It also has it's own auto-sort function if you want to see if that will help your issue:

https://steamcommunity.com/sharedfiles/filedetails/?id=1847679158&searchtext=rimpy

There are also a few mod managers out there, both as mods and as external programs.

Another option for sorting your mods is to follow this guide here:

https://rwom.fandom.com/wiki/Mod_Order_Guide




An explanation of how this works code wise;

"Keep in mind that not all mod conflicts will be solved by shuffling load order around. Sometimes mods are just incompatible until the mod authors put in effort to fix their mods.

Sometimes mods will just be incompatible.

As with most things, the truth is a bit more fine-grained. It's true that "Core, Mod 1, Mod 2, Mod 3" is the load order, and the last mod "wins", but the actual load order is a bit different.

- XML

- xpath

- C#

The game first loads all XML (defs, mostly) from Core, Mod 1, Mod 2, Mod 3

Then it applies all xpath patches from Mod 1, Mod 2, Mod 3

Then it loads the C# from Mod 1, Mod 2, Mod 3

Core doesn't use xpath or load any C#, so they're not in that list. The C# for RimWorld is already loaded by that point, roughly speaking.

So if Mod 3 overwrites something in XML, but Mod 2 overwrites it in xpath and Mod 1 overwrites it in C#, it's Mod 1 that wins -- even though Mod 3 and Mod 2 come after it in the load order.

There are a few things that matter with load order:

- Does the mod require a different mod? Examples of that are mods that require HugsLib, Proper Shotguns, Turret Extensions, Alien Races, JecsTools, whatever. If you are missing a dependency, you'll notice: You get a nice red error saying something like Could not find type named TurretExtensions.CompProperties_Upgradable from node <A lot of XML> and missing a dependency like that will put the entire game in a corrupted and unplayable state.

And then there is another insidious thing some XML mods do: overwrite (abstract) bases. For that, I refer you to https://github.com/RimWorld-CCL-Reborn/AllYourBase. This is something that's still unfortunately very frequently done, and it can cause havoc.

The C# summary slightly diverts from the truth. It even depends on how they instantiate the mod; there are two or three possible hooks and they happen at different times. Most mods that mess about with Defs will all have to do it in the second or third hook.

There's inherit from mod, which happens before Defs are loaded. Generally mods can't screw around with Defs in there.

There's the staticconstructoronstartup annotation which happens after Defs are loaded. This is where mods would screw around with Defs, for the most part.

Finally there's Hugslibs' ondefsloaded, which is exactly like a staticconstructoronstartup, but it runs after the staticconstructoronstartup utility is done.

and fwiw: that's just the Defs side of the equation

I won't even mention the harmony conflicts (which are way harder to detect) or runtime conflicts (which sometimes get logged, but not nearly always)

take the world edit mod: I can't remember which page it was, but basically if you click next somewhere and from there on you get redirected to world edit's version of whatever the next screen would've been.

There's like.. almost zero chance of detecting that programmatically"