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.

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.

Key point: mod.cpp is NOT compiled. It is not Enforce Script. It is a simple key-value file read by the launcher. There are no classes, no semicolons after closing braces, no arrays with [] syntax (with one exception for Workshop script modules -- see below).

Where mod.cpp Lives

@MyMod/                       <-- Workshop/launch folder (prefixed with @)
  mod.cpp                     <-- This file
  Addons/
    MyMod_Scripts.pbo
    MyMod_Data.pbo
  Keys/
    MyMod.bikey
  meta.cpp                    <-- Auto-generated by Workshop publisher

The @ prefix on the folder name is convention for Steam Workshop mods but not strictly required.

All Fields Reference

Field	Type	Purpose	Required
`name`	string	Mod display name	Yes
`picture`	string	Large image in expanded description	No
`logo`	string	Logo below the game menu	No
`logoSmall`	string	Small icon next to mod name (collapsed)	No
`logoOver`	string	Logo on mouse hover	No
`tooltip`	string	Tooltip on mouse hover	No
`tooltipOwned`	string	Tooltip when mod is installed	No
`overview`	string	Longer description in mod details	No
`action`	string	URL link (website, Discord, GitHub)	No
`actionURL`	string	Alternative to `action` (same purpose)	No
`author`	string	Author name	No
`authorID`	string	Steam64 ID of the author	No
`version`	string	Version string	No
`type`	string	`"mod"` or `"servermod"`	No
`extra`	int	Reserved field (always 0)	No

Field Details

name

The display name shown in the DayZ launcher mod list and in-game mod screen.

cpp

name = "My Framework";

You can use string table references for localization:

cpp

name = "$STR_DF_NAME";    // Resolves via stringtable.csv

picture

Path to a larger image displayed when the mod description is expanded. Supports .paa, .edds, and .tga formats.

cpp

picture = "MyMod/GUI/images/logo_large.edds";

The path is relative to the mod root. If empty or omitted, no image is shown.

logo

The primary logo displayed below the game menu when the mod is loaded.

cpp

logo = "MyMod/GUI/images/logo.edds";

logoSmall

Small icon shown next to the mod name when the description is collapsed (not expanded).

cpp

logoSmall = "MyMod/GUI/images/logo_small.edds";

logoOver

The logo that appears when the user hovers their mouse over the mod logo. Often the same as logo but can be a highlighted/glowing variant.

cpp

logoOver = "MyMod/GUI/images/logo_hover.edds";

Short text shown when hovering over the mod in the launcher. tooltipOwned is shown when the mod is installed (downloaded from Workshop).

cpp

tooltip = "MyMod Core - Admin Panel & Framework";
tooltipOwned = "My Framework - Central Admin Panel & Shared Library";

overview

A longer description displayed in the mod details panel. This is your "about" text.

cpp

overview = "My Framework provides a centralized admin panel and shared library for all framework mods. Manage configurations, permissions, and mod integration from a single in-game interface.";

action / actionURL

A clickable URL associated with the mod (typically a website, Discord invite, or GitHub repository). Both fields serve the same purpose -- use whichever one you prefer.

cpp

action = "https://github.com/mymod/repo";
// OR
actionURL = "https://discord.gg/mymod";

author / authorID

The author name and their Steam64 ID.

cpp

author = "Documentation Team";
authorID = "76561198000000000";

authorID is used by the Workshop to link to the author's Steam profile.

version

A version string. Can be any format -- the engine does not parse or validate it.

cpp

version = "1.0.0";

Some mods point to a version file in config.cpp instead:

cpp

versionPath = "MyMod/Scripts/Data/Version.hpp";   // This goes in config.cpp, NOT mod.cpp

type

Declares whether this is a regular mod or server-only mod. When omitted, the default is "mod".

cpp

type = "mod";           // Loaded via -mod= (client + server)
type = "servermod";     // Loaded via -servermod= (server only, not sent to clients)

extra

Reserved field. Always set to 0 or omit entirely.

cpp

extra = 0;

Client Mod vs Server Mod

DayZ supports two mod loading mechanisms:

Client Mod (`-mod=`)

Downloaded by clients from Steam Workshop
Scripts run on BOTH client and server
Can include UI, HUD, models, textures, sounds
Requires key signing (.bikey) for server join

// Launch parameter:
-mod=@MyMod

// mod.cpp:
type = "mod";

Server Mod (`-servermod=`)

Runs ONLY on the dedicated server
Clients never download it
Cannot include client-side UI or 5_Mission client code
No key signing required

// Launch parameter:
-servermod=@MyModServer

// mod.cpp:
type = "servermod";

Split Mod Pattern

Many mods ship as TWO packages -- a client mod and a server mod:

@MyMod_Missions/           <-- Client mod (-mod=)
  mod.cpp                   type = "mod"
  Addons/
    MyMod_Missions.pbo     Scripts: UI, entity rendering, RPC receive

@MyMod_MissionsServer/     <-- Server mod (-servermod=)
  mod.cpp                   type = "servermod"
  Addons/
    MyMod_MissionsServer.pbo   Scripts: spawning, logic, state management

This keeps server-side logic private (never sent to clients) and reduces client download size.

Workshop Metadata

meta.cpp (Auto-Generated)

When you publish to Steam Workshop, the DayZ tools auto-generate a meta.cpp file:

cpp

protocol = 2;
publishedid = 2900000000;    // Steam Workshop item ID
timestamp = 1711000000;       // Unix timestamp of last update

Do not edit meta.cpp manually. It is managed by the publishing tools.

Workshop Interaction

The DayZ launcher reads both mod.cpp and meta.cpp:

mod.cpp provides the visual metadata (name, logo, description)
meta.cpp links the local files to the Steam Workshop item
The Steam Workshop page has its own title, description, and images (managed through Steam's web interface)

The mod.cpp fields are what players see in the in-game mod list. The Workshop page is what they see on Steam. Keep them consistent.

Workshop Image Recommendations

Image	Purpose	Recommended Size
`picture`	Expanded mod description	512x512 or similar
`logo`	Menu logo	128x128 to 256x256
`logoSmall`	Collapsed list icon	64x64 to 128x128

Use .edds format for best compatibility. .paa and .tga also work. PNG and JPG do NOT work in mod.cpp image fields.

Required vs Optional Fields

Absolute Minimum

A functional mod.cpp needs only:

cpp

name = "My Mod";

That is it. One line. The mod will load and function. Everything else is cosmetic.

Recommended Minimum

For a Workshop-published mod, include at least:

cpp

name = "My Mod Name";
author = "YourName";
version = "1.0";
overview = "What this mod does in one sentence.";

Full Professional Setup

cpp

name = "My Mod Name";
picture = "MyMod/GUI/images/logo_large.edds";
logo = "MyMod/GUI/images/logo.edds";
logoSmall = "MyMod/GUI/images/logo_small.edds";
logoOver = "MyMod/GUI/images/logo_hover.edds";
tooltip = "Short description";
overview = "Full description of your mod's features.";
action = "https://discord.gg/mymod";
author = "YourName";
authorID = "76561198000000000";
version = "1.2.3";
type = "mod";

Real Examples

Framework Mod (Client Mod)

cpp

name = "My Framework";
picture = "";
actionURL = "";
tooltipOwned = "My Framework - Central Admin Panel & Shared Library";
overview = "My Framework provides a centralized admin panel and shared library for all framework mods. Manage configurations, permissions, and mod integration from a single in-game interface.";
author = "Documentation Team";
version = "1.0.0";

Framework Server Mod (Minimal)

cpp

name = "My Framework Server";
author = "Documentation Team";
version = "1.0.0";
extra = 0;
type = "mod";

Community Framework

cpp

name = "Community Framework";
picture = "JM/CF/GUI/textures/cf_icon.edds";
logo = "JM/CF/GUI/textures/cf_icon.edds";
logoSmall = "JM/CF/GUI/textures/cf_icon.edds";
logoOver = "JM/CF/GUI/textures/cf_icon.edds";
tooltip = "Community Framework";
overview = "This is a Community Framework for DayZ SA. One notable feature is it aims to resolve the issue of conflicting RPC type ID's and mods.";
action = "https://github.com/Arkensor/DayZ-CommunityFramework";
author = "CF Mod Team";
authorID = "76561198103677868";
version = "1.5.8";

VPP Admin Tools

cpp

picture = "VPPAdminTools/data/vpp_logo_m.paa";
logoSmall = "VPPAdminTools/data/vpp_logo_ss.paa";
logo = "VPPAdminTools/data/vpp_logo_s.paa";
logoOver = "VPPAdminTools/data/vpp_logo_s.paa";
tooltip = "Tools helping in administrative DayZ server tasks";
overview = "V++ Admin Tools built for the DayZ community servers!";
action = "https://discord.dayzvpp.com";

Note: VPP omits name and author -- it still works, but the mod name defaults to the folder name in the launcher.

DabsFramework (With Localization)

cpp

name = "$STR_DF_NAME";
picture = "DabsFramework/gui/images/dabs_framework_logo.paa";
logo = "DabsFramework/gui/images/dabs_framework_logo.paa";
logoSmall = "DabsFramework/gui/images/dabs_framework_logo.paa";
logoOver = "DabsFramework/gui/images/dabs_framework_logo.paa";
tooltip = "$STR_DF_TOOLTIP";
overview = "$STR_DF_DESCRIPTION";
action = "https://dab.dev";
author = "$STR_DF_AUTHOR";
authorID = "76561198247958888";
version = "1.0";

DabsFramework uses $STR_ string table references for all text fields, enabling multi-language support for the mod listing itself.

AI Mod (Client Mod with Script Modules in mod.cpp)

cpp

name = "My AI Mod";
picture = "";
actionURL = "";
tooltipOwned = "My AI Mod - Intelligent Bot Framework for DayZ";
overview = "Advanced AI bot framework with human-like perception, combat tactics, and developer API";
author = "YourName";
version = "1.0.0";
type = "mod";
dependencies[] = {"Game", "World", "Mission"};
class Defs
{
    class gameScriptModule
    {
        value = "";
        files[] = {"MyMod_AI/Scripts/3_Game"};
    };
    class worldScriptModule
    {
        value = "";
        files[] = {"MyMod_AI/Scripts/4_World"};
    };
    class missionScriptModule
    {
        value = "";
        files[] = {"MyMod_AI/Scripts/5_Mission"};
    };
};

Note: This mod places script module definitions in mod.cpp rather than config.cpp. Both locations work -- the engine reads both files. However, the standard convention is to put CfgMods and script module definitions in config.cpp. Placing them in mod.cpp is an alternative approach used by some mods.

Tips and Best Practices

1. Keep mod.cpp Simple

mod.cpp is metadata only. Do not try to put game logic, class definitions, or anything complex here. If you need script modules, put them in config.cpp.

2. Use .edds for Images

.edds is the standard DayZ texture format for UI elements. Use DayZ Tools (TexView2) to convert from PNG/TGA to .edds.

3. Match Your Workshop Page

Keep the name, overview, and author fields consistent with your Steam Workshop page. Players see both.

4. Version Consistently

Pick a versioning scheme (e.g., 1.0.0 semantic versioning) and update it with each release. Some mods use a Version.hpp file referenced in config.cpp for centralized version management.

5. Test Without Images First

During development, leave image paths empty. Add logos last, after everything works. Missing images do not prevent the mod from loading.

6. Server Mods Need Less

Server-only mods need minimal mod.cpp since players never see them in a launcher:

cpp

name = "My Server Mod";
author = "YourName";
version = "1.0.0";
type = "servermod";

Best Practices

Always include at least name and author -- even for server mods, it helps identify them in log output and admin tools.
Use .edds format for all image fields (picture, logo, logoSmall, logoOver). PNG and JPG are not supported.
Keep mod.cpp metadata-only. Put CfgMods, script modules, and defines[] in config.cpp instead.
Use semantic versioning (1.2.3) in the version field and update it with every Workshop release.
Test your mod without images first; add logos as a final polish step after functionality is confirmed.

Observed in Real Mods

Pattern	Mod	Detail
Localized `name` field	DabsFramework	Uses `$STR_DF_NAME` stringtable reference for multi-language mod listing
Script modules in mod.cpp	Some AI mods	Place `class Defs` with script module paths directly in mod.cpp instead of config.cpp
Missing `name` field	VPP Admin Tools	Omits `name` entirely; launcher falls back to folder name as display text
All image fields identical	Community Framework	Sets `logo`, `logoSmall`, and `logoOver` to the same `.edds` file
Empty image paths	Many early-stage mods	Leave `picture=""` during development; add branding before Workshop publish

Theory vs Practice

Concept	Theory	Reality
`mod.cpp` is required	Every mod folder needs one	A mod loads fine without it, but the launcher shows no name or metadata
`type` field controls loading	`"mod"` vs `"servermod"`	The launch parameter (`-mod=` vs `-servermod=`) is what actually controls loading; the `type` field is metadata only
Image paths support common formats	All texture formats work	Only `.edds`, `.paa`, and `.tga` work; `.png` and `.jpg` are silently ignored
`authorID` links to Steam	Steam64 ID creates a clickable link	Only works on the Workshop page; the in-game mod list does not render it as a link
`version` is validated	Engine checks version format	The engine treats it as a raw string; `"banana"` is technically valid

Compatibility & Impact

Multi-Mod: mod.cpp has no effect on load order or dependencies. Two mods with identical field values will not conflict -- only CfgPatches class names in config.cpp can collide.
Performance: mod.cpp is read once at startup. Image files referenced here are loaded into memory for the launcher UI but have no in-game performance impact.

Previous: Chapter 2.2: config.cpp Deep DiveNext: Chapter 2.4: Your First Mod -- Minimum Viable

Chapter 2.3: mod.cpp & Workshop ​

Table of Contents ​

Overview ​

Where mod.cpp Lives ​

All Fields Reference ​

Field Details ​

name ​

picture ​

logo ​

logoSmall ​

logoOver ​

tooltip / tooltipOwned ​

overview ​

action / actionURL ​

author / authorID ​

version ​

type ​

extra ​

Client Mod vs Server Mod ​

Client Mod (-mod=) ​

Server Mod (-servermod=) ​

Split Mod Pattern ​

Workshop Metadata ​

meta.cpp (Auto-Generated) ​

Workshop Interaction ​

Workshop Image Recommendations ​

Required vs Optional Fields ​

Absolute Minimum ​

Recommended Minimum ​

Full Professional Setup ​

Real Examples ​

Framework Mod (Client Mod) ​

Framework Server Mod (Minimal) ​

Community Framework ​

VPP Admin Tools ​

DabsFramework (With Localization) ​

AI Mod (Client Mod with Script Modules in mod.cpp) ​

Tips and Best Practices ​

1. Keep mod.cpp Simple ​

2. Use .edds for Images ​

3. Match Your Workshop Page ​

4. Version Consistently ​

5. Test Without Images First ​

6. Server Mods Need Less ​

Best Practices ​

Observed in Real Mods ​

Theory vs Practice ​

Compatibility & Impact ​