Personal Projects

DayZ - Commie Lobby

Mon, 01 Jan 0001 00:00:00 +0000

DayZ - Commie Lobby#

A modded DayZ dedicated server running on a dedicated box. DayZ-Expansion, dynamic missions and airdrops, admin tooling, and a scheduled restart cycle keep the map fresh without wiping your progress.

Connect#


Server name	[US-PNW] Commie Lobby (PVE)
Address	`51.81.167.216:2301`
Query port	`27016`
Host	`cytonicmushroom.ddns.net`
Map	Sakhal
Build	Current stable - `forceSameBuild` is on

forceSameBuild is enabled. Your DayZ client must be on the same stable build as the server. If DayZ just pushed an update, verify your game files before connecting.

Config UI - Admin Guide

Mon, 01 Jan 0001 00:00:00 +0000

Config UI - Admin Guide#

The Config UI is the web panel for running the DayZ server. It replaces SSH and hand-edited files - you sign in with a key and drive the server from a browser: start and stop it, edit config, tune loot, browse the map, and read logs.

This guide covers how to use it. It does not cover how it is deployed or built.

One rule governs everything: most changes apply at the next restart. Editing config, tuning loot, switching maps, and queuing updates all stage the change. The running server keeps its current settings until you restart it. Each section below says when this applies.

Mumble

Mon, 01 Jan 0001 00:00:00 +0000

Mumble#

Low-latency voice chat for coordinating in-game (and everything else). Free and open source, with positional audio - better for gaming than most alternatives.

Connect#


Address	`cytonicmushroom.ddns.net` (`51.81.167.216`)
Port	`64738` (default)
Software	Mumble server (Murmur)

How to join#

Install the Mumble client

Grab it from mumble.info - Windows, macOS, Linux, and mobile are all supported.
Run the audio & certificate wizards

On first launch Mumble walks you through microphone setup and generates a personal certificate. That keeps your identity between sessions - just accept the defaults.

CryptPad

Mon, 01 Jan 0001 00:00:00 +0000

CryptPad#

Self-hosted CryptPad - end-to-end encrypted docs, spreadsheets, slides, and kanban boards in the browser. Everything encrypts on your machine before it’s sent. The server stores your work but can never read it. Free and open source.

Connect#


Address	pad.cytonicmushroom.ddns.net
Software	CryptPad (self-hosted)

Not live yet - still being wired up. Once it is, reach it at the address above.

Accounts & guests#

You can open and edit any document shared with you by link as a guest - no account needed. An account gets you a home drive that remembers your documents between sessions. Registration is invite-only - ask the host for an invite.

API

Mon, 01 Jan 0001 00:00:00 +0000

API#

A signed HTTP API that controls the box’s services. Each service gets its own path namespace - DayZ lives under /dayz/*. Every call must be signed. Every action comes from a fixed allowlist - there is no arbitrary-command path. The table below is the full set.

Connect#


Address	`https://api.cytonicmushroom.ddns.net`
Auth	HMAC-SHA256 signature on every request
Access	By shared secret - ask the host

Actions#

Trigger one with POST /dayz/<action> - grouped actions with POST /dayz/<group>/<action>.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1.1: Variables & Types#

Home | Variables & Types | Next: Arrays, Maps & Sets »

Primitive Types#

Enforce Script has a small, fixed set of primitive types. You cannot define new value types — only classes (covered in Chapter 1.3 ).

Type	Size	Default Value	Description
`int`	32-bit signed	`0`	Whole numbers from -2,147,483,648 to 2,147,483,647
`float`	32-bit IEEE 754	`0.0`	Floating-point numbers
`bool`	1 bit logical	`false`	`true` or `false`
`string`	Variable	`""` (empty)	Text. Immutable value type — passed by value, not reference
`vector`	3x float	`"0 0 0"`	Three-component float (x, y, z). Passed by value
`typename`	Engine ref	`null`	A reference to a type itself, used for reflection
`void`	N/A	N/A	Used only as a return type to indicate “returns nothing”

Type Hierarchy Diagram#

graph TD
 subgraph "Value Types (passed by copy)"
 INT[int<br/>32-bit signed]
 FLOAT[float<br/>32-bit IEEE 754]
 BOOL[bool<br/>true / false]
 STRING[string<br/>immutable text]
 VECTOR[vector<br/>3x float xyz]
 end

 subgraph "Reference Types (passed by reference)"
 CLASS[Class<br/>root of all ref types]
 MANAGED[Managed<br/>no engine ref-counting]
 TYPENAME[typename<br/>type reflection]
 end

 CLASS --> MANAGED
 CLASS --> ENTITYAI[EntityAI]
 ENTITYAI --> ITEMBASE[ItemBase]
 ENTITYAI --> MANBASE[ManBase / PlayerBase]
 MANAGED --> SCRIPTHANDLER[ScriptedWidgetEventHandler]
 MANAGED --> CUSTOMCLASS[Your Custom Classes]

 style INT fill:#4A90D9,color:#fff
 style FLOAT fill:#4A90D9,color:#fff
 style BOOL fill:#4A90D9,color:#fff
 style STRING fill:#4A90D9,color:#fff
 style VECTOR fill:#4A90D9,color:#fff
 style CLASS fill:#D94A4A,color:#fff
 style MANAGED fill:#D97A4A,color:#fff

Type Constants#

Several types expose useful constants:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1.2: Arrays, Maps & Sets#

Home | « Previous: Variables & Types | Arrays, Maps & Sets | Next: Classes & Inheritance »

Introduction#

Real DayZ mods deal with collections of things: lists of players, inventories of items, mappings from player IDs to permissions, sets of active zones. Enforce Script provides three collection types to handle these needs:

array<T> — Dynamic, ordered, resizable list (the collection you will use most)
map<K,V> — Key-value associative container (hash map)
set<T> — Ordered collection with value-based removal

There are also static arrays (int arr[5]) for fixed-size data known at compile time. This chapter covers all of them in depth, including every available method, iteration patterns, and the subtle pitfalls that cause real bugs in production mods.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1.3: Classes & Inheritance#

Home | « Previous: Arrays, Maps & Sets | Classes & Inheritance | Next: Modded Classes »

Introduction#

Everything in DayZ is a class. Every weapon, vehicle, zombie, UI panel, config manager, and player is an instance of a class. Understanding how to declare, extend, and work with classes in Enforce Script is the foundation of all DayZ modding.

Enforce Script’s class system is single-inheritance, object-oriented, with access modifiers, constructors, destructors, static members, and method overriding. If you know C# or Java, the concepts are familiar — but the syntax has its own flavor, and there are important differences covered in this chapter.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1.4: Modded Classes (The Key to DayZ Modding)#

Home | « Previous: Classes & Inheritance | Modded Classes | Next: Control Flow »

Introduction#

Modded classes are the single most important concept in DayZ modding. They are the mechanism that allows your mod to change the behavior of existing game classes without replacing the original files. Without modded classes, DayZ modding as we know it would not exist.

Every major DayZ mod — Community Online Tools, VPP Admin Tools, DayZ Expansion, Trader mods, medical overhauls, building systems — works by using modded class to hook into vanilla classes and add or change behavior. When you mod PlayerBase, every player in the game gets your new behavior. When you mod MissionServer, your code runs as part of the server’s mission lifecycle. When you mod ItemBase, every item in the game is affected.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1.5: Control Flow#

Home | « Previous: Modded Classes | Control Flow | Next: String Operations »

if / else / else if#

The if statement evaluates a boolean expression and executes a block of code when the result is true. You can chain conditions with else if and provide a fallback with else.

void CheckHealth(PlayerBase player)
{
 float health = player.GetHealth("", "Health");

 if (health > 75)
 {
 Print("Player is healthy");
 }
 else if (health > 25)
 {
 Print("Player is wounded");
 }
 else
 {
 Print("Player is critical");
 }
}

Null checks#

In Enforce Script, object references evaluate to false when null. This is the standard way to guard against null access:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1.6: String Operations#

Home | « Previous: Control Flow | String Operations | Next: Math & Vectors »

Introduction#

Strings in Enforce Script are a value type, like int or float. They are passed by value and compared by value. The string type has a rich set of built-in methods for searching, slicing, converting, and formatting text. This chapter is a complete reference for every string operation available in DayZ scripting, with real-world examples from mod development.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1.7: Math & Vector Operations#

Home | « Previous: String Operations | Math & Vector Operations | Next: Memory Management »

Introduction#

DayZ modding frequently requires mathematical calculations: finding distances between players, randomizing spawn positions, interpolating camera movements, computing angles for AI targeting. Enforce Script provides the Math class for scalar operations and the vector type with static helpers for 3D math. This chapter is a complete reference for both, organized by category.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1.8: Memory Management#

Home | « Previous: Math & Vectors | Memory Management | Next: Casting & Reflection »

Introduction#

Enforce Script uses automatic reference counting (ARC) for memory management – not garbage collection in the traditional sense. Understanding how ref, autoptr, and raw pointers work is essential for writing stable DayZ mods. Get it wrong and you will either leak memory (your server gradually consumes more RAM until it crashes) or access deleted objects (instant crash with no useful error message). This chapter explains every pointer type, when to use each, and how to avoid the most dangerous pitfall: reference cycles.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1.9: Casting & Reflection#

Home | « Previous: Memory Management | Casting & Reflection | Next: Enums & Preprocessor »

Goal: Master safe type casting, runtime type checks, and Enforce Script’s reflection API for dynamic property access.

Table of Contents#

Why Casting Matters
Class.CastTo — Safe Downcasting
Type.Cast — Alternative Casting
CastTo vs Type.Cast — When to Use Which
obj.IsInherited — Runtime Type Checking
obj.IsKindOf — String-Based Type Checking
obj.Type — Get Runtime Type
typename — Storing Type References
Reflection API
- Inspecting Variables
- EnScript.GetClassVar / SetClassVar
Real-World Examples
Common Mistakes
Summary
Navigation

Why Casting Matters#

DayZ’s entity hierarchy is deep. Most engine APIs return a generic base type (Object, Man, Class), but you need a specific type (PlayerBase, ItemBase, CarScript) to access specialized methods. Casting converts a base reference into a derived reference — safely.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1.10: Enums & Preprocessor#

Home | « Previous: Casting & Reflection | Enums & Preprocessor | Next: Error Handling »

Goal: Understand enum declarations, enum reflection tools, bitflag patterns, constants, and the preprocessor system for conditional compilation.

Table of Contents#

Enum Declaration
Using Enums
Enum Reflection
- typename.EnumToString
- typename.StringToEnum
Bitflags Pattern
Constants
Preprocessor Directives
Real-World Examples
Common Mistakes
Summary
Navigation

Enum Declaration#

Enums in Enforce Script define named integer constants grouped under a type name. They behave like int under the hood.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1.11: Error Handling#

Home | « Previous: Enums & Preprocessor | Error Handling | Next: Gotchas »

Goal: Learn how to handle errors in a language with no try/catch. Master guard clauses, defensive coding, and structured logging patterns that keep your mod stable.

Table of Contents#

The Fundamental Rule: No try/catch
Guard Clause Pattern
Null Checking
ErrorEx — Engine Error Reporting
- Severity Levels
- When to Use Each Level
DumpStackString — Stack Traces
Debug Printing
- Basic Print
- Conditional Debug with #ifdef
Structured Logging Patterns
Real-World Examples
Defensive Patterns Summary
Common Mistakes
Summary
Navigation

The Fundamental Rule: No try/catch#

Enforce Script has no exception handling. There is no try, no catch, no throw, no finally. If something goes wrong at runtime (null dereference, invalid cast, array out of bounds), the engine either:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1.12: What Does NOT Exist (Gotchas)#

Home | « Previous: Error Handling | Gotchas | Next: Functions & Methods »

Goal: A complete catalog of features you expect from C++, C#, Java, or Python that are missing or different in Enforce Script. Each entry explains what you would try, what happens, and the correct workaround.

Complete Gotchas Reference#

1. No Ternary Operator#

What you would write:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 1.13: Functions & Methods#

Home | « Previous: Gotchas | Functions & Methods

Introduction#

Functions are the fundamental unit of behavior in Enforce Script. Every action a mod performs — spawning an item, checking a player’s health, sending an RPC, drawing a UI element — lives inside a function. Understanding how to declare them, pass data in and out, and work with the engine’s special modifiers is essential for writing correct DayZ mods.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 2.1: The 5-Layer Script Hierarchy#

Home | The 5-Layer Script Hierarchy | Next: config.cpp Deep Dive »

Summary: DayZ organizes all scripts into five compilation layers. Understanding these layers is the single most important concept in DayZ modding – it determines where every file in your mod lives, what it can access, and when it executes.

Table of Contents#

Overview
The Layer Stack
Layer 1: 1_Core (engineScriptModule)
Layer 2: 2_GameLib (gameLibScriptModule)
Layer 3: 3_Game (gameScriptModule)
Layer 4: 4_World (worldScriptModule)
Layer 5: 5_Mission (missionScriptModule)
The Critical Rule
Load Order and Timing
When Each Layer Executes
Practical Guidelines
Quick Decision Guide
Common Mistakes

Overview#

The DayZ engine compiles scripts in five distinct passes called script modules. Each module corresponds to a numbered folder in your mod’s Scripts/ directory:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 2.2: config.cpp Deep Dive#

Home | « Previous: The 5-Layer Script Hierarchy | config.cpp Deep Dive | Next: mod.cpp & Workshop »

Summary: The config.cpp file is the heart of every DayZ mod. It tells the engine what your mod depends on, where your scripts live, what items it defines, and how it integrates with the game. Every PBO must have one. Getting it wrong means your mod silently fails to load.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 2.3: mod.cpp & Workshop#

Home | « Previous: config.cpp Deep Dive | mod.cpp & Workshop | Next: Minimum Viable Mod »

Summary: The mod.cpp file is pure metadata – it controls how your mod appears in the DayZ launcher, in-game mod list, and Steam Workshop. It has no effect on gameplay, scripting, or load order. If config.cpp is the engine, mod.cpp is the paint job.

Table of Contents#

Overview
Where mod.cpp Lives
All Fields Reference
Field Details
Client Mod vs Server Mod
Workshop Metadata
Required vs Optional Fields
Real Examples
Tips and Best Practices

Overview#

mod.cpp sits at the root of your mod folder (next to the Addons/ directory). The DayZ launcher reads it to display your mod’s name, logo, description, and author in the mod selection screen.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 2.4: Your First Mod – Minimum Viable#

Home | « Previous: mod.cpp & Workshop | Minimum Viable Mod | Next: File Organization »

Summary: This chapter walks you through creating the smallest possible DayZ mod from scratch. By the end, you will have a working mod that prints a message to the script log when the game starts. Three files, zero dependencies, under five minutes.

Table of Contents#

What You Need
The Goal
Step 1: Create the Directory Structure
Step 2: Create mod.cpp
Step 3: Create config.cpp
Step 4: Create Your First Script
Step 5: Pack and Test
Step 6: Verify It Works
Understanding What Happened
Next Steps
Troubleshooting

What You Need#

DayZ game installed (retail or DayZ Tools/Diag)
A text editor (VS Code, Notepad++, or any plain text editor)
DayZ Tools installed (for PBO packing) – OR you can test without packing (see Step 5)

The Goal#

We will create a mod called HelloMod that:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 2.5: File Organization Best Practices#

Home | « Previous: Minimum Viable Mod | File Organization | Next: Server vs Client Architecture »

Summary: How you organize files determines whether your mod is maintainable at 10 files or 1,000. This chapter covers the canonical directory structure, naming conventions, content vs script vs framework mods, client-server splits, and lessons from professional DayZ mods.

Table of Contents#

The Canonical Directory Structure
Naming Conventions
Three Types of Mods
Client-Server Split Mods
What Goes Where
PBO Naming and @mod Folder Naming
Real Examples from Professional Mods
Anti-Patterns

The Canonical Directory Structure#

This is the standard layout used by professional DayZ mods. Not every folder is required – only create what you need.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 2.6: Server vs Client Architecture#

Home | « Previous: File Organization | Server vs Client Architecture

Summary: DayZ is a client-server game. Every line of code you write runs in a specific context – server, client, or both. Understanding this split is essential for writing secure, functional mods. This chapter explains where code runs, how to detect which side you are on, how to structure multi-package mods, and the patterns that keep server and client code properly separated.

Mon, 01 Jan 0001 00:00:00 +0000

Home | Widget Types | Next: Layout Files »

DayZ’s GUI system is built on widgets – reusable UI components that range from simple containers to complex interactive controls. Every visible element on screen is a widget, and understanding the full catalog is essential for building mod UIs.

This chapter provides a complete reference of all widget types available in Enforce Script.

How Widgets Work#

Every widget in DayZ inherits from the Widget base class. Widgets are organized in a parent-child tree, where the root is typically a WorkspaceWidget obtained via GetGame().GetWorkspace().

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 3.2: Layout File Format (.layout)#

Home | « Previous: Widget Types | Layout File Format | Next: Sizing & Positioning »

DayZ uses a custom text-based format for UI layout files. These .layout files are NOT XML – they use a brace-delimited format similar to config.cpp. The DayZ Workbench editor generates them, but understanding the format lets you hand-edit layouts and debug problems.

Basic Structure#

A .layout file defines a tree of widgets. Every file has exactly one root widget, which contains nested children.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 3.3: Sizing & Positioning#

Home | « Previous: Layout File Format | Sizing & Positioning | Next: Container Widgets »

The DayZ layout system uses a dual coordinate mode – every dimension can be either proportional (relative to the parent) or pixel-based (absolute screen pixels). Misunderstanding this system is the number one source of layout bugs. This chapter explains it thoroughly.

The Core Concept: Proportional vs. Pixel#

Every widget has a position (x, y) and a size (width, height). Each of these four values can independently be either:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 3.4: Container Widgets#

Home | « Previous: Sizing & Positioning | Container Widgets | Next: Programmatic Widgets »

Container widgets organize child widgets within them. While FrameWidget is the simplest (invisible box, manual positioning), DayZ provides three specialized containers that handle layout automatically: WrapSpacerWidget, GridSpacerWidget, and ScrollWidget.

Container Comparison#

graph LR
 subgraph "FrameWidget (Absolute)"
 FA["Child A<br/>pos: 10,10"]
 FB["Child B<br/>pos: 200,10"]
 FC["Child C<br/>pos: 10,100"]
 end

 subgraph "WrapSpacer (Flow)"
 WA["Item 1"] --> WB["Item 2"] --> WC["Item 3"]
 WC --> WD["Item 4<br/>(wraps to next row)"]
 end

 subgraph "GridSpacer (Grid)"
 GA["Cell 0,0"] --- GB["Cell 1,0"] --- GC["Cell 2,0"]
 GD["Cell 0,1"] --- GE["Cell 1,1"] --- GF["Cell 2,1"]
 end

 style FA fill:#4A90D9,color:#fff
 style WA fill:#2D8A4E,color:#fff
 style GA fill:#D97A4A,color:#fff

FrameWidget – Structural Container#

FrameWidget is the most basic container. It draws nothing on screen and does not arrange its children – you must position each child manually.

Mon, 01 Jan 0001 00:00:00 +0000

Home | « Previous: Container Widgets | Programmatic Widget Creation | Next: Event Handling »

While .layout files are the standard way to define UI structure, you can also create and configure widgets entirely from code. This is useful for dynamic UIs, procedurally generated elements, and situations where the layout is not known at compile time.

Two Approaches#

DayZ provides two ways to create widgets in code:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 3.6: Event Handling#

Home | « Previous: Programmatic Widget Creation | Event Handling | Next: Styles, Fonts & Images »

Widgets generate events when the user interacts with them – clicking buttons, typing in edit boxes, moving the mouse, dragging elements. This chapter covers how to receive and handle those events.

ScriptedWidgetEventHandler#

The ScriptedWidgetEventHandler class is the foundation of all widget event handling in DayZ. It provides override methods for every possible widget event.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 3.7: Styles, Fonts & Images#

Home | « Previous: Event Handling | Styles, Fonts & Images | Next: Dialogs & Modals »

This chapter covers the visual building blocks of DayZ UI: predefined styles, font usage, text sizing, image widgets with imageset references, and how to create custom imagesets for your mod.

Styles#

Styles are predefined visual appearances that can be applied to widgets via the style attribute in layout files. They control background rendering, borders, and overall look without requiring manual color and image configuration.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 3.8: Dialogs & Modals#

Home | « Previous: Styles, Fonts & Images | Dialogs & Modals | Next: Real Mod UI Patterns »

Dialogs are temporary overlay windows that demand user interaction – confirmation prompts, alert messages, input forms, and settings panels. This chapter covers the built-in dialog system, manual dialog patterns, layout structure, focus management, and common pitfalls.

There are two fundamental types of dialog:

Modal – Blocks all interaction with content behind the dialog. The user must respond (confirm, cancel, close) before doing anything else. Examples: quit confirmation, delete warning, rename prompt.
Modeless – Allows the user to interact with content behind the dialog while it remains open. Examples: info panels, settings windows, tool palettes.

In DayZ, the distinction is controlled by whether you lock game input when the dialog opens. A modal dialog calls ChangeGameFocus(1) and shows the cursor; a modeless dialog may skip this or use a toggle approach.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 3.9: Real Mod UI Patterns#

Home | « Previous: Dialogs & Modals | Real Mod UI Patterns | Next: Advanced Widgets »

This chapter surveys UI patterns found in six professional DayZ mods: COT (Community Online Tools), VPP Admin Tools, DabsFramework, Colorful UI, Expansion, and DayZ Editor. Each mod solves different problems. Studying their approaches gives you a library of proven patterns beyond what official documentation covers.

All code shown is extracted from actual mod source. File paths reference the original repositories.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 3.10: Advanced Widgets#

Home | « Previous: Real Mod UI Patterns | Advanced Widgets

Beyond the standard containers, text, and image widgets covered in earlier chapters, DayZ provides specialized widget types for rich text formatting, 2D canvas drawing, map display, 3D item previews, video playback, and render-to-texture. These widgets unlock capabilities that simple layouts cannot achieve.

This chapter covers every advanced widget type with confirmed API signatures extracted from vanilla source code and real mod usage.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 4.1: Textures (.paa, .edds, .tga)#

Home | Textures | Next: 3D Models »

DayZ uses PAA as its runtime texture format. During development you work with source formats (TGA, PNG, EDDS) that are converted to PAA during the build process. This chapter covers the formats, naming conventions, resolution rules, and conversion workflow.

Texture Formats Overview#

DayZ uses four texture formats at different stages of the development pipeline:

Format	Extension	Role	Alpha Support	Used At
PAA	`.paa`	Runtime game format (compressed)	Yes	Final build, shipped in PBOs
EDDS	`.edds`	Editor/intermediate DDS variant	Yes	Object Builder preview, auto-converts
TGA	`.tga`	Uncompressed source artwork	Yes	Artist workspace, Photoshop/GIMP export
PNG	`.png`	Portable source format	Yes	UI textures, external tools

The general workflow is: Source (TGA/PNG) –> DayZ Tools conversion –> PAA (game-ready).

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 4.2: 3D Models (.p3d)#

Home | « Previous: Textures | 3D Models | Next: Materials »

Introduction#

Every physical object in DayZ – weapons, clothing, buildings, vehicles, trees, rocks – is a 3D model stored in Bohemia’s proprietary P3D format. The P3D format is far more than a mesh container: it encodes multiple levels of detail, collision geometry, animation selections, memory points for attachments and effects, and proxy positions for mountable items. Understanding how P3D files work and how to create them with Object Builder is essential for any mod that adds physical items to the game world.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 4.3: Materials (.rvmat)#

Home | « Previous: 3D Models | Materials | Next: Audio »

Introduction#

A material in DayZ is the bridge between a 3D model and its visual appearance. While textures provide raw image data, the RVMAT (Real Virtuality Material) file defines how those textures are combined, which shader interprets them, and what surface properties the engine should simulate – shininess, transparency, self-illumination, and more. Every face on every P3D model in the game references an RVMAT file, and understanding how to create and configure them is essential for any visual mod.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 4.4: Audio (.ogg, .wss)#

Home | « Previous: Materials | Audio | Next: DayZ Tools Workflow »

Introduction#

Sound design is one of the most immersive aspects of DayZ modding. From the crack of a rifle to the ambient wind in a forest, audio brings the game world to life. DayZ uses OGG Vorbis as its primary audio format and configures sound playback through a layered system of CfgSoundShaders and CfgSoundSets defined in config.cpp. Understanding this pipeline – from raw audio file to spatialized in-game sound – is essential for any mod that introduces custom weapons, vehicles, ambient effects, or UI feedback.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 4.5: DayZ Tools Workflow#

Home | « Previous: Audio | DayZ Tools | Next: PBO Packing »

Introduction#

DayZ Tools is a free suite of development applications distributed through Steam, provided by Bohemia Interactive for modders. It contains everything needed to create, convert, and package game assets: a 3D model editor, texture viewer, terrain editor, script debugger, and the binarization pipeline that transforms human-readable source files into optimized game-ready formats. No DayZ mod can be built without at least some interaction with these tools.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 4.6: PBO Packing#

Home | « Previous: DayZ Tools Workflow | PBO Packing | Next: Workbench Guide »

Introduction#

A PBO (Packed Bank of Objects) is DayZ’s archive format – the equivalent of a .zip file for game content. Every mod the game loads is delivered as one or more PBO files. When a player subscribes to a mod on Steam Workshop, they download PBOs. When a server loads mods, it reads PBOs. The PBO is the final deliverable of the entire modding pipeline.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 4.7: Workbench Guide#

Home | « Previous: PBO Packing | Workbench Guide | Next: Building Modeling »

Introduction#

Workbench is Bohemia Interactive’s integrated development environment for the Enfusion engine. It ships with DayZ Tools and is the only official tool that understands Enforce Script at a language level. While many modders write code in VS Code or other editors, Workbench remains indispensable for tasks no other tool can perform: attaching a debugger to a running DayZ instance, setting breakpoints, stepping through code, inspecting variables at runtime, previewing .layout UI files, browsing game resources, and running live script commands through the built-in console.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 4.8: Building Modeling – Doors & Ladders#

Home | « Previous: Workbench Guide | Building Modeling

Introduction#

Buildings in DayZ are more than static scenery. Players interact with them constantly – opening doors, climbing ladders, taking cover behind walls. Creating a custom building that supports these interactions requires careful model setup: doors need rotation axes and named selections across multiple LODs, ladders need precisely placed climbing paths defined entirely through Memory LOD vertices.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 5.1: stringtable.csv — Localization#

Home | stringtable.csv | Next: inputs.xml »

Summary: The stringtable.csv file provides localized text for your DayZ mod. The engine reads this CSV at startup and resolves translation keys based on the player’s language setting. Every user-facing string — UI labels, input binding names, item descriptions, notification text — should live in a stringtable rather than being hardcoded.

Table of Contents#

Overview
CSV Format
Column Reference
Key Naming Convention
Referencing Strings
Creating a New Stringtable
Empty Cell Handling and Fallback Behavior
Multi-Language Workflow
Modular Stringtable Approach (DayZ Expansion)
Real Examples
Common Mistakes

Overview#

DayZ uses a CSV-based localization system. When the engine encounters a string key prefixed with # (for example, #STR_MYMOD_HELLO), it looks up that key in all loaded stringtable files and returns the translation matching the player’s current language. If no match is found for the active language, the engine falls back through a defined chain.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 5.2: inputs.xml — Custom Keybindings#

Home | « Previous: stringtable.csv | inputs.xml | Next: Credits.json »

Summary: The inputs.xml file lets your mod register custom keybindings that appear in the player’s Controls settings menu. Players can view, rebind, and toggle these inputs just like vanilla actions. This is the standard mechanism for adding hotkeys to DayZ mods.

Table of Contents#

Overview
File Location
Complete XML Structure
Actions Block
Sorting Block
Preset Block (Default Keybindings)
Modifier Combos
Hidden Inputs
Multiple Default Keys
Accessing Inputs in Script
Input Methods Reference
Suppressing and Disabling Inputs
Key Names Reference
Real Examples
Common Mistakes

Overview#

When your mod needs the player to press a key — opening a menu, toggling a feature, commanding an AI unit — you register a custom input action in inputs.xml. The engine reads this file at startup and integrates your actions into the universal input system. Players see your keybindings in the game’s Settings > Controls menu, grouped under a heading you define.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 5.3: Credits.json#

Home | « Previous: inputs.xml | Credits.json | Next: ImageSet Format »

Summary: The Credits.json file defines the credits that DayZ displays for your mod in the game’s mod menu. It lists team members, contributors, and acknowledgments organized by departments and sections. While purely cosmetic, it is the standard way to give credit to your development team.

Table of Contents#

Overview
File Location
JSON Structure
How DayZ Displays Credits
Using Localized Section Names
Templates
Real Examples
Common Mistakes

Overview#

When a player selects your mod in the DayZ launcher or in-game mod menu, the engine looks for a Credits.json file inside your mod’s PBO. If found, the credits are displayed in a scrolling view organized into departments and sections — similar to movie credits.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 5.4: ImageSet Format#

Home | « Previous: Credits.json | ImageSet Format | Next: Server Configuration Files »

Summary: ImageSets define named sprite regions within a texture atlas. They are DayZ’s primary mechanism for referencing icons, UI graphics, and sprite sheets from layout files and scripts. Instead of loading hundreds of individual image files, you pack all icons into a single texture and describe each icon’s position and size in an imageset definition file.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 5.5: Server Configuration Files#

Home | « Previous: ImageSet Format | Server Configuration Files | Next: Spawning Gear Configuration »

Summary: DayZ servers are configured through XML, JSON, and script files in the mission folder (e.g., mpmissions/dayzOffline.chernarusplus/). These files control item spawns, economy behavior, gameplay rules, and server identity. Understanding them is essential for adding custom items to the loot economy, tuning server parameters, or building a custom mission.

Table of Contents#

Overview
init.c — Mission Entry Point
types.xml — Item Spawn Definitions
cfgspawnabletypes.xml — Attachments and Cargo
cfgrandompresets.xml — Reusable Loot Pools
globals.xml — Economy Parameters
cfggameplay.json — Gameplay Settings
serverDZ.cfg — Server Settings
How Mods Interact with the Economy
Common Mistakes

Overview#

Every DayZ server loads its configuration from a mission folder. The Central Economy (CE) files define what items spawn, where, and for how long. The server executable itself is configured through serverDZ.cfg, which lives alongside the executable.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 5.6: Spawning Gear Configuration#

Home | « Previous: Server Configuration Files | Spawning Gear Configuration

Summary: DayZ has two complementary systems that control how players enter the world: spawn points determine where a character appears on the map, and spawn gear determines what equipment they carry. This chapter covers both systems in depth, including file structure, field reference, practical presets, and mod integration.

Table of Contents#

Overview
The Two Systems
Spawn Gear: cfgPlayerSpawnGear.json
Spawn Points: cfgplayerspawnpoints.xml
Practical Examples
Integration with Mods
Best Practices
Common Mistakes

Overview#

flowchart TD
 A[Player connects] --> B{cfgGameplay.json enabled?}
 B -->|Yes| C[Load cfgPlayerSpawnGear.json]
 B -->|No| D[Use StartingEquipSetup in init.c]
 C --> E[Select preset by spawnWeight]
 E --> F[Select characterType]
 F --> G[Apply attachmentSlotItemSets]
 G --> H[Apply discreteItemSets to cargo]
 H --> I[Set item attributes - health, quantity]
 I --> J[Player spawns with gear]
 D --> J

When a player spawns as a fresh character in DayZ, two questions are answered by the server:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.1: Entity System#

Home | Entity System | Next: Vehicles »

Every object in the DayZ world — items, players, zombies, animals, buildings, vehicles — descends from a single class hierarchy rooted at IEntity. This chapter is an API reference for the core entity classes: what methods exist, what their signatures are, and how to use them correctly.

Class Hierarchy#

Class (root of all Enforce Script classes)
└── Managed
 └── IEntity // 1_Core/proto/enentity.c
 └── Object // 3_Game/entities/object.c
 └── ObjectTyped
 └── Entity
 └── EntityAI // 3_Game/entities/entityai.c
 ├── InventoryItem // 3_Game/entities/inventoryitem.c
 │ └── ItemBase // 4_World/entities/itembase.c
 │ ├── Weapon_Base, Magazine_Base
 │ └── (all inventory items)
 ├── Man // 3_Game/entities/man.c
 │ └── Human // engine native (proto)
 │ └── DayZPlayer
 │ └── DayZPlayerImplement
 │ └── ManBase
 │ └── PlayerBase // 4_World/entities/manbase/playerbase.c
 ├── Building // 3_Game/entities/building.c
 ├── DayZInfected
 │ └── ZombieBase // 4_World/entities/creatures/infected/zombiebase.c
 ├── DayZAnimal
 │ └── AnimalBase // 4_World
 └── AdvancedCommunication

Complete Entity Hierarchy#

classDiagram
 IEntity <|-- Object
 Object <|-- ObjectTyped
 ObjectTyped <|-- Entity
 Entity <|-- EntityAI
 EntityAI <|-- ItemBase
 EntityAI <|-- Man
 Man <|-- Human
 Human <|-- ManBase
 EntityAI <|-- Building
 EntityAI <|-- DayZInfected
 EntityAI <|-- DayZAnimal
 EntityAI <|-- Transport
 ManBase <|-- PlayerBase
 ItemBase <|-- Weapon_Base
 ItemBase <|-- Magazine_Base
 ItemBase <|-- Clothing_Base
 Transport <|-- CarScript
 Transport <|-- BoatScript
 Weapon_Base <|-- Rifle_Base
 Weapon_Base <|-- Pistol_Base

 class EntityAI {
 +GetHealth()
 +SetHealth()
 +IsAlive()
 +Delete()
 }
 class PlayerBase {
 +GetIdentity()
 +GetBleeding()
 +IsRestrained()
 }

Key points:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.2: Vehicle System#

Home | « Previous: Entity System | Vehicles | Next: Weather »

Introduction#

DayZ vehicles are entities that extend the transport system. Cars extend CarScript, boats extend BoatScript, and both inherit from Transport. Vehicles have fluid systems, parts with independent health, gear simulation, and physics managed by the engine. This chapter covers the API methods you need to interact with vehicles in scripts.

Class Hierarchy#

EntityAI
└── Transport // 3_Game - base for all vehicles
 ├── Car // 3_Game - engine-native car physics
 │ └── CarScript // 4_World - scriptable car base
 │ ├── CivilianSedan
 │ ├── OffroadHatchback
 │ ├── Hatchback_02
 │ ├── Sedan_02
 │ ├── Truck_01_Base
 │ └── ...
 └── Boat // 3_Game - engine-native boat physics
 └── BoatScript // 4_World - scriptable boat base

Transport (Base)#

File: 3_Game/entities/transport.c

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.3: Weather System#

Home | « Previous: Vehicles | Weather | Next: Cameras »

Introduction#

DayZ has a fully dynamic weather system controlled through the Weather class. The system manages overcast, rain, snowfall, fog, wind, and thunderstorms. Weather can be configured through script (the Weather API), through cfgweather.xml in the mission folder, or through a scripted weather state machine. This chapter covers the script API for reading and controlling weather programmatically.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.4: Camera System#

Home | « Previous: Weather | Cameras | Next: Post-Process Effects »

Introduction#

DayZ uses a multi-layered camera system. The player camera is managed by the engine through DayZPlayerCamera subclasses. For modding and debugging, the FreeDebugCamera allows free-flight. The engine also provides global accessors for the current camera state. This chapter covers camera types, how to access camera data, and how to use the scripted camera tools.

Current Camera State (Global Accessors)#

These methods are available anywhere and return the active camera’s state regardless of camera type:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.5: Post-Process Effects (PPE)#

Home | « Previous: Cameras | Post-Process Effects | Next: Notifications »

Introduction#

DayZ’s Post-Process Effects (PPE) system controls visual effects applied after scene rendering: blur, color grading, vignette, chromatic aberration, night vision, and more. The system is built around PPERequester classes that can request specific visual effects. Multiple requesters can be active simultaneously, and the engine blends their contributions. This chapter covers how to use the PPE system in mods.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.6: Notification System#

Home | « Previous: Post-Process Effects | Notifications | Next: Timers & CallQueue »

Introduction#

DayZ includes a built-in notification system for displaying toast-style popup messages to players. The NotificationSystem class provides static methods for sending notifications both locally (client-side) and from server to client via RPC. This chapter covers the full API for sending, customizing, and managing notifications.

NotificationSystem#

File: 3_Game/client/notifications/notificationsystem.c (320 lines)

A static class that manages the notification queue. Notifications appear as small popup cards at the top of the screen, stacked vertically, and fade out after their display time expires.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.7: Timers & CallQueue#

Home | « Previous: Notifications | Timers & CallQueue | Next: File I/O & JSON »

Introduction#

DayZ provides several mechanisms for deferred and repeating function calls: ScriptCallQueue (the primary system), Timer, ScriptInvoker, and WidgetFadeTimer. These are essential for scheduling delayed logic, creating update loops, and managing timed events without blocking the main thread. This chapter covers each mechanism with full API signatures and usage patterns.

Call Categories#

All timer and call queue systems require a call category that determines when the deferred call executes within the frame:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.8: File I/O & JSON#

Home | « Previous: Timers & CallQueue | File I/O & JSON | Next: Networking & RPC »

Introduction#

DayZ provides file I/O operations for reading and writing text files, JSON serialization/deserialization, directory management, and file enumeration. All file operations use special path prefixes ($profile:, $saves:, $mission:) rather than absolute filesystem paths. This chapter covers every file operation available in Enforce Script.

Path Prefixes#

Prefix	Location	Writable
`$profile:`	Server/client profile directory (e.g., `DayZServer/profiles/`)	Yes
`$saves:`	Save directory	Yes
`$mission:`	Current mission folder (e.g., `mpmissions/dayzOffline.chernarusplus/`)	Read typically
`$CurrentDir:`	Current working directory	Depends
No prefix	Relative to game root	Read only

Important: Most file write operations are restricted to $profile: and $saves:. Attempting to write elsewhere may silently fail.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.9: Networking & RPC#

Home | « Previous: File I/O & JSON | Networking & RPC | Next: Central Economy »

DayZ is a client-server game. All authoritative logic runs on the server, and clients communicate with it through Remote Procedure Calls (RPCs). This chapter covers ScriptRPC, the serialization context classes, the legacy CGame.RPC() method, and ScriptInputUserData for input-verified client-to-server messages.

Client-Server Architecture#

graph LR
 Client["Client<br/>GetGame().IsClient()"] -- "RPC →" --> Server["Server<br/>GetGame().IsServer()"]
 Server -- "← RPC" --> Client

Environment Checks#

proto native bool GetGame().IsServer(); // true on server and listen-server host
proto native bool GetGame().IsClient(); // true on client
proto native bool GetGame().IsMultiplayer(); // true in multiplayer
proto native bool GetGame().IsDedicatedServer(); // true only on dedicated server

Typical guard pattern:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.10: Central Economy#

Home | « Previous: Networking & RPC | Central Economy | Next: Mission Hooks »

Introduction#

The Central Economy (CE) is DayZ’s server-side system for managing all spawnable entities in the world: loot, vehicles, infected, animals, and dynamic events. It is configured entirely through XML files in the mission folder. While the CE itself is an engine system (not directly scriptable), understanding its configuration files is essential for any server mod. This chapter covers all CE configuration files, their structure, key parameters, and how they interact.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.11: Mission Hooks#

Home | « Previous: Central Economy | Mission Hooks | Next: Action System »

Introduction#

Every DayZ mod needs an entry point — a place where it initializes managers, registers RPC handlers, hooks into player connections, and cleans up on shutdown. That entry point is the Mission class. The engine creates exactly one Mission instance when a scenario loads: MissionServer on a dedicated server, MissionGameplay on a client, or both on a listen server. These classes provide lifecycle hooks that fire in a guaranteed order, giving mods a reliable place to inject behavior.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.12: Action System#

Home | « Previous: Mission Hooks | Action System | Next: Input System »

Introduction#

The Action System is how DayZ handles all player interactions with items and the world. Every time a player eats food, opens a door, bandages a wound, repairs a wall, or turns on a flashlight, the engine runs through the action pipeline. Understanding this pipeline — from condition checks to animation callbacks to server execution — is fundamental to creating any interactive gameplay mod.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.13: Input System#

Home | « Previous: Action System | Input System | Next: Player System »

Introduction#

The DayZ input system connects hardware inputs — keyboard, mouse, and gamepad — to named actions that scripts can query. It operates in two layers:

inputs.xml (config layer) — declares named actions, assigns default keybindings, and organizes them into groups for the player’s Controls settings menu. See Chapter 5.2: inputs.xml for full coverage.
UAInput API (script layer) — queries input state at runtime. This is what your scripts call every frame to detect presses, releases, holds, and analog values.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.14: Player System#

Home | « Previous: Input System | Player System | Next: Sound System »

Introduction#

PlayerBase is the single most important class in DayZ modding. Every gameplay system — health, hunger, bleeding, stamina, inventory, restraints, unconsciousness — lives on the player entity or one of its manager subsystems. Whether you are writing an admin tool, a survival mechanic, or a PvP mod, you will interact with PlayerBase constantly.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.15: Sound System#

Home | « Previous: Player System | Sound System | Next: Crafting System »

Introduction#

DayZ provides two main approaches for playing sounds from scripts: a high-level API built around EffectSound and SEffectManager, and a config-driven shortcut via PlaySoundSet / StopSoundSet on entities. Both ultimately rely on engine-level CfgSoundSets and CfgSoundShaders definitions in config.cpp.

All scripted sound playback is client-side only. Dedicated servers have no audio output device — calling sound methods on a headless server wastes resources and can trigger warnings. Always guard sound calls behind !GetGame().IsDedicatedServer() or use the built-in guards provided by the API.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.16: Crafting System#

Home | « Previous: Sound System | Crafting System | Next: Construction System »

Introduction#

The Crafting System is how DayZ handles combining items to produce new items — sharpening sticks with knives, tying rags into rope, sawing off shotgun barrels, assembling splints. It is a data-driven pipeline that sits on top of the Action System (Chapter 6.12) and uses a central recipe registry to discover, validate, and execute item transformations.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.17: Construction System#

Home | « Previous: Crafting System | Construction System | Next: Animation System »

Introduction#

DayZ’s base building system allows players to construct fortifications — fences, watchtowers, and shelters — by assembling individual parts using tools and materials. Each structure is divided into named construction parts (walls, platforms, roofs, gates) that are built, dismantled, or destroyed independently.

The system lives primarily in three files:

4_World/entities/itembase/basebuildingbase.c — the entity base class
4_World/classes/basebuilding/construction.c — the construction manager
4_World/classes/basebuilding/constructionpart.c — individual part representation

Construction actions are in 4_World/classes/useractionscomponent/actions/continuous/ and construction data management is handled by constructionactiondata.c.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.18: Animation System#

Home | « Previous: Construction System | Animation System | Next: Terrain & World Queries »

Introduction#

DayZ uses a state-machine-driven animation system built into the Enfusion engine. Player animations are controlled by a hierarchy of HumanCommand classes – movement, actions, climbing, swimming, vehicles, falling, death, and unconsciousness each have their own dedicated command. Object animations (doors, lids, deployables) are driven through model.cfg AnimationSources and controlled from script via SetAnimationPhase().

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.19: Terrain & World Queries#

Home | « Previous: Animation System | Terrain & World Queries | Next: Particle & Effect System »

Introduction#

Every spatial operation in DayZ — spawning objects on the ground, checking line of sight, detecting nearby entities, determining surface type for footstep sounds — depends on querying the world. The engine exposes three categories of spatial API: terrain queries (height, surface type, normals), object queries (finding entities near a position), and raycasting (tracing a line through the world to detect collisions). This chapter documents every available method, its exact signature, and the practical patterns found in vanilla code.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.20: Particle & Effect System#

Home | « Previous: Terrain & World Queries | Particle & Effect System | Next: Zombie & AI System »

Introduction#

DayZ’s particle and visual effects system handles fire, smoke, blood, explosions, weather effects, vehicle exhaust, contaminated area gas, and more. Every visual effect you see in the game world — from a campfire to a bullet impact crater — is driven by this system.

There are two layers for working with particles from script:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.21: Zombie & AI System#

Home | « Previous: Particle & Effect System | Zombie & AI System | Next: Admin & Server Management »

Introduction#

Zombies (officially called “Infected”) are the primary hostile AI entity in DayZ. They patrol, detect players through sight, sound, and proximity, transition through behavioral states, attack, vault, crawl, and die — all driven by a C++ AI engine with script-level hooks for customization. Understanding how the infected system works is essential for any mod that spawns, modifies, or interacts with zombies.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.22: Admin & Server Management#

Home | « Previous: Zombie & AI System | Admin & Server Management | Next: World Systems »

Introduction#

Server administration in DayZ covers a broad set of responsibilities: managing connected players, enforcing rules, controlling world state (time, weather), logging events for audit trails, and integrating with persistence systems. Unlike most game engines that provide a built-in admin panel, DayZ offers only low-level scripting APIs. The admin tool ecosystem — COT, VPP, and custom solutions — is built entirely on top of these APIs.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 6.23: World Configuration Systems#

Home | « Previous: Admin & Server Management | World Systems

Introduction#

DayZ provides several JSON and XML configuration files that control world-level systems without requiring script modifications. These files live in the mission folder and are loaded at server start, allowing server owners to customize contaminated areas, underground darkness, weather behavior, gameplay rules, and object placement with no code changes and no wipe required.

This chapter covers five mission-folder configuration systems:

Mon, 01 Jan 0001 00:00:00 +0000

Engine API Quick Reference#

Home | Engine API Quick Reference

Condensed single-page reference for the most commonly used DayZ engine methods. For detailed explanations and examples, see the full chapters linked in each section header.

Table of Contents#

Entity Methods
Health & Damage
Type Checking
Inventory
Entity Creation & Deletion
Player Methods
Vehicle Methods
Weather Methods
File I/O Methods
Timer & CallQueue Methods
Widget Creation Methods
RPC / Networking Methods
Math Constants & Methods
Vector Methods
Global Functions
Mission Hooks
Action System

Entity Methods#

Full reference: Chapter 6.1: Entity System

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 7.1: Singleton Pattern#

Home | Singleton Pattern | Next: Module Systems »

The singleton pattern guarantees that a class has exactly one instance, accessible globally. In DayZ modding it is the most common architectural pattern — virtually every manager, cache, registry, and subsystem uses it.

This chapter covers the canonical implementation, lifecycle management, when the pattern is appropriate, and where it goes wrong.

Table of Contents#

The Canonical Implementation
Lazy vs Eager Initialization
Lifecycle Management
When to Use Singletons
Real-World Examples
Thread Safety Considerations
Anti-Patterns
Alternative: Static-Only Classes
Checklist

The Canonical Implementation#

The standard DayZ singleton follows a simple formula: a private static ref field, a static GetInstance() accessor, and a static DestroyInstance() for cleanup.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 7.2: Module / Plugin Systems#

Home | « Previous: Singleton Pattern | Module / Plugin Systems | Next: RPC Patterns »

Introduction#

Every serious DayZ mod framework uses a module or plugin system to organize code into self-contained units with defined lifecycle hooks. Rather than scattering initialization logic across modded mission classes, modules register themselves with a central manager that dispatches lifecycle events — OnInit, OnMissionStart, OnUpdate, OnMissionFinish — to each module in a predictable order.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 7.3: RPC Communication Patterns#

Home | « Previous: Module Systems | RPC Communication Patterns | Next: Config Persistence »

Introduction#

Remote Procedure Calls (RPCs) are the only way to send data between client and server in DayZ. Every admin panel, every synced UI, every server-to-client notification, and every client-to-server action request flows through RPCs. Understanding how to build them correctly — with proper serialization order, permission checks, and error handling — is essential for any mod that does more than add items to CfgVehicles.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 7.4: Config Persistence#

Home | « Previous: RPC Patterns | Config Persistence | Next: Permission Systems »

Introduction#

Almost every DayZ mod needs to save and load configuration data: server settings, spawn tables, ban lists, player data, teleport locations. The engine provides JsonFileLoader for simple JSON serialization and raw file I/O (FileHandle, FPrintln) for everything else. Professional mods layer config versioning and auto-migration on top.

This chapter covers the standard patterns for config persistence, from basic JSON load/save through versioned migration systems, directory management, and auto-save timers.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 7.5: Permission Systems#

Home | « Previous: Config Persistence | Permission Systems | Next: Event-Driven Architecture »

Introduction#

Every admin tool, every privileged action, and every moderation feature in DayZ needs a permission system. The question is not whether to check permissions but how to structure them. The DayZ modding community has settled on three major patterns: hierarchical dot-separated permissions, user-group role assignment (VPP), and framework-level role-based access (CF/COT). Each has different trade-offs in granularity, complexity, and server-owner experience.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 7.6: Event-Driven Architecture#

Home | « Previous: Permission Systems | Event-Driven Architecture | Next: Performance Optimization »

Introduction#

Event-driven architecture decouples the producer of an event from its consumers. When a player connects, the connection handler does not need to know about the killfeed, the admin panel, the mission system, or the logging module — it fires a “player connected” event, and each interested system subscribes independently. This is the foundation of extensible mod design: new features subscribe to existing events without modifying the code that fires them.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 7.7: Performance Optimization#

Home | « Previous: Event-Driven Architecture | Performance Optimization

Introduction#

DayZ runs at 10–60 server FPS depending on player count, entity load, and mod complexity. Every script cycle that takes too long eats into that frame budget. A single poorly-written OnUpdate that scans every vehicle on the map or rebuilds a UI list from scratch can drop server performance noticeably. Professional mods earn their reputation by running fast — not by having more features, but by implementing the same features with less waste.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 8.1: Your First Mod (Hello World)#

Home | Your First Mod | Next: Creating a Custom Item »

Table of Contents#

Prerequisites
Step 1: Install DayZ Tools
Step 2: Set Up the P: Drive (Workdrive)
Step 3: Create the Mod Directory Structure
Step 4: Write mod.cpp
Step 5: Write config.cpp
Step 6: Write Your First Script
Step 7: Pack the PBO with Addon Builder
Step 8: Load the Mod in DayZ
Step 9: Verify in the Script Log
Step 10: Troubleshooting Common Issues
Complete File Reference
Next Steps

Prerequisites#

Before you begin, make sure you have:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 8.2: Creating a Custom Item#

Home | « Previous: Your First Mod | Creating a Custom Item | Next: Building an Admin Panel »

Summary: This tutorial walks you through adding a brand-new item to DayZ. You will define the item in config.cpp, give it textures using hidden selections, add it to the server’s spawn table, create a string table for its display name, and test it in-game. By the end, you will have a custom item that players can find, pick up, and carry in their inventory.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 8.3: Building an Admin Panel Module#

Home | « Previous: Creating a Custom Item | Building an Admin Panel | Next: Adding Chat Commands »

Summary: This tutorial walks you through building a complete admin panel module from scratch. You will create a UI layout, bind widgets in script, handle button clicks, send an RPC from client to server, process the request on the server, send a response back, and display the result in the UI. This covers the full client-server-client roundtrip that every networked mod needs.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 8.4: Adding Chat Commands#

Home | « Previous: Building an Admin Panel | Adding Chat Commands | Next: Using the DayZ Mod Template »

Summary: This tutorial walks you through creating a chat command system for DayZ. You will hook into the chat input, parse command prefixes and arguments, check admin permissions, execute a server-side action, and send feedback to the player. By the end, you will have a working /heal command that fully heals the admin’s character, along with a framework for adding more commands.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 8.5: Using the DayZ Mod Template#

Home | « Previous: Adding Chat Commands | Using the DayZ Mod Template | Next: Debugging & Testing »

Summary: This tutorial shows you how to use InclementDab’s open-source DayZ Mod Template to bootstrap a new mod project in seconds. Instead of creating every file from scratch, you clone a ready-made skeleton that already has the correct folder structure, config.cpp, mod.cpp, and script layer stubs. You then rename a few things and start writing code immediately.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 8.6: Debugging & Testing Your Mod#

Home | « Previous: Using the DayZ Mod Template | Debugging & Testing | Next: Publishing to the Steam Workshop »

Summary: This tutorial teaches you how to debug and test DayZ mods effectively. You will learn to read script logs, use Print debugging, work with DayZDiag and file patching for rapid iteration, diagnose common error messages, and establish a reliable testing workflow. No IDE debugger exists for retail builds – your tools are script logs, Print statements, Workbench, DayZDiag, and file patching.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 8.7: Publishing to the Steam Workshop#

Home | « Previous: Debugging & Testing | Publishing to the Steam Workshop | Next: Building a HUD Overlay »

Summary: Your mod is built, tested, and ready for the world. This tutorial walks you through the complete publishing process from start to finish: preparing your mod folder, signing PBOs for multiplayer compatibility, creating a Steam Workshop item, uploading via DayZ Tools or command line, and maintaining updates over time. By the end, your mod will be live on the Workshop and playable by anyone.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 8.8: Building a HUD Overlay#

Home | « Previous: Publishing to the Steam Workshop | Building a HUD Overlay | Next: Professional Mod Template »

Summary: This tutorial walks you through building a custom HUD overlay that displays server information in the top-right corner of the screen. You will create a layout file, write a controller class, hook into the mission lifecycle, request data from the server via RPC, add a toggle keybind, and polish the result with fade animations and smart visibility. By the end, you will have a non-intrusive Server Info HUD showing the server name, player count, and current in-game time – plus a solid understanding of how HUD overlays work in DayZ.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 8.9: Professional Mod Template#

Home | « Previous: Building a HUD Overlay | Professional Mod Template | Next: Creating a Custom Vehicle »

Summary: This chapter provides a complete, production-ready mod template with every file you need for a professional DayZ mod. Unlike Chapter 8.5 which introduces InclementDab’s starter skeleton, this is a full-featured template with a config system, singleton manager, client-server RPC, UI panel, keybinds, localization, and build automation. Every file is copy-paste ready and heavily commented to explain why each line exists.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 8.10: Creating a Custom Vehicle Mod#

Home | « Previous: Professional Mod Template | Creating a Custom Vehicle | Next: Creating Custom Clothing »

Summary: This tutorial walks you through creating a custom vehicle variant in DayZ by extending an existing vanilla vehicle. You will define the vehicle in config.cpp, customize its stats and textures, write script behavior for doors and engine, add it to the server spawn table with pre-attached parts, and test it in-game. By the end, you will have a fully drivable custom Offroad Hatchback variant with modified performance and appearance.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 8.11: Creating Custom Clothing#

Home | « Previous: Creating a Custom Vehicle | Creating Custom Clothing | Next: Building a Trading System »

Summary: This tutorial walks you through creating a custom tactical jacket for DayZ. You will choose a base class, define the clothing in config.cpp with insulation and cargo properties, retexture it with a camo pattern using hidden selections, add localization and spawning, and optionally extend it with scripted behavior. By the end, you will have a wearable jacket that keeps players warm, holds items, and spawns in the world.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 8.12: Building a Trading System#

Home | « Previous: Creating Custom Clothing | Building a Trading System | Next: The Diagnostic Menu »

Summary: Build a complete NPC-less shop system: JSON config, server-validated buy/sell, categorized UI, currency-based transactions. The most complex tutorial in this wiki – covers data modeling, RPC roundtrips, inventory manipulation, and anti-cheat principles.

Table of Contents#

What We Are Building
Step 1: Data Model (3_Game)
Step 2: RPC Constants (3_Game)
Step 3: Server-Side Shop Manager (4_World)
Step 4: Client-Side Shop UI (5_Mission)
Step 5: Layout File
Step 6: Mission Hook and Keybind
Step 7: Currency Item
Step 8: Shop Config JSON
Step 9: Build and Test
Security Considerations
Complete Code Reference
Best Practices / Common Mistakes / What You Learned

What We Are Building#

Players press F6 to open a shop menu, browse items by category (Weapons, Food, Medical), and buy/sell using a currency item. The server validates every transaction – the client never decides prices or spawns items.

Mon, 01 Jan 0001 00:00:00 +0000

Home | « Previous: Building a Trading System | The Diagnostic Menu

Summary: The Diag Menu is DayZ’s built-in diagnostic tool, available only through the DayZDiag executable. It provides FPS counters, script profiling, render debugging, free camera, physics visualization, weather control, Central Economy tools, AI navigation debugging, and sound diagnostics. This chapter documents every menu category, option, and keyboard shortcut based on the official Bohemia Interactive documentation.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 9.1: Server Setup & First Launch#

Home | Server Setup | Next: Directory Structure »

Summary: Install a DayZ Standalone dedicated server from scratch using SteamCMD, launch it with a minimal configuration, verify it appears in the server browser, and connect as a player. This chapter covers everything from hardware requirements to fixing the most common first-launch failures.

Table of Contents#

Prerequisites
Installing SteamCMD
Installing DayZ Server
Directory After Install
First Launch with Minimal Config
Verifying the Server is Running
Connecting as a Player
Common First-Launch Problems

Prerequisites#

Hardware#

Component	Minimum	Recommended
CPU	4 cores, 2.4 GHz	6+ cores, 3.5 GHz
RAM	8 GB	16 GB
Disk	20 GB SSD	40 GB NVMe SSD
Network	10 Mbps upload	50+ Mbps upload
OS	Windows Server 2016 / Ubuntu 20.04	Windows Server 2022 / Ubuntu 22.04

DayZ Server is single-threaded for gameplay logic. Clock speed matters more than core count.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 9.2: Directory Structure & Mission Folder#

Home | « Previous: Server Setup | Directory Structure | Next: serverDZ.cfg Reference »

Summary: A complete walkthrough of every file and folder in the DayZ server directory and the mission folder. Knowing what each file does – and which ones are safe to edit – is essential before touching the loot economy or adding mods.

Table of Contents#

Top-Level Server Directory
The addons/ Folder
The keys/ Folder
The profiles/ Folder
The mpmissions/ Folder
Mission Folder Structure
The db/ Folder – Economy Core
The env/ Folder – Animal Territories
The storage_1/ Folder – Persistence
Top-Level Mission Files
Which Files to Edit vs Leave Alone

Top-Level Server Directory#

DayZServer/
 DayZServer_x64.exe # Server executable
 serverDZ.cfg # Main server config (name, password, mods, time)
 dayzsetting.xml # Rendering settings (irrelevant for dedicated servers)
 ban.txt # Banned Steam64 IDs, one per line
 whitelist.txt # Whitelisted Steam64 IDs, one per line
 steam_appid.txt # Contains "221100" -- do not edit
 dayz.gproj # Workbench project file -- do not edit
 addons/ # Vanilla game PBOs
 battleye/ # Anti-cheat files
 config/ # Steam config (config.vdf)
 dta/ # Core engine PBOs (scripts, GUI, graphics)
 keys/ # Signature verification keys (.bikey files)
 logs/ # Engine-level logs
 mpmissions/ # All mission folders
 profiles/ # Runtime output (script logs, player DB, crash dumps)
 server_manager/ # Server management utilities

The addons/ Folder#

Contains all vanilla game content packed as PBO files. Each PBO has a matching .bisign signature file:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 9.3: serverDZ.cfg Complete Reference#

Home | « Previous: Directory Structure | serverDZ.cfg Reference | Next: Loot Economy Deep Dive »

Summary: Every parameter in serverDZ.cfg documented with its purpose, valid values, and default behavior. This file controls server identity, network settings, gameplay rules, time acceleration, and mission selection.

Table of Contents#

File Format
Server Identity
Network & Security
Gameplay Rules
Time & Weather
Performance & Login Queue
Persistence & Instance
Mission Selection
Complete Example File
Launch Parameters That Override Config

File Format#

serverDZ.cfg uses Bohemia’s config format (similar to C). Rules:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 9.4: Loot Economy Deep Dive#

Home | « Previous: serverDZ.cfg Reference | Loot Economy Deep Dive

Summary: The Central Economy (CE) is the system that controls every item spawn in DayZ – from a can of beans on a shelf to an AKM in a military barracks. This chapter explains the full spawn cycle, documents every field in types.xml, globals.xml, events.xml, and cfgspawnabletypes.xml with real examples from the vanilla server files, and covers the most common economy mistakes.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 9.5: Vehicle & Dynamic Event Spawning#

Home | « Previous: Loot Economy | Next: Player Spawning »

Summary: Vehicles and dynamic events (heli crashes, convoys, police cars) do NOT use types.xml. They use a separate three-file system: events.xml defines what spawns and how many, cfgeventspawns.xml defines where, and cfgeventgroups.xml defines grouped formations. This chapter covers all three files with real vanilla values.

Table of Contents#

How Vehicle Spawning Works
events.xml Vehicle Entries
Vehicle Event Field Reference
cfgeventspawns.xml – Spawn Positions
Heli Crash Events
Military Convoy
Police Car
cfgeventgroups.xml – Grouped Spawns
cfgeconomycore.xml Vehicle Root Class
Common Mistakes

How Vehicle Spawning Works#

Vehicles are not defined in types.xml. If you add a vehicle class to types.xml, it will not spawn. Vehicles use a dedicated three-file pipeline:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 9.6: Player Spawning#

Home | « Previous: Vehicle Spawning | Next: Persistence »

Summary: Player spawn locations are controlled by cfgplayerspawnpoints.xml (position bubbles) and init.c (starting gear). This chapter covers both files with real vanilla values from Chernarus.

Table of Contents#

cfgplayerspawnpoints.xml Overview
Spawn Parameters
Generator Parameters
Group Parameters
Fresh Spawn Bubbles
Hop Spawns
init.c – Starting Equipment
Adding Custom Spawn Points
Common Mistakes

cfgplayerspawnpoints.xml Overview#

This file lives in your mission folder (e.g., dayzOffline.chernarusplus/cfgplayerspawnpoints.xml). It has two sections, each with its own parameters and position bubbles:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 9.7: World State & Persistence#

Home | « Previous: Player Spawning | Next: Performance Tuning »

DayZ persistence keeps the world alive between restarts. Understanding how it works lets you manage bases, plan wipes, and avoid data corruption.

Table of Contents#

How Persistence Works
The storage_1/ Directory
globals.xml Persistence Parameters
Territory Flag System
Hoarder Items
cfggameplay.json Persistence Settings
Server Wipe Procedures
Backup Strategy
Common Mistakes

How Persistence Works#

DayZ stores world state in the storage_1/ directory inside your server profile folder. The cycle is straightforward:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 9.8: Performance Tuning#

Home | « Previous: Persistence | Next: Access Control »

Summary: Server performance in DayZ comes down to three things: item count, dynamic events, and mod/player load. This chapter covers the specific settings that matter, how to diagnose problems, and what hardware actually helps – all based on real community data from 400+ Discord reports of FPS drops, lag, and desync.

Table of Contents#

What Affects Server Performance
globals.xml Tuning
Economy Tuning for Performance
cfgeconomycore.xml Logging
serverDZ.cfg Performance Settings
Mod Performance Impact
Hardware Recommendations
Monitoring Server Health
Common Performance Mistakes

What Affects Server Performance#

From community data (400+ Discord mentions of FPS/performance/lag/desync), the three biggest performance factors are:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 9.9: Access Control#

Home | « Previous: Performance Tuning | Next: Mod Management »

Summary: Configure who can connect to your DayZ server, how bans work, how to enable remote administration, and how mod signature verification keeps unauthorized content out. This chapter covers every access control mechanism available to a server operator.

Table of Contents#

Admin Access via serverDZ.cfg
ban.txt
whitelist.txt
BattlEye Anti-Cheat
RCON (Remote Console)
Signature Verification
The keys/ Directory
In-Game Admin Tools
Common Mistakes

Admin Access via serverDZ.cfg#

The passwordAdmin parameter in serverDZ.cfg sets the admin password for your server:

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 9.10: Mod Management#

Home | « Previous: Access Control | Next: Troubleshooting »

Summary: Install, configure, and maintain third-party mods on a DayZ dedicated server. Covers launch parameters, Workshop downloads, signature keys, load order, server-only vs client-required mods, updates, and the most common mistakes that cause crashes or player kicks.

Table of Contents#

How Mods Load
Launch Parameter Format
Workshop Mod Installation
Mod Keys (.bikey)
Load Order and Dependencies
Server-Only vs Client-Required Mods
Updating Mods
Troubleshooting Mod Conflicts
Common Mistakes

How Mods Load#

DayZ loads mods through the -mod= launch parameter. Each entry is a path to a folder containing PBO files and a config.cpp. The engine reads every PBO in each mod folder, registers its classes and scripts, then continues to the next mod in the list.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 9.11: Server Troubleshooting#

Home | « Previous: Mod Management | Next: Advanced Topics »

Summary: Diagnose and fix the most common DayZ server problems – startup failures, connection issues, crashes, loot and vehicle spawning, persistence, and performance. Every solution here comes from real failure patterns across thousands of community reports.

Table of Contents#

Server Won’t Start
Players Can’t Connect
Crashes and Null Pointers
Loot Not Spawning
Vehicles Not Spawning
Persistence Issues
Performance Problems
Reading Log Files
Quick Diagnostic Checklist

Server Won’t Start#

Missing DLL Files#

If DayZServer_x64.exe crashes immediately with a missing DLL error, install the latest Visual C++ Redistributable for Visual Studio 2019 (x64) from Microsoft’s official site and restart.

Mon, 01 Jan 0001 00:00:00 +0000

Chapter 9.12: Advanced Server Topics#

Home | « Previous: Troubleshooting | Part 9 Home

Summary: Deep configuration files, multi-map setups, economy splitting, animal territories, dynamic events, weather control, automated restarts, and the messages system.

Table of Contents#

cfggameplay.json Deep Dive
Multi-Map Servers
Custom Economy Tuning
cfgenvironment.xml and Animal Territories
Custom Dynamic Events
Server Restart Automation
cfgweather.xml
Messages System

cfggameplay.json Deep Dive#

The file cfggameplay.json lives in your mission folder and overrides hardcoded gameplay defaults. Enable it in serverDZ.cfg first:

Mon, 01 Jan 0001 00:00:00 +0000

Enforce Script Cheat Sheet#

Home | Cheat Sheet

Single-page quick reference for DayZ Enforce Script. Bookmark this.

Types#

Type	Description	Default	Example
`int`	32-bit signed integer	`0`	`int x = 42;`
`float`	32-bit float	`0.0`	`float f = 3.14;`
`bool`	Boolean	`false`	`bool b = true;`
`string`	Immutable value type	`""`	`string s = "hello";`
`vector`	3-component float (x,y,z)	`"0 0 0"`	`vector v = "1 2 3";`
`typename`	Type reference	`null`	`typename t = PlayerBase;`
`Class`	Root of all reference types	`null`	—
`void`	No return	—	—

Limits: int.MAX = 2147483647, int.MIN = -2147483648, float.MAX, float.MIN

Mon, 01 Jan 0001 00:00:00 +0000

Frequently Asked Questions#

Home | FAQ

Getting Started#

Q: What do I need to start modding DayZ?#

A: You need Steam, DayZ (retail copy), DayZ Tools (free on Steam under Tools), and a text editor (VS Code recommended). No programming experience is strictly required — start with Chapter 8.1: Your First Mod . DayZ Tools includes Object Builder, Addon Builder, TexView2, and the Workbench IDE.

Q: What programming language does DayZ use?#

A: DayZ uses Enforce Script, a proprietary language by Bohemia Interactive. It has C-like syntax similar to C#, but with its own rules and limitations (no ternary operator, no try/catch, no lambdas). See Part 1: Enforce Script for a complete language guide.

Mon, 01 Jan 0001 00:00:00 +0000

DayZ Modding Glossary & Page Index#

Home | Glossary & Index

This glossary defines every key term in DayZ modding and links to the chapter where it is explained in depth. Use Ctrl+F to search.

How to Use#

Bold terms are defined inline
[Chapter links] point to the full documentation
See also connects related concepts

A#

Action System#

The system that handles player interactions with items and the world – eating, opening doors, repairing, etc. Actions are registered on items via SetActions() and extend ActionBase.

Mon, 01 Jan 0001 00:00:00 +0000

DayZ Modding Complete Guide – English#

The most comprehensive DayZ modding and server administration documentation available. From zero to published mod, from first server to advanced economy tuning.

Note: This is the English version. For other languages, see the home page .

Mon, 01 Jan 0001 00:00:00 +0000

Troubleshooting Guide#

Home | Troubleshooting Guide

When something goes wrong, start here. This guide is organized by what you see (the symptom), not by system. Find your problem, read the cause, apply the fix.

Table of Contents#

Mod Won’t Load
Script Errors
RPC and Network Issues
UI Problems
Build and PBO Issues
Performance Issues
Item, Vehicle, and Entity Issues
Config and Types Issues
Persistence Issues
Decision Flowcharts
Debug Commands Quick Reference
Log File Locations
Where to Get Help

1. Mod Won’t Load#

These are problems where the mod does not appear, does not activate, or is rejected by the game at startup.

Personal Projects

DayZ - Commie Lobby

DayZ - Commie Lobby#

Connect#

Config UI - Admin Guide

Config UI - Admin Guide#

Mumble

Mumble#

Connect#

How to join#

CryptPad

CryptPad#

Connect#

Accounts & guests#

API

API#

Connect#

Actions#

Chapter 1.1: Variables & Types#

Primitive Types#

Type Hierarchy Diagram#

Type Constants#

Chapter 1.2: Arrays, Maps & Sets#

Introduction#

Chapter 1.3: Classes & Inheritance#

Introduction#

Chapter 1.4: Modded Classes (The Key to DayZ Modding)#

Introduction#

Chapter 1.5: Control Flow#

if / else / else if#

Null checks#

Chapter 1.6: String Operations#

Introduction#

Chapter 1.7: Math & Vector Operations#

Introduction#

Chapter 1.8: Memory Management#

Introduction#

Chapter 1.9: Casting & Reflection#

Table of Contents#

Why Casting Matters#

Chapter 1.10: Enums & Preprocessor#

Table of Contents#

Enum Declaration#

Chapter 1.11: Error Handling#

Table of Contents#

The Fundamental Rule: No try/catch#

Chapter 1.12: What Does NOT Exist (Gotchas)#

Table of Contents#

Complete Gotchas Reference#

1. No Ternary Operator#

Chapter 1.13: Functions & Methods#

Introduction#

Chapter 2.1: The 5-Layer Script Hierarchy#

Table of Contents#

Overview#

Chapter 2.2: config.cpp Deep Dive#

Chapter 2.3: mod.cpp & Workshop#

Table of Contents#

Overview#

Chapter 2.4: Your First Mod – Minimum Viable#

Table of Contents#

What You Need#

The Goal#

Chapter 2.5: File Organization Best Practices#

Table of Contents#

The Canonical Directory Structure#

Chapter 2.6: Server vs Client Architecture#

Chapter 3.1: Widget Types#

How Widgets Work#

Chapter 3.2: Layout File Format (.layout)#

Basic Structure#

Chapter 3.3: Sizing & Positioning#

The Core Concept: Proportional vs. Pixel#

Chapter 3.4: Container Widgets#

Container Comparison#

FrameWidget – Structural Container#

Chapter 3.5: Programmatic Widget Creation#

Two Approaches#

Chapter 3.6: Event Handling#

ScriptedWidgetEventHandler#