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. Mods that do not support your server's map are not listed, so they cannot be installed.

If you switch your server to a different map later, mods that were installed for the old one stay installed but are no longer deployed. The installed mods view marks each of them as Skipped and names the maps it supports, and each one notes in its log that it was skipped. Uninstall them, or switch back, and nothing else changes.

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)
• Hide on/Show on maps (for installed mods, see Mod buildings on the map)
• 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

Gameplay mods

The gameplay switches you may know from the Nitrado web interface are free mods in the marketplace:

Mod	What it changes
No Base Damage	Built bases take no damage
No Container Damage	Tents, barrels and crates take no damage
Unlimited Stamina	Players never run out of stamina
Hit Indicator (Hitmarker)	The marker showing where a hit came from: on or off, its look, color, duration and accuracy, and the red screen flash
Night Lighting	Bright, dark or Sakhal-style nights, and the faint light around players
Build Anywhere	Turns off the checks that stop building, one group at a time (objects in the way, roofs, uneven ground, height, underwater, distance)
Show Players On Map	Players see their own position on the map

All of them change cfggameplay.json. dzbot keeps enableCfgGameplayFile switched on for your server (see Nitrado setup), so they work without any change in Nitrado. While that file is on, the matching switches in the Nitrado web interface have no effect — use the mods instead. Like every mod, a change applies after the next restart.

To switch one on only at certain times, schedule it in the Scheduler: an Install/uninstall mods task for on and off — for a raid weekend, uninstall No Base Damage and No Container Damage on Friday and install them again on Monday — or a Change mod configuration task to change one of its settings, such as darker nights on weekends.

Mod buildings on the map

The buildings and objects your mods place through object spawner files (a safe zone, a bunker, a trader camp) appear on every map of your server: the map on your server website, the zone editor, coordinate pickers, player routes and the map pictures of map.image. They are drawn like the rest of the map, so a safe zone looks like a town and not like a marker.

• What counts: every installed marketplace mod and every live custom mod that writes a spawner file (a JSON file with an Objects list). dzbot's own spawner files (shop deliveries, zone markers) and mods hidden with Hide on maps are left out.
• Only vanilla objects: objects are drawn from DayZ's own building shapes. An object dzbot does not know the shape of is left out and counted as without a known shape.
• When it updates: in the Installed mods view, the Map card shows when the map was last computed. Recompute draws it again from the mods as they are configured now (once a day); it also happens once a week on its own. The map does not wait for a restart, so it can show a mod a little before the server spawns it.
• Map change: after you switch the server to another map, mod objects disappear until the map is recomputed.
• Mission files: the same recompute (and the weekly run) also reads your mission files for the map's heli crashes, vehicles, zones, spawns and loot — see Events, spawns and loot from your server. The card shows when they were last read, or why reading failed.
• Remove takes the mod objects off the map at once, for example after hiding a mod that was already drawn. The next recompute brings back everything that is not hidden.

Players never get your spawner files: the map only receives pictures, not the objects and their positions.

Custom iZurvive map

iZurvive can build a custom map for your server that shows the buildings your object spawner files place. You connect your Nitrado account on iZurvive's side. dzbot has no part in that step, and you share the link iZurvive gives you with your community.

iZurvive leaves out everything listed in izurvive.json in your mission folder, and dzbot keeps that file up to date on every restart:

• the spawner files dzbot rewrites on every restart (shop deliveries and zone markers) are always left out, so a delivery crate or a zone marker never ends up on the map
• a mod whose buildings should not appear, for example an arena or a maze, is hidden with Hide on maps in the menu of its details page. This works for marketplace mods and custom mods, and hides it on the dzbot map too. Show on maps brings it back
• your own entries stay. dzbot adds its lines to the izurvive.json you already had. Once dzbot manages the file, edit izurvive.json.original instead, as with every managed file (see below)

A change applies after the next restart, and the map changes the next time iZurvive rebuilds it.

Paid mods and ownership

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

Related documentation

• Scheduler
• Shop system
• Modding