mod.cpp & Workshop

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
Worked 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

What Bohemia documents. The Modding Structure page lists ten mod.cpp keys -- name, picture, logoSmall, logo, logoOver, tooltip, overview, action, author, version -- and describes the file as holding "information for mod presentation". The rest of the table above (tooltipOwned, actionURL, authorID, type, extra) is community convention seen in published mods; it does no harm, but do not expect documented behaviour from it. In particular type is documented under CfgMods in a PBO's config.cpp, not here.

Field Details

name

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

cpp

name = "Lantern Core";

You can use string table references for localization:

cpp

name = "$STR_LNT_MOD_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 = "Lantern Core - Admin Panel & Framework";
tooltipOwned = "Lantern Core - Central Admin Panel & Shared Library";

overview

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

cpp

overview = "Lantern Core provides a centralized admin panel and shared library for the Lantern mod family. 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 = 1;
publishedid = 2900000000;            // Steam Workshop item ID
name = "My Mod";                     // Workshop item name
timestamp = 5249975085759540888;     // Internal 64-bit value, NOT a Unix timestamp

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";

Worked Examples

The examples below use the wiki's constructed Lantern mod family (by the fictional team Northlight). Each one demonstrates a different field subset you will encounter in published mods.

Lantern Missions (Development Stage)

A mod still in development: image fields left empty, branding deferred until the code works.

cpp

name = "Lantern Missions";
picture = "";
actionURL = "";
tooltipOwned = "Lantern Missions - Dynamic Mission Framework";
overview = "Lantern Missions adds dynamic, admin-configurable missions on top of Lantern Core.";
author = "Northlight";
version = "0.3.0";

Lantern Missions Server (Minimal Server Mod)

The server half of a split mod. Players never see it in the launcher, so metadata stays minimal.

cpp

name = "Lantern Missions Server";
author = "Northlight";
version = "0.3.0";
extra = 0;
type = "servermod";

Lantern Core (Full-Featured)

A flagship client mod using every presentation field: all four image slots, tooltip, overview, a community link, and author metadata.

cpp

name = "Lantern Core";
picture = "Lantern_Core/GUI/images/lantern_logo_large.edds";
logo = "Lantern_Core/GUI/images/lantern_logo.edds";
logoSmall = "Lantern_Core/GUI/images/lantern_logo_small.edds";
logoOver = "Lantern_Core/GUI/images/lantern_logo_hover.edds";
tooltip = "Lantern Core - Admin Panel & Shared Library";
overview = "Lantern Core provides a centralized admin panel and shared library for the Lantern mod family. Manage configurations, permissions, and mod integration from a single in-game interface.";
action = "https://github.com/northlight/lantern";
author = "Northlight";
authorID = "76561198000000000";
version = "1.2.0";
type = "mod";

Lantern Server Tools (Optional Fields Omitted)

This one deliberately omits name, author, and version to show which fields are truly optional -- everything except the visuals here could be dropped too.

cpp

picture = "Lantern_Admin/data/lantern_admin_logo.edds";
logoSmall = "Lantern_Admin/data/lantern_admin_logo_small.edds";
logo = "Lantern_Admin/data/lantern_admin_logo.edds";
logoOver = "Lantern_Admin/data/lantern_admin_logo.edds";
tooltip = "Tools for administrating your DayZ server";
overview = "Lantern Server Tools bundles moderation and diagnostics utilities for server owners.";
action = "https://discord.gg/northlight";

Note: with name omitted, the mod still works, but the launcher falls back to the folder name (e.g. @Lantern_Admin) as the display text.

Lantern UI Kit (With Localization)

Every text field is a $STR_ stringtable reference, so the launcher listing itself is translated. The keys must exist in the mod's stringtable.csv -- see Stringtable & Localization.

cpp

name = "$STR_LNT_UIKIT_NAME";
picture = "Lantern_UIKit/gui/images/lantern_uikit_logo.edds";
logo = "Lantern_UIKit/gui/images/lantern_uikit_logo.edds";
logoSmall = "Lantern_UIKit/gui/images/lantern_uikit_logo.edds";
logoOver = "Lantern_UIKit/gui/images/lantern_uikit_logo.edds";
tooltip = "$STR_LNT_UIKIT_TOOLTIP";
overview = "$STR_LNT_UIKIT_DESCRIPTION";
action = "https://github.com/northlight/lantern";
author = "$STR_LNT_UIKIT_AUTHOR";
authorID = "76561198000000000";
version = "1.0";

Using $STR_ references for all text fields enables multi-language support for the mod listing itself.

Lantern AI (Script Modules in mod.cpp)

cpp

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

Note: a class Defs block like this does appear in published mods' mod.cpp files, always alongside the same script module paths declared in Scripts/config.cpp under CfgMods (see config.cpp Deep Dive). It has no documented effect there. Bohemia's Modding Structure page describes mod.cpp as an "optional config file, holds information for mod presentation" and lists only presentation keys for it, while placing class defs -- and the script module classes inside it -- under CfgMods in a PBO's config.cpp. Treat a class Defs block in mod.cpp as inert leftover rather than a second valid location, and declare your script modules in config.cpp.

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.

Patterns Observed in Published Mods

Pattern	Detail
Localized `name` field	A `$STR_` stringtable reference in `name` (and `tooltip`/`overview`) makes the launcher listing itself multi-language
Script modules in mod.cpp	Some published mods carry a `class Defs` block with script module paths in `mod.cpp` in addition to the declaration in `config.cpp`'s `CfgMods`. Only the `config.cpp` one is documented; treat the `mod.cpp` copy as inert leftover (see note above)
Missing `name` field	Some mods omit `name` entirely; the launcher falls back to the folder name as display text
All image fields identical	Setting `logo`, `logoSmall`, and `logoOver` to the same `.edds` file is common when only one logo asset exists
Empty image paths	Early-stage mods leave `picture=""` during development and 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.

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 ​

Worked Examples ​

Lantern Missions (Development Stage) ​

Lantern Missions Server (Minimal Server Mod) ​

Lantern Core (Full-Featured) ​

Lantern Server Tools (Optional Fields Omitted) ​

Lantern UI Kit (With Localization) ​

Lantern AI (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 ​

Patterns Observed in Published Mods ​

Theory vs Practice ​

Compatibility & Impact ​