-
Notifications
You must be signed in to change notification settings - Fork 48
How To Create Load Order Rules (read this before any rules creation!)
Create rules only for mods that interact with each other in the way that causes issues, you know exact mods that causes the issue (you have followed instruction below to do that) and you can replicate the issue, never create rule just because you think "that is a good mod order position".
To start the testing method you must first identify an error. An error usually appears as red text in the debug log once RimWorld boots. It may also appear as a bug in a new save game, with unexpected/odd behavior occuring. Adding or removing mods in an ongoing game will likely give false-positives and is poor practice. Adding/removing mods mid-game should not be done unless you know what you are doing and accept that responsibility. As always you should read mod descriptions/documentation and only report errors that are unmentioned. It should be noted that in all testing it is assumed you always load required depedencies for any mods.
Error examples:
- game crashes
- exceptions/errors (red text in console)
- warnings (yellow text in console)
- mod missing functionality after other mods enabled (gizmos, actions, etc)
- mod missing functionality that is added by other mods (items, hair, animations, etc. for races mods)
Once you identify errors you can start a binary search to single out the mods with conflicts. This is the most simple method, but also more time consuming that deciphering an error log. It will be the most practical method for most users.
A binary search requires that you de-activate half of your loaded mods from the active mod list. Then you restart RimWorld and see if the same errors/behavior persist. If the errors are still there, you remove another half of your loaded mods and restart the game (do not add the previously removed mods back into the active mods). You continue this process until the errors do not exist. As soon as the errors do not exist, you can assume the last batch of removed mods includes at least one of the conflicting mods. Now you can slowly add in the mods from the last removed batch, and single out which mod in that group is causing a conflict.
One way of doing this in an organized manner is by removing mods alphabetically. Remove all mods starting with letters M-Z
. If the error no longer exists, add mods M-Q
back into the load list. If the error exists again, remove P-Q
. Repeat this binary search until you narrow down the individual mod.
Once you have identified a mod that is causing a conflict, you must now identify if it is isolated to that mod, or if it is multiple mods conflicting. In order to do this, take note of/save the shortened mod list that produces an error after the first successful binary search. This mod list is your base mod list for identifying the conflict. Now you must test the conflicting mod alone.
After a successful binary search you must isolate the conflicting mod, and load it alone. This will let you know if it is a mod design issue or inter-mod issue. Loading a mod alone means that you only load Vanilla RimWorld and any required dependencies for the conflicting mod. If the mod loads successfully when alone, you may now assume it is an inter-mod conflict, and not necessarily a design issue with the mod itself (though still possible).
Now you have a base mod list that produces an error, and you have determined that the mod in question loads fine on it's own. The next step is a "reverse" binary search. This is essentially keeping the mod in question loaded, while removing the opposing half of the actively loaded mods.
Example Continued--
If the conflicting mod was in the letter M
section, then you will need to start removing mods in a binary search on section A-L
. So start with mods H-L
, and see if errors/bugs persist. Continue this binary search until you have isolated another mod.
Once you have isolated the 2+ mods that conflict, you may test load orders.
Testing load orders is fairly simple once you know the conflicting mods. All it requires is moving one mod above or below the other mod/s that cause conflict. In some cases this may solve your error, and then you may create a load order rule. If this does not solve the error you should report the conflicting mods the the mod author/s.
To create a rule, right click on mod, then choose "Modify/share sorting rule". That will open a dialog in which you may drag/drop one mod from the left column to the right above or below the selected mod. Click save to save your rule.
Bad Rules: Since any user may create and share rules, there may be situations when user will share a "Bad" rule. "Bad" rules do not fix anything and may create troubles for others. For example:
- in some situations you may resolve conflicts between mods with changing load order for only 2 mods. Meaning one mod must load above or below the other. Instead users may create rules that move many other unrelated mods. Do not do that. Troubleshoot with a binary search until conflicting mods are isolated, and rules are as simple as possible.
- users try to follow a categorical mod order guide and still use RimPy autosorting, because they believe it is the "right way". RimPy is intentionally not designed for categorical mod loading. Creating rules to fit mods into categories without a true need will break RimPy's conception and will end up with circular dependency issues. Submit rules only for mods that interact with each other in the way that causes issues and you are sure that issue exists after testing.
There are three types of rules you are able to create:
- Load after rules - mod will be loaded after another mod
- Load before - mod will be loaded before other mod
- Load bottom - mod will be loaded at the bottom of the list (loadAfter and loadBefore rules will also be applied to it)
There are lots of false suggestions to put mods at the bottom (from both users and modders), I ask you not to create any loadBottom rules. Instead of creating them, ask on our Discord server if we really need that rule. Otherwise database may be bloated with false rules and/or your rule packs may be declined to merge!