How to use the DayZ Tools Addon Builder to build PBOs

• Where Steam Library
• Why it matters Free official toolset

The Addon Builder lives inside DayZ Tools, a free package on Steam (App 830640). Open Steam, switch the library filter to show Tools, and search for DayZ Tools - if it does not appear, make sure the Tools category is enabled in the drop-down above the search box.

Launch it and let it boot in administrator mode. DayZ Tools is the standard, supported way to get the Addon Builder, so there is no need for any third-party download to follow this guide.

• Where DayZ Tools menu, third item
• Why it matters Opens the packer window

In the DayZ Tools launcher, the tools are listed down the left-hand side. The Addon Builder is the third entry from the top - click it to open the packer.

The main window then appears with all of its fields and checkboxes. It can look busy at first, but every option is covered below in the order you will actually use them.

• Where Top field of the main window
• Why it matters Resolves texture and model paths

The Addon source directory points at the very first folder of your mod structure - the root folder that contains everything you want packed. The builder walks from this folder all the way down, pulling in every file inside it.

Always pack from the P: drive, where you should be doing most of your modding work. The P: drive automatically fills in the correct file paths, so the textures, models and other assets your mod references are resolved at pack time. If you instead point it at something like C:\Program Files\Steam\steamapps\..., the paths bake in a location that nobody else has on their machine and the assets will not load.

• Where Second field
• Why it matters Where the finished PBO lands

The destination directory (or filename ending in .pbo) decides exactly where the packed file is written. You can drop it straight into the folder structure you want - for example your server’s addons folder - by editing this one line.

This is especially handy while testing: change the path here and the builder outputs to wherever you need, with no other setup. You can repoint it any time you pack to a different target.

• Where Prefix and version fields
• Why it matters Overwrites a core or third-party PBO

The Addon prefix lets you overwrite a core PBO or someone else’s PBO entirely. By prefixing your files to match the original, the game loads your version in place of the vanilla one - useful for sweeping vanilla changes, such as redoing every vehicle texture or adding blooded clothing across all the vanilla rvmat files without authoring a separate retexture for each.

Prefixing is a deep topic; the same Arma 3 concept applies here, so it is worth searching the Bohemia wiki and community videos if you want the full detail. The Addon version field next to it is just bookkeeping - 1.0, 2.0 and so on - to keep your releases organised. It does not affect the build.

• Where Checkbox
• Why it matters Safe temporary backup while packing

With Clear temp folder enabled, the builder creates a backup copy of your mod inside a temp folder on the P: drive while it packs. If anything goes wrong mid-build, that copy is a safety net in case your core folder structure somehow gets corrupted.

On a successful pack the temp copy is deleted automatically, while the finished .pbo is written to the destination you set earlier - ready to test, push to Steam, or load on your server.

• Where Checkbox + key path in Options
• Why it matters Required for public and private mods

Signing writes a signature onto your PBO using a private .bikey. This is required for any public - or even private - mod to be usable: the player must place the matching .bikey into the keys folder at the root of their server. Without that key, an unsigned PBO simply will not load into the game.

The checkbox stays greyed out until you point the builder at a private key in the Options window (covered in step 11). Set the key first, and the Sign output PBO option becomes available.

• Where Checkboxes
• Why it matters Lets the engine read your files correctly

Binarize - pronounced “bi-nice” by many modders - converts your models and configs into the engine’s compiled format. It both protects your work (anyone unpacking the mod sees a placeholder block instead of your model in Object Builder) and, more importantly, lets DayZ read your file structure properly. Skipping it is a known cause of strange, hard-to-diagnose bugs.

Binarize all textures does the same for the textures themselves. Enable both for a normal release. The one critical exception is config.cpp, which should never be binarized - that is handled by the files-to-copy list in step 10.

• Where Checkbox
• Why it matters Detailed output for debugging

Enable extended logging makes the builder print a full report of everything it does during a pack - every file synced, used and processed. When a build fails, this detail is what lets you trace the exact file or step that caused the problem.

A failed build throws an error box you have to dismiss. A good run ends with a clear “build successful” message and the full file listing shown below it.

• Where Options window, General tab
• Why it matters Always include *.cpp

Open Options and stay on the General tab. The “files to copy” box holds a comma- or semicolon-separated list of patterns - for example *.emat; - that are copied into the PBO as-is, without being binarized. Each entry is a star (any name), a dot, the extension, then a semicolon to close it.

Always keep *.cpp in this list. If config.cpp is binarized it can break your health system - starting health states may no longer transition correctly to damaged, badly damaged or ruined. The config.cpp controls how items and models are implemented, their damage values and attached textures, so protecting it from binarization is essential.

You should also exclude image set and layout files. If those are binarized they cannot display as icons or ghost images - the faint attachment previews you see for magazines, grenades and similar custom items - so leaving them in the copy list keeps your UI artwork working.

• Where Options → General
• Why it matters Enables signing; swap test keys before release

Still in Options, set Path to the private key to your .bikey file - this is what un-greys the Sign output PBO checkbox from step 7. Click the three dots, browse to your private keys folder, and double-click the key you want to use.

A common workflow is to pack with a dedicated testing key. If you do this, change it back before you publish: signing with a key that does not match the .bikey in the server’s keys folder will cause load problems. The same Options tab also holds the temp folder path, the project folder path (point this at your P: drive), the author field (defaults to your Steam name), and the exclusion pattern list - leave the exclusion file on its default.

The Tools tab next to General just lists the default paths to the underlying tools. There is almost never a reason to touch these; leave “use default” checked unless you have deliberately moved your installation.

• Where Pack button
• Why it matters Produces the loadable PBO

With the source and destination set and your options chosen, click Pack. If a PBO already exists at the destination the builder asks whether to overwrite it - confirm yes - and if none exists it starts packing immediately.

When it finishes you will see “build successful” and the output written to your destination folder. If a build fails, try once more before assuming the mod is broken - the Addon Builder occasionally hiccups, and a clean second attempt often succeeds. From here the .pbo is ready to test, sign, or ship.