OpenMod is the newer of Unturned's two plugin frameworks. It installs as a module beside the game, keeps its files in an OpenMod folder inside your server instance, installs plugins as NuGet packages with openmod install <PackageId>, and controls who can run what through two YAML files: openmod.roles.yaml and openmod.users.yaml. It does not replace RocketMod. It is designed to run alongside it, can load Rocket plugins through a compatibility layer, and can share Rocket's permission data. The practical rule for choosing: most existing Unturned plugins are published for RocketMod, so start there, and add OpenMod when a plugin you want is only published for it or you are writing your own.
This guide covers how the two frameworks differ, installing OpenMod on a server that already has Rocket, installing plugins, the permission system in detail, how the Rocket bridge works, and the faults you will meet. The Rocket side is covered in Unturned Commands.dat and RocketMod plugins.
OpenMod and RocketMod compared#
| RocketMod (LDM) | OpenMod | |
|---|---|---|
| Where it comes from | Ships with the server in Extras, maintained alongside the game | Separate project, installed from its releases |
| Plugin format | DLLs in Rocket/Plugins/ | NuGet packages, or DLLs in OpenMod/plugins/ |
| Configuration | XML | YAML |
| Permissions | Groups in Permissions.config.xml | Roles and users in YAML files |
| Plugin catalogue | Large, years of plugins | Smaller |
| Design | Simple, synchronous | Modern .NET: dependency injection, async, shared services |
RocketMod's history matters for this comparison: the original project was archived, and the version you get today is Legally Distinct Missile, maintained by Smartly Dressed Games and bundled with the dedicated server. It is stable and almost every plugin targets it.
OpenMod was written by one of Rocket's original maintainers with modern .NET practice: plugins are packages with declared dependencies, services such as economy or permissions are shared through interfaces instead of each plugin rolling its own, and configuration is YAML. For a plugin author, that is a nicer platform. For a server owner, what matters is that a plugin you want exists for it, and that its dependencies resolve.
Running both is normal. A typical server uses Rocket for the large catalogue of established plugins and OpenMod for a few that are only published there.
Installing OpenMod#
On RE:NODE, Unturned servers ship with RocketMod already in the Modules folder, so you are always installing OpenMod beside Rocket rather than instead of it. There are two routes.
The installer plugin
The easiest is a small Rocket plugin that installs OpenMod for you.
- Stop the server and take a backup of the instance folder.
- Download the OpenMod installer plugin for RocketMod from the OpenMod project's releases, and put the DLL in
Servers/<ServerID>/Rocket/Plugins/. - Start the server and wait for Rocket to load the installer.
- In the console, run
openmod installand follow the output. - Restart when it tells you to.
Manual install
- Stop the server and back up.
- Download the Unturned module from the OpenMod project's releases.
- Extract it so that its module folder sits directly inside the server's
Modulesdirectory, next toRocket.Unturned. - Start the server.
U3DS/ Modules/ Rocket.Unturned/ OpenMod.Unturned/ Servers/ MyServer/ Rocket/ OpenMod/The first start after installing is slow. OpenMod downloads its own components as NuGet packages, which needs outbound internet from the server and takes a while on the first run. Watch the console rather than the clock, and run modules once it settles to confirm both modules are loaded.
What the OpenMod folder contains#
After the first start, OpenMod creates its working folder in the instance:
Servers/MyServer/OpenMod/ openmod.yaml core settings openmod.unturned.yaml Unturned-specific settings, including the Rocket bridge openmod.roles.yaml roles and their permissions openmod.users.yaml players, their roles and personal permissions logging.yaml log levels and outputs packages/ NuGet packages, including installed plugins plugins/ plugin DLLs added by hand, and each plugin's config logs/ OpenMod's own logsThe exact set of files grows a little with each release. Two habits keep it manageable: edit only with the server stopped or reload afterwards, and keep this folder in your backups - it holds every permission you have granted.
Installing plugins#
OpenMod plugins are normally published as NuGet packages, and the console installs them by package ID:
openmod install <PackageId>openmod install <PackageId> <version>openmod remove <PackageId>help openmodThe package ID is on the plugin's page. Installing pulls the package and its dependencies into packages/, and most plugins need a restart to load. help openmod lists the sub-commands your version supports, which is worth checking because they have changed between releases.
A plugin distributed as a plain DLL goes into OpenMod/plugins/ instead, with any libraries it needs.
On first load, a plugin typically creates its own folder of files - a config.yaml for settings and a translations.yaml for messages. The usual routine:
- Install the plugin and restart.
- Read the console. Confirm the plugin loaded without errors.
- Stop the server, edit the plugin's generated config, start again.
- Grant its permissions to a role (next section).
- Test as a normal player, not as an admin.
That fourth step is where most "the plugin does not work" reports end, exactly as with Rocket.
Roles, users and permissions#
OpenMod permissions are strings in the form <ComponentId>:<permission>. The component is the plugin or framework that owns the permission, so OpenMod.Core:commands.help is the core framework's permission to run help. A plugin's page should list its permissions; if it does not, its commands usually follow the pattern <PluginId>:commands.<command>.
Roles live in openmod.roles.yaml:
roles:- id: default displayName: Default priority: 0 isAutoAssigned: true parents: [] permissions: - OpenMod.Core:commands.help data: {}- id: vip displayName: VIP priority: 10 isAutoAssigned: false parents: - default permissions: - Example.Kits:commands.kit - Example.Kits:kits.vip data: {}| Field | What it does |
|---|---|
id | The role's name, used everywhere else |
isAutoAssigned | Everyone gets this role without being listed |
parents | Roles this one inherits from |
priority | Decides which role wins when two disagree |
permissions | Permission strings granted by this role |
The structure your server generated is the authority for field names; follow it rather than this example if they differ.
Three features do most of the work:
- Inheritance.
viplistsdefaultas a parent, so a VIP has everything a default player has plus their own permissions. - Wildcards.
Example.Kits:kits.*grants every kit permission the plugin defines. - Negation. A permission prefixed with
!explicitly denies it, which lets a role inherit a wildcard and then remove one item from it.
Individual players are in openmod.users.yaml, keyed by their Steam ID, with the roles they hold and any personal permissions. You can edit it by hand with the server stopped, but the console commands are safer while it is running, because they write the file and reload in one step. OpenMod provides permission and role commands for adding and removing permissions and roles; run help permission and help role for the exact syntax your version expects.
The principle is the same as for panel accounts: give each role only what it needs. Moderators need kick and ban, not item spawning. Subusers and least privilege makes the general argument.
Running OpenMod alongside Rocket#
The two frameworks can cooperate in three ways, configured in openmod.unturned.yaml.
Loading Rocket plugins. OpenMod can host Rocket plugins through its compatibility layer, so a server could in principle run everything through OpenMod. In practice most servers leave Rocket plugins under Rocket, because that is where they are tested.
Shared permissions. The Rocket bridge can make OpenMod read Rocket's Permissions.config.xml, or keep the two systems separate. If you already have a well-built Rocket permissions file, letting OpenMod use it saves maintaining two sets of groups. If you are starting fresh, OpenMod's YAML roles are easier to read.
Shared economy. Plugins that charge or pay players need one balance per player, not one per framework. The bridge can route economy calls to a single system so a shop plugin under one framework and a jobs plugin under the other see the same money.
The setting names and options have changed between releases, so read the comments in your generated openmod.unturned.yaml before changing anything. Decide one thing early and write it down: which framework owns permissions on your server. Two systems each believing they are in charge is how a player ends up with a command in one and not the other.
A worked example: adding one OpenMod plugin to a Rocket server#
Suppose a server has run on Rocket for a year, with a tidy Permissions.config.xml holding default, vip and moderator groups, and the owners want one plugin that is only published for OpenMod. This is the order that avoids an evening of confusion.
First, take a backup of the whole instance folder and lock it, so there is a known-good point to go back to. Install OpenMod with the installer plugin and let the first start finish, however long it takes. Run modules and confirm both frameworks are listed before touching anything else.
Second, decide who owns permissions. With an established Rocket setup, the sensible choice is to let the bridge in openmod.unturned.yaml point OpenMod at Rocket's permission data, so the existing groups keep working and nobody maintains two lists. Read the comments in that file, make the change, and restart.
Third, install the plugin with openmod install and restart again. Read the console for the plugin's load line and any dependency errors. Stop the server, open the plugin's generated config, set it up, and start.
Fourth, grant the plugin's permission. With Rocket owning permissions, that means adding the permission to the right group in Permissions.config.xml, in the form the bridge expects - the comments in its config say how - and reloading with /p reload. With OpenMod owning them, it means adding it to a role in openmod.roles.yaml. This is the step that is easiest to put in the wrong file, which is why the decision in step two matters.
Finally, test with an ordinary player account in each group. Admins bypass enough checks that testing as one proves very little. If a VIP can use the command and a default player cannot, the setup is right.
Write down what you did - which framework owns permissions, which plugins live where - somewhere your other admins will find it. Six months later, someone will add a plugin and wonder why its command does nothing, and the note will save them an hour.
Security and choosing plugins#
OpenMod plugins are code that runs with full access to your server: player data, the save, and anything the server process can reach. NuGet packaging makes them easy to install, and that makes it easy to install something you have not looked at.
- Prefer plugins with public source. OpenMod's ecosystem is largely open source; read what a plugin does before trusting it with your server.
- Pin versions.
openmod install <PackageId> <version>installs a specific version, so a later update cannot change behaviour without you choosing it. - Remove what you stopped using. An unused plugin is still running code.
- Back up before installing. Plugins that store data can write to the save or to their own files, and there is no undo.
There is no whitelist of permitted plugins on RE:NODE; what you install is what runs, which is the right default for a server you own and a reason to be selective. Keeping a modded server clean covers the wider habits, and backups that actually restore covers testing that your backups work before you need one.
Troubleshooting#
OpenMod never finishes its first start. It is downloading packages. If it fails outright, the console shows a NuGet error, usually a network failure or a package that does not exist for this version.
`modules` does not list OpenMod. The module folder is nested too deep, or was extracted into the instance folder instead of the server's Modules directory.
A plugin installed but its commands do nothing. Permissions. Add the plugin's permission to a role, reload or restart, and test as a non-admin.
A plugin fails to load with a missing dependency. Install the dependency package named in the error, or install a plugin version built for your OpenMod version.
Everything broke after an Unturned update. OpenMod's module needs a release built for the new game version. Check the project's releases; restore the backup if you need the server up meanwhile.
Permissions work in Rocket but not OpenMod, or the reverse. The bridge in openmod.unturned.yaml decides which system is used. Pick one and make the other follow it.
Two plugins charge players from different balances. The economy is not shared. Configure the bridge so both frameworks use one economy.
FAQ#
Should I use OpenMod or RocketMod?
Start with RocketMod, which ships with the server and has the larger plugin catalogue. Add OpenMod when a plugin you want is only published for it, or when you are writing your own plugins and want its modern design.
Can OpenMod and RocketMod run at the same time?
Yes. OpenMod is designed to sit beside Rocket, and its Unturned module includes a bridge for permissions and economy. Most servers that use OpenMod also run Rocket.
Where are OpenMod permissions stored?
In OpenMod/openmod.roles.yaml for roles and OpenMod/openmod.users.yaml for individual players, inside the server instance folder. Back that folder up with the save.
How do I install an OpenMod plugin?
Run openmod install <PackageId> in the server console and restart. Plugins distributed as DLLs go into OpenMod/plugins/ instead. Then grant the plugin's permissions to a role.
Does OpenMod need internet access from the server?
Yes, for installing. Packages and OpenMod's own components come from NuGet. Once installed, a server runs from the downloaded packages.
Do players need to install anything for OpenMod plugins?
No. Plugins run on the server only. Players need nothing beyond any workshop content the server uses, which is handled separately - see Unturned workshop maps and mods.
Comments
Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.