How to install and configure Breachingcharge on a DayZ server

By Niko Catarino

Updated 5 October 2026

Load CF and Breachingcharge on the server and joining clients. Add the integration required by your building or lock system, then edit BreachingCharge/breachingcharge.json in the active profiles directory. Before letting players raid, use a disposable base to test the allowed built states and other enabled damage methods.

Select the original Breachingcharge, item 1827241477, published by Handsome Nipple and Deadcraft for Steam PC. The author prohibits repacking, modifying and reuploading its contents; use the original package and its supported configuration. It uses the author’s custom damage system. The listing points to the separate More Explosives project for native-damage integration, so use the chosen package’s own configuration and acceptance procedure. Check the package’s release notes and test it on your game build before enabling raids.

Define the raid policy before installation

Record the allowed objects and built states, the lock/wall destruction rule and the supply of charges. Include other active damage methods and the installed BBP, Expansion and Code Lock revisions in that policy record.

Preserve the mission, saved world, profiles, packages, keys and launch arguments in a stopped recovery copy. Prepare a fresh disposable base on a separate instance. Review its author’s world-wipe requirement if CF is new to the service, keeping the live world intact during rehearsal.

Install the original package and required integrations

Find the original IDs through VXPanel Mods and inspect each dependency and load scope. On a manual host, deploy the package folders and copy their supplied .bikey files into keys. Retain signature verification while extending the client-required argument:

"-mod=@CF;@Breachingcharge"

Match the argument to the deployed folders and preserve the rest of the required load list. Complete the package checks and join with matching client files.

Add Code Lock compatibility

The linked Breachingcharge Codelock Compatibility, item 2464098674 requires Breachingcharge and Code Lock. Its author permits server-side loading. Keep Code Lock and Breachingcharge client-required and extend the server-only argument with the addon:

"-serverMod=@Breachingcharge Codelock Compatibility"

Use the installed binding’s folder name for this example. Inspect the load arguments for duplicate addon entries, then confirm the startup load and exercise the lock interaction.

Add Expansion building compatibility

Use the author-linked Breachingcharge - Expansion Compatibility, item 2854282346 for Expansion BaseBuilding. Preserve the required Expansion building modules and load this integration after its parents in the client-required list. The listing leaves server-only scope unconfirmed; the Code Lock addon’s explicit permission should not be extended to this package.

Retain the current state definitions when adding the integration, then configure the wall/gate policy in the raid file. Test the complete combination with the Code Lock addon too if the installation uses both systems.

Edit the generated profiles configuration

According to the author’s installation instructions, first startup creates BreachingCharge/breachingcharge.json. Run a restricted startup with the intended -profiles path, retain its logs and stop before opening that generated file. Save the baseline and keep the filename unchanged.

Configuration section	Role
Charges	Configure each class’s object/player damage, radius, placement, timings and lock result
Tiers	Assign health to named categories and list the charge classes they accept
DestroyableObjects	Map each allowed built-state key to its tier name

Scroll to see all columns →

Inspect the installed Templates against the author’s version-pinned templates, keeping the fields required by the installed release. Deploy a complete JSON template or edits to the generated file. Json-Explanation.txt contains comments and incomplete example references; use it to understand fields, then apply edits to a complete configuration.

Configure gates, locks and built states

Start a vanilla gate-only review with the author’s gate-only template. It selects Fence_Gate, Fence_Gate_HalfMetal and Fence_Gate_Metal. Retain the referenced tiers and document the intended allowlist before withdrawing other targets. Use the state keys to distinguish built gates sharing the Fence classname.

Select the release’s special target keys when configuring BBP. The listed BBP_BDoor_Frame_Door_T1 describes a construction state; it is not a separate spawn class. Attempt the allowed material/door states and the denied frame/wall states. A custom object’s partial destruction may need script integration beyond its JSON entry.

For every charge, review OnlyDestroyLocks, DestroyLocksFirst and DeleteObjectsDirectly alongside DamageToObjects, tier Health, radius and vertical controls. Record observed charge counts on the disposable targets. Lock-first behavior and multiple affected objects can invalidate an assumption based on a simple health/damage example.

The author’s FAQ traces a charge used as a melee tool to entries in BBP’s raiding-tool list. Configure the explosive policy in Breachingcharge’s file and test the server’s other damage methods too. Review the FAQ’s distinction between vanilla disableBaseDamage and this custom damage system, then confirm the chosen rule with the installed building packages.

Validate tier and charge references on Windows

Run this read-only PowerShell check on a working copy before transferring configuration. It parses the JSON and checks the tier/charge references used by object entries. Substitute the active profiles directory for the example path:

$raidFile = '.\profiles\BreachingCharge\breachingcharge.json'
$raid = Get-Content -LiteralPath $raidFile -Raw -Encoding UTF8 -ErrorAction Stop |
    ConvertFrom-Json -ErrorAction Stop
foreach ($field in @('Charges', 'Tiers', 'DestroyableObjects')) {
    if ($null -eq $raid.$field) { throw "Missing section: $field" }
}
$chargeNames = @($raid.Charges | ForEach-Object { [string]$_.Classname })
$tierNames = @($raid.Tiers | ForEach-Object { [string]$_.Name })
foreach ($names in @(@{ Label = 'charge'; Values = $chargeNames }, @{ Label = 'tier'; Values = $tierNames })) {
    if (@($names.Values | Where-Object { [string]::IsNullOrWhiteSpace($_) }).Count -gt 0) {
        throw "Blank $($names.Label) name"
    }
    if (@($names.Values | Group-Object -CaseSensitive | Where-Object Count -gt 1).Count -gt 0) {
        throw "Repeated $($names.Label) name"
    }
}
foreach ($tier in $raid.Tiers) {
    foreach ($accepted in $tier.AcceptedChargeTypes) {
        if ($chargeNames -cnotcontains [string]$accepted) {
            throw "Tier $($tier.Name) refers to an unconfigured charge: $accepted"
        }
    }
}
foreach ($target in $raid.DestroyableObjects.PSObject.Properties) {
    if ($tierNames -cnotcontains [string]$target.Value) {
        throw "Target $($target.Name) refers to an unknown tier: $($target.Value)"
    }
}
[pscustomobject]@{ Charges = $chargeNames.Count; Tiers = $tierNames.Count; Targets = @($raid.DestroyableObjects.PSObject.Properties).Count }

A successful reference check leaves game-class availability, state keys, damage balance and player access untested. It does not check every required field or numeric value: an invalid DamageToObjects value can pass. Compare those fields with the installed release’s complete template and author documentation too. Use the check to repair broken internal references before startup. Preserve the comparison copy and inspect the new logs after uploading with the service stopped.

Supply loot without copying blank economy values

Decide whether crafting, trader stock or natural loot supplies the charges. Match class names to the installed package and author’s class list. The wiki’s teaching types template leaves population, lifetime and location values blank. Complete your chosen definitions for the active mission using the modded-loot procedure before treating them as deployable economy files.

Test supply and raid permissions as different parts of acceptance. Use admin spawning to examine the charge interaction and natural spawning to inspect mission availability. Reconcile duplicate definitions across the stock and supplemental types files.

Test the complete raid and recovery

Build disposable allowed and denied targets, including a locked object and the material/state combinations in use. Perform the tests as an ordinary player. Record the charge, built state, selected tier, timings and resulting damage.

Check	Observe
Place on allowed and denied states	Attempt both sides of the target allowlist
Arm, defuse and detonate	Compare timing, permitted tools, tool condition and the final object
Lock-only or lock-first policy	Inspect the affected lock and surviving structure
Nearby/stacked targets	Exercise the radius and vertical limits on disposable objects
Other melee, firearms or explosive damage	Verify the full server rule with the other loaded damage systems
Stop/start between required tests	Check saved state and the intended result of a repeat raid
Restore the test recovery set	Compare the recovered disposable base and its contents

Scroll to see all columns →

Enable CreateLogs for the investigation and inspect the raid logs described under the mod’s profiles directory. Save evidence of the first failure and its session before trying another edit. Recover a policy mistake through its saved configuration. If objects were damaged, keep a copy of that failed state and rehearse restoring a compatible world backup.

Source and verification scope

This guide used AI-assisted research and drafting. On 3 October 2026, source checks covered the original Workshop items, integration listings, author wiki and pinned templates. JSON and reference verification used working copies without starting DayZ. Charge damage, script compatibility, player permissions and recovered bases remain untested here; establish those results with your installed packages before enabling live raids.