Getting Started: Best Practices
This guide covers some best practices we recommend for mod authors as relates to backups, versioning, and mod conflicts.
Backups
One of the best practices you can follow as a mod author is to ensure that your mods are backed up in a location separate from your computer. Backups can be stored on an external hard drive, on another computer, or with a file-hosting service. Whatever your preference, a backup will ensure that if something goes wrong, a mod can always be restored to a previous version. We recommend using version control as it provides additional benefits:
- Maintains a history of changes.
- Allows changes to be rolled back to previous revisions.
- Enables authors to work together on the same mod.
- Acts as a safety net in the case of accidental deletions or errors.
Versioning
In general, versioning will be handled for you automatically (auto-incremented) and you don’t need to engage with it. However, setting a custom version number can be beneficial to signal to players how significant the changes of your most recent publication are.
Whilst testing mods, we recommend not touching the version and letting the Toolkit manage it. Then, when a mod is ready to be released, you can set the major, minor, and revision values in the Project Settings using the suggestions below. You can access these settings in Project > Project Settings > Properties.
Version numbers consist of several parts:
Major
The major number represents a large or significant change to a mod, such as the addition of new content or sweeping changes.
Minor
The minor number represents small but important updates to a mod, such as improvements or fixes.
Revision
The revision number represents small and unimportant updates to a mod, such as tweaks or adjustments that the player might not notice or care about.
Build (Auto-Incremented)
The build number represents any change made to a mod. If you’re using version control, it can be useful to set this to the same number as the one in your version control tool, so you can track which changes are present in each version.
ⓘ This field is auto-incremented to ensure that each mod published has a unique version that is higher than the previous version. It’s used when checking if a player has mods that can be updated, or when checking if players can join each other in multiplayer.
Conflicts
When making mods, you can expect that, eventually, there will be two mods that cannot function together. The most common reason for this is the two mods overriding the same data and the Toolkit not having a way of merging them together.
In these cases, the Toolkit lets you mark conflicting mods, which will allow the game to automatically unload the mod when it detects the conflict.
In the image below, if the currently loaded mod (MyMod) and MySpell are enabled together, MyMod will be disabled when the game starts because it has MySpell marked as a conflict.
You can access mod conflict settings in Project > Project Settings > Conflicts.
Using conflicts lets you protect players from being in an invalid state or playing with missing data. It also protects you as the mod author from feedback about something you have no power to fix.
You can see more on defining and managing conflicts in Getting Started: Publishing a Mod.
