Skip to main content

Mods

This page explains how mod management works in the admin area, including install/update flows, multiple configurations, and file-safety behavior.

Access and availability​

Mods in admin depend on both:

  • access rights: mods.view and mods.install

Practical split:

  • mods.view: browse mods, open details, review file changes and configurations
  • mods.install: install, uninstall, update, reorder, and configuration-changing actions

Where admins manage mods​

Navigation paths:

  • Server Admin -> Mods -> All mods
  • Server Admin -> Mods -> Installed mods

All mods view​

The All mods view is your marketplace-style overview.

It provides:

  • search by mod name
  • maintainer information
  • verification state
  • price (free or paid)
  • install footprint (how many servers currently run the mod)
  • quick link to mod details

Map compatibility is enforced automatically. If a mod is not supported for your server map, it cannot be installed.

Installed mods view​

The Installed mods view is your operational list for active and inactive configurations.

Per entry, admins can:

  • see whether that configuration is currently installed
  • see whether auto-update is enabled for that mod
  • open details
  • install or uninstall a specific configuration
  • remove a configuration that is not installed
  • change load order for installed entries (move up/down)

Mod details page​

The details page has three tabs:

  • Information: description and maintainership context
  • File changes: preview of the generated diff against your current server files
  • Configuration: manage one or more server configurations for that mod

Top action behavior depends on state:

  • Buy mod (for paid mods not yet owned)
  • Install (for installable mods)
  • Enable/disable auto-update (for installed mods)
  • Uninstall all (when any configuration is currently installed)

If a newer released version exists, the page shows an update warning and offers update action. If auto-update is enabled, installed configurations of that mod are moved to the latest released version automatically when the creator publishes a new release.

Important behavior:

  • auto-update is managed per mod on a server, even if the mod has multiple configurations
  • enabling auto-update also catches the mod up to the current released version immediately
  • file transfer and restart expectations still follow the normal admin workflow after version changes

Paid mods require purchase before installation.

After purchase, ownership may take a short time to appear in the UI. During this period, install actions can remain unavailable briefly.

Configuration model​

A mod can have one or multiple server configurations, depending on how the mod author designed it.

What you can do:

  • create first configuration
  • add additional configurations (if supported)
  • edit configuration values
  • set a configuration description label
  • install/uninstall each configuration independently

Important behavior:

  • invalid configuration blocks effective install behavior until corrected
  • when a mod is updated to a new version, review configuration values again
  • new configurations inherit the mod's current auto-update preference

Mods that support multiple installations (e.g. a teleporter mod installable several times for different locations) use the built-in {$installation_id} variable in their file paths. Each configuration instance gets a unique identifier, so separate installations do not overwrite each other's files. No admin action is required — this is handled automatically by the mod author's design.

File safety model (.original)​

dzbot protects baseline files using .original backups.

How it works:

  • before managed file changes are applied, baseline content is preserved in matching .original files
  • generated mod output is built from that baseline
  • uninstall/recover flows use baseline data to restore files

Operational rule:

  • if you manually edit a file managed by mods, edit the .original baseline file, not only the generated active file
  • do not delete .original files

Apply model and restart expectation​

Mod file transfer is handled by dzbot-managed transfer logic. Gameplay impact generally requires restart cycles to be fully applied in-game.

Recommended operations practice:

  • perform restarts through dzbot after mod install/uninstall/update changes
  • avoid mixing manual external restart workflows for mod-heavy servers