How to install Community Online Tools on a DayZ server
To install Community Online Tools (COT), load the original package after CF on the server and clients, then configure the owner’s identity in the active profiles directory. The first successful join establishes that the packages match. Administrator access requires a separate permissions check.
Use Community-Online-Tools, Workshop item 1564026768, published by the Jacob Mango and Arkensor team. This guide covers Steam PC servers. COT cannot be installed on Xbox or PlayStation community servers.
Prepare a test instance and permissions backup
Section titled “Prepare a test instance and permissions backup”Start with a server that accepts a normal client join. Record its game branch, active mission, launch parameters and mod versions. Back up the mission, saved world and profiles while the service is stopped. Profiles contain the permissions and logs covered below.
If CF is new to this world, its author requires a wipe before installation. Start the rehearsal with separate, fresh persistence. Plan the live change with your community and retain a recovery set before adding the framework to an existing save.
Choose the server owner who will receive the initial admin role. Get that person’s Steam64 ID, kept as a string. A display name, server join password, RCON password or VPP permission does not identify a COT administrator.
Use one administration system for the first test. If the server already uses VPP, record its bindings and permissions before deciding whether to replace it or test coexistence. Overlapping shortcuts can trigger the wrong tool.
Install CF and COT
Section titled “Install CF and COT”In VXPanel:
- Stop the test service and open Mods.
- Install CF, item
1559212036, then Community-Online-Tools, item1564026768. Follow each Steam link to confirm the publisher and current requirements. - Keep both in client-required scope, with CF before COT. COT has a client interface; loading it only through a server-side binding omits that interface.
- Wait for the installations to finish. Check the supplied keys in the server’s central
keys/directory. The locally inspected packages useJacob_Mango_V3.bikey; use the current release’s supplied file rather than a key from a reupload. - Start the service and read the new startup logs. Join with the same CF and COT versions, then disconnect and stop the service before editing permissions.
For a self-managed host, use the manual mod and signing-key procedure. If your installed folders are named @CF and @Community-Online-Tools, retain the rest of the launch command and include:
"-mod=@CF;@Community-Online-Tools"Append other client-required packages to that same semicolon-separated argument. Keep signature verification enabled. Fix package mismatches before working on permissions.
Find the active permissions directory
Section titled “Find the active permissions directory”Resolve the directory selected by the running service’s -profiles= parameter or corresponding panel setting. The inspected COT package uses these locations:
<profiles>/PermissionsFramework/Players/<profiles>/PermissionsFramework/Roles/<profiles>/PermissionsFramework/Permissions/<profiles>/CommunityOnlineTools/Logs/Players/ contains identity role assignments as JSON. Roles/ contains the role definitions as text files, including admin.txt in the inspected release. Permissions/ can contain individual permission overrides. Keep all three when backing up or transferring staff access.
If these folders do not appear after a completed startup and player join, check the actual profiles path, mod compilation errors and the service’s write access. Creating a second folder next to an inactive serverDZ.cfg will not change the running service.
Give the owner the initial admin role
Section titled “Give the owner the initial admin role”The author’s installation example assigns the role named admin. In the inspected release, the server creates that role from its registered permissions. It grants broad administration capabilities, so use it for the owner who will configure staff roles.
- With the service stopped, back up
PermissionsFramework/. - Create or reconcile the owner’s file in
Players/, namedYOUR_STEAM64_ID.json. ReplaceYOUR_STEAM64_IDwith the owner’s actual ID. Enable filename extensions so the file does not become.json.txt. - Use this JSON role assignment, preserving any other intentional role assignments for that identity:
{ "Roles": [ "admin" ]}- Validate the JSON, start the service and join as that owner.
- Check that COT opens and that the owner can view its player and role controls.
The inspected COT fallback permissions loader gives a manually supplied Steam64 file priority, then migrates it to the player’s sanitized DayZ GUID filename. That loader is compiled when CF_MODULE_PERMISSIONS is absent. The Steam64 file disappearing after a successful join can be expected migration behavior with that loader. Check the generated player record and its Roles array before recreating another file. A release using CF’s permissions module needs its own generated-record check.
A Steam64 ID and a DayZ GUID are different identifiers. Use the author’s supported Steam64 filename for initial setup; do not calculate a filename from a nickname. For an existing generated GUID record, reconcile the correct player’s record while stopped. Avoid leaving several competing assignments for the same person.
The paths and schema above were checked against the installed original package. If an updated release changes them, keep the generated schema and follow that release’s instructions.
Open COT and assign staff roles
Section titled “Open COT and assign staff roles”The author lists these default shortcuts. Check the COT section of the client’s controls if your bindings differ:
| Key | Author-listed action |
|---|---|
End |
Toggle COT keybindings. |
Y |
Show the toolbar. |
Insert |
Toggle free camera. |
H |
Teleport to the position under the crosshair. |
Enable COT, open its toolbar and use the player/role controls to grant the capabilities each staff member needs. Save a custom role for moderators rather than giving every moderator the owner’s admin role. Check the available permission tree in your release and include the view permission needed to open the tool.
The inspected package recreates its built-in admin role during mission loading. Keep limited staff permissions in a separate custom role; editing admin.txt into a restricted role can be undone by that startup behavior.
After saving a role and assigning it to a player, reconnect that player and verify the assignment. Individual permission overrides can affect the result. Do not edit the everyone role to solve one administrator’s access problem, because ordinary players use it too.
Verify staff access and ordinary-player restrictions
Section titled “Verify staff access and ordinary-player restrictions”Use a test area away from community bases. Record the results before moving COT to the live instance:
- Join as the owner. Open the tool, inspect the player list and perform one reversible action, such as teleporting your own test character to a known clear location.
- Join with a limited staff account. Confirm its required action works and that excluded actions are denied.
- Join with a normal account that has no staff role. Confirm it cannot use administration features.
- Read the new COT log under
CommunityOnlineTools/Logs/and reconcile the action with the actor you tested. - Stop and start the same test world. Reconnect each account and repeat the permission checks.
An offline editor session can grant tools without multiplayer permissions. It does not replace these dedicated-server checks. An item spawned through COT also does not establish that its classname is registered in the loot economy.
Fix COT installation and permission failures
Section titled “Fix COT installation and permission failures”| Symptom | Check |
|---|---|
| COT controls absent from the client | Matching original package, client-required scope and completed game restart after updating mods. |
| Shortcut does nothing | COT enabled, current bindings, overlapping admin tools and the player’s view permission. |
| JSON saves but no admin access | Active profiles directory, actual Steam64 ID, case-sensitive Roles field, valid array and existing admin role. |
| Steam64 JSON disappears | Check the generated GUID record; the inspected loader migrates the supplied assignment on join. |
| Role assignment is lost | Stop before file edits, reconnect after changes, inspect the saved player record and any individual override. |
| Restricted admin role becomes broad again | Use a custom role; the inspected code regenerates the built-in admin role. |
| Everyone can use tools | Review everyone, inherited role permissions and individual grants, then repeat the normal-account check. |
Update or remove COT
Section titled “Update or remove COT”Back up all permission directories and logs before a mod update. Update the server and clients together, read the author’s changes, then repeat the three-account checks. Keep a record of who should retain each role.
To undo the rehearsal, stop the service and restore the previous launch list and compatible profiles from the recovery set. Follow mod removal before removing CF, because other mods may require it. Do not delete the world to repair a malformed player JSON file.
Related documentation: Author-linked role assignment, Author’s source repository.
Continue with VPP setup if that is your chosen admin system, or return to the DayZ server tutorials.