- Alex -

GGU OpenMod MySQL Permissions Setup Guide Roles, Inheritance, Grants, Denials, Assignments & Cache Management GGU Public Technical Knowledge Base Applies to GGU.OpenMod.MySqlPermissions v0.7.0 • Guide updated October 4, 2026 Public Knowledge Base This guide documents GGU's internal GGU.OpenMod.MySqlPermissions permission system. The plugin itself is private and is not publicly distributed, but the technical information in this guide is public so other server operators can understand the permission-management concepts, command structure, and architecture GGU uses. Introduction GGU.OpenMod.MySqlPermissions is a private, in-house GGU OpenMod plugin that stores roles, inheritance, actor assignments, permission grants and denials, and role/actor metadata in MySQL. This makes permission data persistent outside individual server configuration files and allows the same permission structure to be shared or synchronized across GGU servers when they use the same configured scope. Availability The plugin is not a public download and is not offered as a supported third-party package. This documentation is public for transparency, technical reference, and knowledge-sharing purposes. The plugin is designed to be administered through its own command interface rather than by manually editing permission YAML for routine role and player changes. Command Aliases /gguperms is the primary command. The aliases /gp and /ggup can be used in its place. Prerequisites & Administrative Access OpenMod is installed and running. GGU.OpenMod.MySqlPermissions is installed on an authorized GGU-managed OpenMod server and connected to its MySQL database. The database schema has initialized successfully. You know the Steam64 ID of any player receiving a direct role or permission assignment. You have an authorized administrative path to execute the permission-management commands. Administrative Permission Node GGU.OpenMod.MySqlPermissions:commands.gguperms Critical Access Warning Do not remove your last working administrative path until a replacement role or account has been tested. Permission mistakes can lock administrators out of in-game management. Understanding the Permission Model Role: a named collection of permissions and metadata. Parent role: a role inherited by another role. Grant: explicitly allows a permission node. Deny: explicitly denies a permission node. Actor: the player or other OpenMod actor receiving direct permissions or roles. Priority: an integer stored with a role for ordering/resolution. Auto role: a role configured for automatic assignment. Expiration: an optional end time on a player-role assignment; permanent assignments use no expiration. Role data: metadata such as prefixes, suffixes, colors, cooldown data, or other JSON-backed values consumed by compatible plugins. Recommended Design Build permissions from small reusable roles and inheritance. Avoid granting * broadly. Keep player perks and staff authority in separate branches unless staff are intentionally supposed to inherit the player-perk role. Step 1: Verify the Plugin & Cache Before creating roles, confirm the permission provider is responding. /gguperms cache status In the v0.7.0 configuration used by this guide, caching can be enabled with a fallback TTL of 300 seconds. External assignment and permission changes are also synchronized so affected cache entries are invalidated without waiting for the full fallback TTL. Known v0.7.0 Cache/Scope Settings scope: name: global cache: enabled: true ttl_seconds: 300 Step 2: Create the Base Roles The following example creates a clean role hierarchy. Names and permission nodes are examples; adapt them to the plugins and responsibilities on the GGU server being configured. Create the Default Role /gguperms role create default "Default" /gguperms role priority default 0 /gguperms role auto default true Create a Player-Perk Role /gguperms role create vip "VIP" /gguperms role priority vip 10 /gguperms role parent add vip default Create a Staff Hierarchy /gguperms role create helper "Helper" /gguperms role priority helper 20 /gguperms role parent add helper default /gguperms role create moderator "Moderator" /gguperms role priority moderator 50 /gguperms role parent add moderator helper /gguperms role create admin "Administrator" /gguperms role priority admin 80 /gguperms role parent add admin moderator Inheritance Principle A child role should contain only the additional access needed beyond its parent. This keeps the permission tree readable and prevents the same nodes from being copied into every rank. Step 3: Grant Permissions to Roles Add only the permission nodes each role requires. /gguperms role permission add default OpenMod.Core.Commands.help /gguperms role permission add moderator RocketMod.Essentials.kick /gguperms role permission add moderator RocketMod.Essentials.teleport /gguperms role permission add admin RocketMod.Essentials.ban /gguperms role permission add admin RocketMod.Essentials.unban Explicit Denials /gguperms role permission deny moderator RocketMod.Essentials.shutdown To remove an explicit role permission entry, use: /gguperms role permission remove moderator RocketMod.Essentials.shutdown Use Denials Carefully The plugin supports grants, explicit denials, inheritance, and wildcard-style permission structures. Keep deny rules limited and test inherited combinations before rolling them out broadly. Step 4: Assign Players to Roles Permanent player assignments should use the player's Steam64 ID rather than a display name. /gguperms player role add 76561198090988183 moderator Remove the role with: /gguperms player role remove 76561198090988183 moderator Step 5: Temporary / Expiring Roles Role assignments can carry an expiration time. This is useful for temporary staff access, timed VIP access, event roles, testing access, or contractor/partner permissions. /gguperms player role expiry set 76561198090988183 vip 2026-10-31T23:59:59Z Inspect or remove the expiration with: /gguperms player role expiry show 76561198090988183 vip /gguperms player role expiry clear 76561198090988183 vip Expiration Format Use an explicit UTC timestamp such as 2026-10-31T23:59:59Z. Permanent assignments are stored without an expiration. Step 6: Direct Player Permissions Direct player permissions are best used for narrow exceptions. If several players need the same access, create a role instead. /gguperms player permission add 76561198090988183 Example.Plugin:commands.example /gguperms player permission deny 76561198090988183 Example.Plugin:commands.dangerous /gguperms player permission remove 76561198090988183 Example.Plugin:commands.example Step 7: Inspect Roles Before Changing Them /gguperms role list /gguperms role show moderator Use role show before modifying an existing production role so you understand its current parents, priority, automatic-assignment state, and permission entries. Step 8: Manage Role Inheritance Add or remove parent relationships with: /gguperms role parent add moderator helper /gguperms role parent remove moderator helper Avoid Inheritance Loops Keep the role tree one-directional. A parent should never inherit from one of its own children. Step 9: Role Metadata & Plugin Data The permission store can associate data with roles. Common uses include prefixes, suffixes, colors, cooldown definitions, or arbitrary JSON consumed by another plugin. Inspect Role Data /gguperms role data list default /gguperms role data show default cooldowns Set Role Data /gguperms role data set default cooldowns [{"command":"Rocket.pvp","cooldown":"1 minute 30 seconds"}] Remove Role Data /gguperms role data remove default cooldowns Metadata Is Consumer-Dependent Storing a key does not automatically make it visible in chat or change plugin behavior. Another plugin must read and use that role data. Step 10: Cache & Synchronization v0.7.0 caches effective roles, inherited roles, grants, and denials. Changes made through the permission system invalidate the affected cache. The synchronization path also detects externally changed assignments and direct permissions so multiple servers using the same permission data do not need to wait for the entire cache TTL. Check Cache State /gguperms cache status Force a Cache Clear /gguperms cache clear Use a manual cache clear when troubleshooting stale access, after emergency database work, or when verifying a synchronization issue. Recommended Role Layout default ├── vip default └── helper └── moderator └── admin This model keeps optional player perks separate from staff authority. If your organization intentionally gives staff the same perks as VIPs, add the appropriate parent relationship or grant those permissions through a shared parent role rather than duplicating nodes. Quick Start Example A minimal working setup could look like this: /gguperms role create default "Default" /gguperms role priority default 0 /gguperms role auto default true /gguperms role permission add default OpenMod.Core.Commands.help /gguperms role create moderator "Moderator" /gguperms role priority moderator 50 /gguperms role parent add moderator default /gguperms role permission add moderator RocketMod.Essentials.kick /gguperms role create admin "Administrator" /gguperms role priority admin 80 /gguperms role parent add admin moderator /gguperms role permission add admin GGU.OpenMod.MySqlPermissions:commands.gguperms /gguperms player role add 76561198090988183 admin /gguperms role show admin /gguperms cache status Do Not Copy Example IDs into Production Replace all example Steam64 IDs, role names, and plugin permission nodes with the values appropriate for the GGU server or environment being configured. Role Administration Command Reference Player Administration Command Reference Cache Command Reference Database Reference The plugin's MySQL schema stores the permission model in separate tables. With the standard ggu_openmod_ prefix, the core data includes roles, role-parent relationships, actor-role assignments, permission entries, role data, and actor data. ggu_openmod_roles ggu_openmod_role_parents ggu_openmod_actor_roles ggu_openmod_permissions ggu_openmod_role_data ggu_openmod_actor_data Direct SQL Changes The database is the authoritative backing store, but routine GGU administration should use the plugin commands. Direct SQL is appropriate only when you understand the schema and synchronization implications. Back up production permission data before bulk changes. Troubleshooting A Player Did Not Receive a Role Verify the Steam64 ID. Confirm the role exists with /gguperms role show <role>. Check whether the assignment has expired. Confirm all servers are using the intended permission scope. Check the cache state and clear it if troubleshooting stale data. A Permission Still Does Not Work Verify the permission node exposed by the target plugin. Check the role's parent chain. Look for an explicit deny on the role or player. Confirm the target plugin is loaded. Use a narrow direct grant temporarily to isolate whether the problem is the role hierarchy or the permission node itself. A Database Change Is Not Visible Yet Allow the external synchronization poll to run. Use /gguperms cache status to inspect cache state. Use /gguperms cache clear when immediate troubleshooting is required. Verify that the servers are pointing at the same intended database and scope. Permission Administration Is Locked Out Do not continue deleting or changing roles blindly. Use an already-authorized console or administrative recovery path. Restore the required management grant: GGU.OpenMod.MySqlPermissions:commands.gguperms. Clear the permission cache after emergency repair if needed. Security & Best Practices Follow least privilege. Grant only what each role needs. Prefer role-based access over large numbers of direct player permissions. Use Steam64 IDs for permanent assignments. Use expiration timestamps for temporary access. Keep a clear, documented inheritance tree. Do not use * unless the account genuinely requires unrestricted access. Audit old staff, testing, partner, and temporary assignments regularly. Back up the permission database before bulk migrations or direct SQL work. Test high-risk permission changes with a non-owner account before applying them broadly. GGU Operational Note On GGU-managed servers, role and permission changes should follow the applicable access-control and change-management process. The MySQL permission store makes cross-server access easier to manage, but it also makes an incorrect global-scope change capable of affecting more than one server. Verification Checklist The expected roles appear in /gguperms role list. Each role has the intended priority and automatic-assignment setting. Parent relationships form the intended hierarchy. Role permission grants and denials are correct. The test account receives the intended role. Inherited commands work. Denied commands remain blocked. Temporary-role expiration behaves as expected. Cache/synchronization behavior is healthy. No unnecessary wildcard permissions remain. Conclusion GGU.OpenMod.MySqlPermissions provides GGU with a centralized permission model for its OpenMod servers without requiring routine role management to be duplicated across local YAML files. A clean role hierarchy, narrow permission grants, stable Steam64 assignments, expirations for temporary access, and disciplined cache/database management provide a permission system that remains understandable as the server network grows. Golden Gamers United Bringing back the golden days, one server at a time.

OpenMod Common Errors & FAQ Fast Answers with Diagnostic Context GGU Public Technical Knowledge Base Public Knowledge Base: This article is written for both GGU administrators and the wider server-hosting community. General instructions are platform-neutral where possible; GGU-specific practices are identified separately. Applies To OpenMod server operators Prerequisites Basic console/log access What You’ll Accomplish Resolve common OpenMod administration problems and know when deeper troubleshooting is required. Permission Changes Did Not Work Check the role file/permission command, inheritance, explicit denies, and the exact permission string. The upstream docs state that `openmod.roles.yaml` changes are applied immediately. Plugin Installed but Commands Are Missing Confirm OpenMod was reloaded after installation, then inspect the plugin load logs for dependency or configuration errors. A New Config Option Is Missing OpenMod's docs warn that plugin config files are not automatically expanded when new fields are introduced. Compare against current defaults/documentation. Plugin Update Broke the Server Stop making unrelated changes, preserve the error, and evaluate rollback. Restore compatible configuration/data with the older binary if the update changed formats. Can I Grant Everything with a Wildcard? Technically broad grants may be possible depending on the permission store/plugin, but least privilege is safer and easier to review. Where Should I Ask for Help? Start with the plugin's authoritative documentation/repository and OpenMod's documentation. Provide logs, versions, the exact command/config involved, and what you already tested. Redact secrets. GGU Implementation Notes For GGU-developed plugins, the internal Gitea repository and deployment history should be checked in addition to the public KB. Public articles should never depend on access to GGU-private systems to be useful. Upstream References OpenMod Permissions OpenMod Plugins OpenMod Configuration Files OpenMod Logging Golden Gamers United — Public Technical Knowledge Base General guidance first. GGU implementation details second.

OpenMod Translations & Message Customization Editing User-Facing Text Safely GGU Public Technical Knowledge Base Public Knowledge Base: This article is written for both GGU administrators and the wider server-hosting community. General instructions are platform-neutral where possible; GGU-specific practices are identified separately. Applies To OpenMod administrators Plugin maintainers Prerequisites Access to translation YAML files What You’ll Accomplish Customize OpenMod/plugin messages while preserving formatting and upgrade compatibility. What Translation Files Are For OpenMod translation files allow framework/plugin messages to be localized or customized without hardcoding operational text into source code. Framework Translation File OpenMod/openmod.translations.yaml Plugins may provide their own translation resources. Keep placeholder/format tokens intact when editing messages. Update Caveat Important: The OpenMod documentation warns that translation files are not automatically updated when new translation keys are added. You may need to merge new keys or regenerate according to the plugin/framework instructions. Safe Editing Back up the current file. Preserve YAML indentation. Preserve formatting placeholders. Test messages that contain user-provided values or formatting. Do not put secrets into user-facing translation strings. GGU Implementation Notes GGU can use translations for community-specific wording while keeping plugin logic generic. If GGU customizes an upstream plugin's messages, document those changes so an update does not silently discard or miss new keys. Upstream References OpenMod Translation Files Golden Gamers United — Public Technical Knowledge Base General guidance first. GGU implementation details second.

Deploying Custom OpenMod Plugins Release, Validation & Rollback GGU Public Technical Knowledge Base Public Knowledge Base: This article is written for both GGU administrators and the wider server-hosting community. General instructions are platform-neutral where possible; GGU-specific practices are identified separately. Applies To Plugin developers Production server operators Prerequisites A built plugin artifact Access to the target server A rollback copy What You’ll Accomplish Move a custom OpenMod plugin from development into production in a repeatable, auditable way. Deployment Is More Than Copying a DLL A production deployment should identify the artifact, configuration impact, dependencies, data changes, validation steps, and rollback point. Recommended Release Contents Versioned plugin artifact. Release notes/changelog. Configuration changes. New permissions/commands. Dependencies. Migration notes. Rollback compatibility. Deployment Checklist Confirm the target server/environment. Back up current plugin/config/data as appropriate. Deploy the approved artifact. Apply required config changes. Reload/restart as required. Watch logs from plugin initialization through first use. Test representative commands and permission tiers. Record the deployed version. Avoid Building directly on production and leaving no artifact history. Copying a DLL from a developer desktop with no version record. Deploying configuration containing secrets to a public repository. Changing code, configuration, and database schema simultaneously without a recovery plan. GGU Implementation Notes At GGU, Gitea is the source-control system. In-house plugin deployments should be traceable to a Gitea commit/tag or CI artifact. Pelican is the game-server control plane, but the public deployment principles in this guide also apply to other hosting panels. Upstream References OpenMod Plugins OpenMod Publishing to NuGet Golden Gamers United — Public Technical Knowledge Base General guidance first. GGU implementation details second.

Developing OpenMod Plugins From Project Template to Testable Plugin GGU Public Technical Knowledge Base Public Knowledge Base: This article is written for both GGU administrators and the wider server-hosting community. General instructions are platform-neutral where possible; GGU-specific practices are identified separately. Applies To C# developers OpenMod plugin maintainers Prerequisites .NET SDK suitable for the target project OpenMod development dependencies A test server What You’ll Accomplish Create a maintainable OpenMod plugin using the framework's command, configuration, permission, logging, and lifecycle concepts. Start with the Official Template OpenMod provides project templates for universal and Unturned plugins. A plugin ID should be unique and is commonly aligned with the package ID. dotnet new openmod-universal-plugin --PluginId <PluginId> dotnet new openmod-unturned-plugin --PluginId <PluginId> Plugin Structure Plugin entry class/lifecycle. Commands. Configuration. Permissions. Services/dependency injection. Logging. Translations/resources where applicable. Commands Use OpenMod command base classes and command metadata for names, aliases, description, and syntax. Restrict actor types through the framework's actor mechanism rather than ad-hoc type checks. Configuration OpenMod's developer docs use `Microsoft.Extensions.Configuration`. Keep configuration focused on settings operators are likely to change, and do not hardcode operational values that vary between servers. Permissions Register custom permissions before checking them. Command permissions are better handled through the command system rather than manually recreating command-use checks. Logging Inject `ILogger` and log meaningful state transitions and errors. Avoid logging secrets. Build & Test Build in Release mode for deployment. Test load/unload/reload. Test a fresh configuration. Test permission denied and allowed paths. Test failure cases, not only the happy path. Document any data migration. GGU Implementation Notes GGU in-house OpenMod plugins should live in Gitea, be reproducibly built, and have deployment/version information tied to the repository revision. Production binaries should come from the approved build artifact whenever practical. Upstream References OpenMod Plugin Development Getting Started OpenMod Commands OpenMod Developer Configuration OpenMod Developer Permissions Golden Gamers United — Public Technical Knowledge Base General guidance first. GGU implementation details second.

Updating & Rolling Back OpenMod Plugins Production-Safe Upgrade Workflow GGU Public Technical Knowledge Base Public Knowledge Base: This article is written for both GGU administrators and the wider server-hosting community. General instructions are platform-neutral where possible; GGU-specific practices are identified separately. Applies To OpenMod administrators Prerequisites A currently working plugin installation Access to backup/restore mechanisms What You’ll Accomplish Upgrade OpenMod plugins with a known rollback path and validate the full runtime state. Why Rollback Planning Matters Plugin updates can change binaries, configuration, dependencies, database schemas, or persisted data. A safe update has a known recovery point before the first production change is made. Before Updating Record the currently deployed plugin version. Back up plugin configuration. Back up plugin-owned data/database where applicable. Read release notes. Confirm dependency changes. Know where the previous binary/package can be restored from. Update Install/replace the new version. Reload OpenMod as required. Watch the complete load sequence. Verify the plugin's main commands/features. Verify permissions. Verify persisted data. Keep the old version until the new one is accepted. Rollback Decision Rollback when the update creates a production-impacting failure that cannot be safely corrected in the maintenance window. Do not continue stacking speculative changes merely because an update is 'supposed' to work. Rollback Limits Important: If an update performed an irreversible or forward-only database/data migration, restoring only the previous DLL may make the situation worse. Restore compatible data/configuration as well. GGU Implementation Notes GGU should prefer versioned release artifacts from Gitea/CI so the exact prior build is recoverable. Record the deployed version and rollback point with material production changes. Upstream References OpenMod Plugins Golden Gamers United — Public Technical Knowledge Base General guidance first. GGU implementation details second.

Troubleshooting OpenMod Plugin Load Failures A Repeatable Diagnostic Workflow GGU Public Technical Knowledge Base Public Knowledge Base: This article is written for both GGU administrators and the wider server-hosting community. General instructions are platform-neutral where possible; GGU-specific practices are identified separately. Applies To OpenMod server operators Prerequisites Console/log access Plugin package/version information What You’ll Accomplish Determine why an OpenMod plugin did not load and recover without random changes. Symptoms of a Load Failure Plugin commands do not exist. Configuration never appears. Console reports package/dependency errors. Plugin starts and immediately fails. Reload produces an exception. Another plugin reports a missing service/library. Diagnostic Order Confirm the plugin file/package is actually installed. Confirm the plugin targets the correct game/platform. Confirm dependencies are installed. Check the first load exception. Validate YAML/configuration. Confirm the plugin version is compatible with its dependencies. Temporarily return to the last known-good version if the failure began after an update. Dependency Problems Package-based plugins may rely on other packages. A missing or incompatible dependency can prevent a plugin from loading even when the plugin DLL itself is present. Configuration Problems A plugin can fail because a required configuration value is malformed, missing, or no longer valid after an update. Compare the current config against the plugin's current defaults/release documentation. Rollback A rollback is not simply replacing the DLL. If the new version changed persisted data or configuration format, determine whether the previous version can safely read the newer data before downgrading. GGU Implementation Notes For GGU in-house plugins, compare the deployed build against the Gitea release/commit used by the server. Production should not depend on an untracked local DLL with no reproducible source revision. Upstream References OpenMod Plugins OpenMod Logging OpenMod Configuration Files Golden Gamers United — Public Technical Knowledge Base General guidance first. GGU implementation details second.

OpenMod Logging & Troubleshooting Finding the Real Error Behind Plugin Failures GGU Public Technical Knowledge Base Public Knowledge Base: This article is written for both GGU administrators and the wider server-hosting community. General instructions are platform-neutral where possible; GGU-specific practices are identified separately. Applies To OpenMod administrators Plugin developers Prerequisites Console/log access What You’ll Accomplish Use OpenMod logs systematically to isolate plugin, configuration, dependency, and runtime failures. Logging Architecture OpenMod uses Serilog as its default logging implementation. Administrator-level logging is configured through `logging.yaml` in the OpenMod folder. What to Capture When Troubleshooting The first error, not only the last cascading error. Plugin ID/name and version. OpenMod/game-server version information. Stack trace when available. Configuration parsing errors. Dependency/package errors. The exact action that triggered the problem. Increasing Logging Usefully More logging is useful only when it helps isolate the failure. Avoid flooding production logs indefinitely. Reproduce the issue, capture the relevant window, then return logging to the normal level if you temporarily increased verbosity. Additional Log Sinks OpenMod's documentation notes that Serilog sinks can be installed as packages and configured in `logging.yaml`. This makes it possible to send logs to additional destinations, but credentials and connection strings must be protected. Reading a Plugin Failure Locate the plugin load/start event. Find the first exception/error associated with that plugin. Check for missing dependencies. Check YAML/config parsing. Check permission/service registration errors. Confirm the plugin targets the correct runtime/game. Reproduce after making one corrective change. GGU Implementation Notes GGU production troubleshooting should preserve the relevant console/log excerpt in the incident or deployment record. Do not publish database strings, tokens, private IP details that are intentionally restricted, or member data in public KB examples. Upstream References OpenMod Logging OpenMod Developer Configuration Golden Gamers United — Public Technical Knowledge Base General guidance first. GGU implementation details second.

OpenMod Commands & Command Permissions Finding, Granting & Troubleshooting Command Access GGU Public Technical Knowledge Base Public Knowledge Base: This article is written for both GGU administrators and the wider server-hosting community. General instructions are platform-neutral where possible; GGU-specific practices are identified separately. Applies To OpenMod administrators Plugin developers Prerequisites OpenMod installed A command or plugin to inspect What You’ll Accomplish Understand how OpenMod command access is determined and troubleshoot denied commands. Command Permissions OpenMod automatically assigns permissions to commands rather than requiring plugin authors to invent a separate general-use permission check for every command. The developer documentation recommends using the command metadata and permission system consistently. Find a Command's Permission help <command> Use the command's help output and plugin documentation to determine its base permission and syntax. Child / Additional Permissions A plugin may register more specific child permissions for sensitive behavior inside a broader command. This allows a command to remain generally usable while particular operations require stronger access. Actor Restrictions Commands can be limited to appropriate actor types such as players or console. A command that manipulates an in-game player should not assume every possible command actor is a game player. Troubleshooting Permission Denied Confirm the command name and syntax. Use help to identify the permission. Confirm the user has the intended role. Check role inheritance. Look for explicit deny rules. Confirm the plugin is actually loaded. Test again after correcting the role. Avoid Granting a global wildcard merely to fix one denied command. Creating duplicate roles for individual users. Assuming the display name of a command is its permission string. Editing a plugin binary/source merely to work around a permission configuration issue. GGU Implementation Notes GGU should document command permission mappings for in-house plugins alongside the plugin's public/admin documentation. Game Team roles should be granted the smallest command set necessary for their responsibilities. Upstream References OpenMod Commands OpenMod Permissions Golden Gamers United — Public Technical Knowledge Base General guidance first. GGU implementation details second.

OpenMod Permissions & Roles Building Maintainable Access Control GGU Public Technical Knowledge Base Public Knowledge Base: This article is written for both GGU administrators and the wider server-hosting community. General instructions are platform-neutral where possible; GGU-specific practices are identified separately. Applies To OpenMod administrators Server owners Prerequisites OpenMod installed Access to roles configuration or permission commands What You’ll Accomplish Build a role hierarchy, understand inheritance, and grant permissions using least privilege. Role-Based Permissions OpenMod's administrator documentation uses roles as groups of permissions. Assigning a role to a user gives that user the role's effective permissions, and roles may inherit from parent roles. Primary Configuration OpenMod/openmod.roles.yaml OpenMod also provides `permission` and `permissionrole` commands for managing access. The upstream documentation notes that changes to `openmod.roles.yaml` are applied immediately and do not require a reload. Role Attributes Parents: other roles from which this role inherits. Permissions: actions explicitly granted/denied by the role. Display Name: human-readable role name. Auto Assigned: whether the role is automatically assigned to new users. Designing a Hierarchy Prefer a small number of reusable roles rather than copying the same permissions to many users. Put common permissions in a parent role and add stronger permissions only at higher tiers. roles: moderator: display_name: Moderator permissions: - ExamplePlugin:SomePermission staff: display_name: Staff parents: - moderator permissions: - ExamplePlugin:HigherPermission Example Only: The exact YAML schema and permission strings depend on the OpenMod version and plugins installed. Use the plugin's registered permissions/help output as the authoritative source. Least Privilege Grant only the permissions needed for the role. Avoid broad wildcards when a narrow permission is practical. Test denied behavior as well as allowed behavior. Document unusual grants. Remove obsolete role assignments when responsibilities change. GGU Implementation Notes GGU maps OpenMod roles to operational responsibilities rather than assuming every Leadership rank needs every game-server permission. Public examples may use GGU-style role names, but outside operators should adapt the hierarchy to their own structure. Upstream References OpenMod Permissions OpenMod Developer Permissions Golden Gamers United — Public Technical Knowledge Base General guidance first. GGU implementation details second.

OpenMod Plugin Configuration & YAML Editing Plugin Settings Without Breaking Production GGU Public Technical Knowledge Base Public Knowledge Base: This article is written for both GGU administrators and the wider server-hosting community. General instructions are platform-neutral where possible; GGU-specific practices are identified separately. Applies To OpenMod administrators Plugin operators Prerequisites Access to the plugin configuration Basic YAML familiarity What You’ll Accomplish Locate, edit, validate, and safely update OpenMod plugin configuration. Where Plugin Configuration Lives OpenMod uses YAML for configuration. The administrator documentation places plugin-specific configuration under the plugin's directory inside the OpenMod plugins area. OpenMod/plugins/<plugin-id>/config.yaml YAML Rules That Matter Indentation is significant; use spaces consistently. Do not mix tabs into indentation. Lists normally use `-` entries. Quote values when punctuation or YAML parsing could make intent ambiguous. Keep a backup before large edits. Validate the server after changing a critical configuration. Configuration Updates Important: OpenMod's documentation warns that configuration files are not automatically updated when a plugin adds new fields. You may need to add new keys manually or regenerate the file according to the plugin's instructions. Safe Editing Workflow Read the plugin's current release notes or config documentation. Back up the current config. Make one logical change at a time. Preserve indentation and data types. Apply/reload only as required by that plugin/framework. Review console/log output. Test the changed behavior. Regenerating a Configuration If the plugin author documents that deleting or renaming the configuration causes a fresh default to be generated, preserve the old file first. Regeneration is useful for discovering newly added keys, but blindly deleting a production config can discard important values. Secrets Do not paste production database passwords, API keys, bot tokens, or other secrets into public troubleshooting posts. If a plugin needs secrets in YAML, restrict file access appropriately and use placeholders in public examples. GGU Implementation Notes GGU should keep non-secret example configurations in Gitea when useful, but production secrets belong outside public repositories. For in-house plugins, configuration changes should be documented alongside the version that introduced them so other GGU operators can upgrade without guessing. Upstream References OpenMod Configuration Files OpenMod Developer Configuration Golden Gamers United — Public Technical Knowledge Base General guidance first. GGU implementation details second.

Installing, Updating & Removing OpenMod Plugins Public Administrator Guide GGU Public Technical Knowledge Base Public Knowledge Base: This article is written for both GGU administrators and the wider server-hosting community. General instructions are platform-neutral where possible; GGU-specific practices are identified separately. Applies To OpenMod server operators Prerequisites OpenMod is already installed Console or panel access A known plugin package/source What You’ll Accomplish Install, update, remove, reload, and verify OpenMod plugins safely. Before Installing a Plugin Identify the plugin ID/package name and authoritative download source. Check whether it targets your game/platform and OpenMod environment. Read dependency requirements and configuration notes. Back up production configuration before replacing an existing plugin. Prefer a test server for major updates or plugins that alter persistence/data. Install from NuGet OpenMod's documented package workflow installs plugins with the OpenMod command interface. openmod install <package-id> To request a specific package version: openmod install <package-id>@<version> The upstream documentation also supports pre-release installation with the appropriate pre-release option. Use pre-release builds deliberately; they may be less stable. Manual Installation For a manually distributed plugin, place the plugin DLL and any required libraries in the OpenMod plugins area according to the plugin author's package structure. Do not scatter DLLs through unrelated directories. Apply the Change The OpenMod plugin documentation states that installation, update, or removal changes require an OpenMod reload before they take effect. openmod reload Verify Watch the console during reload. Check for dependency or load errors. Confirm the plugin appears to initialize. Run a harmless plugin command or status check. Inspect the plugin's configuration directory. Check logs for warnings that may not be obvious in-game. Updating For NuGet-installed plugins, running the install command again is the documented update path. For manually installed plugins, replace the plugin binary according to the author's instructions, then reload OpenMod. Removing NuGet-installed packages can be removed through OpenMod's remove command. Manually installed plugins are removed by deleting their plugin files. Back up configuration/data first if you may need to restore the plugin. Common Mistakes Forgetting `openmod reload` after installing/updating/removing. Installing a plugin for the wrong game/platform. Updating a plugin without checking configuration changes. Deleting plugin data during an otherwise routine update. Assuming a successful download means a successful plugin load. GGU Implementation Notes On GGU production servers, treat plugin updates as production changes: preserve the current plugin/configuration, know the rollback version, watch startup/reload logs, and validate commands/permissions after deployment. In-house plugin binaries should come from the approved GGU build/release workflow rather than an arbitrary local copy. Upstream References OpenMod Plugins Golden Gamers United — Public Technical Knowledge Base General guidance first. GGU implementation details second.

OpenMod: What It Is & How It Fits Together Framework Architecture for Server Operators GGU Public Technical Knowledge Base Public Knowledge Base: This article is written for both GGU administrators and the wider server-hosting community. General instructions are platform-neutral where possible; GGU-specific practices are identified separately. Applies To OpenMod administrators Unturned/OpenMod server operators Plugin developers Prerequisites A server or test environment where OpenMod is installed or planned What You’ll Accomplish Understand the framework, plugin, permission, configuration, and logging layers before making changes. What OpenMod Is OpenMod is a plugin framework used by supported game servers to add commands, permissions, configuration, logging, and plugin-provided functionality. For administrators, the important distinction is between the OpenMod framework itself and the individual plugins installed on top of it. Core Concepts OpenMod framework: loads and manages plugins and shared services. Plugins: add features such as commands, moderation, economy, integrations, or server utilities. Roles and permissions: determine which users can execute protected actions. Configuration: OpenMod and plugins commonly use YAML files. Runtime management: OpenMod provides commands to install, update, remove, reload, and inspect components. Logging: OpenMod uses structured logging and can be configured through its logging configuration. Typical Directory Layout OpenMod/ ├── openmod.yaml ├── openmod.roles.yaml ├── openmod.translations.yaml ├── logging.yaml └── plugins/ ├── <plugin id>/ │ └── config.yaml └── ... Exact capitalization or surrounding game-server paths can differ by platform, package, or host. The important part is to distinguish framework configuration from plugin-specific configuration. Administration Model OpenMod's public administrator documentation describes a role-based permission system. Users inherit permissions from assigned roles, and roles can inherit from parent roles. This is more maintainable than individually granting every permission to every user. When to Use This KB Installing or updating a plugin. Building a role hierarchy. Finding why a command returns a permission error. Editing plugin YAML. Troubleshooting a plugin that will not load. Deploying a custom OpenMod plugin. Understanding where OpenMod logs and configuration live. GGU Implementation Notes GGU uses OpenMod primarily on supported game servers such as Unturned. Public articles should remain useful to any OpenMod operator; where GGU has an in-house plugin, role naming scheme, Pelican deployment workflow, or Gitea repository, those details are documented as implementation examples rather than universal requirements. Upstream References OpenMod Permissions OpenMod Plugins OpenMod Configuration Files Golden Gamers United — Public Technical Knowledge Base General guidance first. GGU implementation details second.

Repository Archival & Deprecation Guide Retiring Gitea Projects Safely This guide may be updated as GGU policies, procedures, platforms, and organizational needs change. Archive repositories that are no longer actively maintained but still have historical or operational value. Before Archiving Confirm the project is actually retired or superseded. Update the README with status and replacement project if one exists. Resolve or document critical open issues. Remove active secrets and obsolete deploy credentials. Archive Use Gitea's archive/read-only behavior when appropriate. Preserve tags/releases needed for historical deployments. Do not delete repositories solely because they are old. Delete Only When Deletion is explicitly approved and the repository has no continuing legal, operational, historical, or recovery value. Change Control Know what you are changing and why. Back up or ensure a rollback path for high-impact changes. Avoid combining unrelated changes. Record material production changes. Test before production when practical. Validation Confirm the service starts successfully. Review logs for new errors. Test the exact behavior changed. Confirm permissions and integrations still work. Monitor briefly after deployment for delayed failures. Escalation If a change affects systems outside your responsibility, creates a security concern, or cannot be safely reversed, stop and escalate rather than continuing to experiment in production. Archive Metadata Reason for retirement. Replacement repository/service. Last known production version. Archive owner/contact. Known dependencies still using the project. Prerequisites Confirm you are authorized to make the change. Confirm the target system/server/repository. Read current project or service documentation. Identify the expected result. Identify a rollback or recovery path for high-impact work. Common Mistakes to Avoid Copying commands or values from a different server without checking context. Making several unrelated changes before testing. Ignoring warnings because the service still appears to start. Editing production directly when a safer test or review path exists. Deleting old files or backups before the replacement is verified. Treating permissions errors as a reason to grant broad administrator access. Failing to record what changed. Operational Record For material changes, record enough information for another administrator to understand the target, change, reason, result, and rollback point. This may be a ticket, issue, pull request, deployment note, incident record, or appropriate Leadership message. If Something Goes Wrong Stop making unrelated changes. Preserve the current logs and error output. Determine whether immediate rollback is safer than continued troubleshooting. Restore the last known-good state where practical. Escalate with the exact error, target service, recent changes, and reproduction steps. After recovery, document the cause and any preventative follow-up. Archive history before deleting knowledge.

Git Rollback & Revert Procedure Recovering from Bad Changes This guide may be updated as GGU policies, procedures, platforms, and organizational needs change. Use this guide when a deployed change must be reversed. Prefer Revert for Shared History When a bad commit is already shared, prefer creating a new revert commit rather than rewriting shared branch history. Rollback Process Identify the exact change causing the problem. Stabilize production if immediate containment is needed. Revert or redeploy the last known-good version. Verify service health. Document the rollback. Open follow-up work for the underlying issue. Force Push: Do not force-push protected/shared branches to erase mistakes unless explicitly authorized for an exceptional recovery case. Change Control Know what you are changing and why. Back up or ensure a rollback path for high-impact changes. Avoid combining unrelated changes. Record material production changes. Test before production when practical. Validation Confirm the service starts successfully. Review logs for new errors. Test the exact behavior changed. Confirm permissions and integrations still work. Monitor briefly after deployment for delayed failures. Escalation If a change affects systems outside your responsibility, creates a security concern, or cannot be safely reversed, stop and escalate rather than continuing to experiment in production. Database Changes Code rollback may not reverse database migrations. Identify database rollback or compatibility requirements before deploying schema changes. Prerequisites Confirm you are authorized to make the change. Confirm the target system/server/repository. Read current project or service documentation. Identify the expected result. Identify a rollback or recovery path for high-impact work. Common Mistakes to Avoid Copying commands or values from a different server without checking context. Making several unrelated changes before testing. Ignoring warnings because the service still appears to start. Editing production directly when a safer test or review path exists. Deleting old files or backups before the replacement is verified. Treating permissions errors as a reason to grant broad administrator access. Failing to record what changed. Operational Record For material changes, record enough information for another administrator to understand the target, change, reason, result, and rollback point. This may be a ticket, issue, pull request, deployment note, incident record, or appropriate Leadership message. If Something Goes Wrong Stop making unrelated changes. Preserve the current logs and error output. Determine whether immediate rollback is safer than continued troubleshooting. Restore the last known-good state where practical. Escalate with the exact error, target service, recent changes, and reproduction steps. After recovery, document the cause and any preventative follow-up. Restore service first, then fix the root cause.