DayZ Central Economy configuration reference

By Niko Catarino

Updated 8 October 2026

Use db/types.xml for individual loot entries, db/events.xml for events, db/globals.xml for economy-wide limits and timers, db/economy.xml for entity-group persistence and spawning switches, and cfgeconomycore.xml for root classes, diagnostics and extra economy files. These files belong to the active mission. For the steps to change an item’s abundance, follow the types.xml loot procedure.

The values below come from Bohemia’s Chernarus, Livonia and Sakhal mission files at revision 9a21bb9f5fb9c62a7ce2761402196091588133e6, dated 13 August 2026 and checked on 7 October 2026. They are reference values, not a preset to upload over your server. Compare your installed mission and registered overrides before changing anything.

Make one change you can undo

Find the mission selected by the running instance. For a mission named dayzOffline.chernarusplus, its globals file is mpmissions/dayzOffline.chernarusplus/db/globals.xml. Keep the actual path and filename case, especially on Linux.

Take a stopped backup of the mission, profiles and saved world. Keep the original XML and a note of the setting you intend to change. Use a separate test world for changes to persistence, cleanup or population limits; a configuration rollback cannot recover objects that have already been deleted from a save.

Edit the existing field or register a small override as described below. Parse the XML, restart the test instance and inspect its new logs. Then check the behavior with a player and after a restart. Preserve the live world while diagnosing a result that differs from what you expected.

Read a complete types.xml entry

This is the Canteen entry from the pinned Chernarus types.xml, with line breaks added to make its flags easier to read:

<type name="Canteen">
    <nominal>20</nominal>
    <lifetime>14400</lifetime>
    <restock>0</restock>
    <min>10</min>
    <quantmin>10</quantmin>
    <quantmax>90</quantmax>
    <cost>100</cost>
    <flags count_in_cargo="0"
        count_in_hoarder="0" count_in_map="1"
        count_in_player="0" crafted="0" deloot="0" />
    <category name="food" />
    <usage name="Military" />
    <usage name="Hunting" />
</type>

nominal is the population target; it doesn’t guarantee that many items are available at every moment. min is the lower population setting. Available positions, counting flags and respawn work also affect the result. The Bohemia script API describes lifetime as an idle lifetime in seconds and restock as the delay before a required respawn is allowed. Here, 14400 is four hours. A zero restock removes that delay; it doesn’t promise an immediate replacement in the same position.

Keep the complete flags group when making an override. The example’s counting settings include items on the map and exclude the cargo, hoarder and player counts. Leave crafted and deloot at their supplied values unless you’re deliberately configuring those spawning paths; changing them is not part of filling a canteen or increasing its ordinary loot target.

For items assigned to dynamic-event loot with deloot="1", check the separate per-event allowance as well as the type’s population target.

Compare zero and nonzero restock

Use restock to change the configured wait before a required respawn is allowed. In the example above, 0 adds no wait from this field. A positive value adds a delay: 60 represents sixty seconds. Keep lifetime separate; it controls how long an idle item can remain before deletion.

Bohemia’s linked GetRestock() description establishes that delay, but it doesn’t specify the native queue’s batching algorithm. Don’t read 0 as a promise to fill every missing item at once, or 60 as a guarantee that the item you just picked up returns one minute later. Population counts, eligible positions and the economy’s respawn limits still matter.

To compare intervals, change only this field on a backed-up test mission. Keep the same item target, counting flags and location filters, then record new natural spawns under comparable player activity. Use a connected tester so empty-server idle mode doesn’t invalidate the comparison. Restore the previous interval if the result differs from the supply you intended.

The loot guide explains which direction to change min and restock, using Bohemia’s 1.26 notes on individual-spawn timing and countdowns saved across restarts.

Add an item that has no types entry

The Canteen block above shows a complete item definition. A short override can inherit fields from an existing entry; a new classname needs its own definition. Bohemia’s merge rules make that distinction. Adding a type entry does not create an item class that the game hasn’t loaded.

For an ordinary loose-loot item whose installed package provides no economy file:

1. Confirm the exact classname in that release’s configuration or author documentation. Search the active db/types.xml and every registered types file for an existing entry before creating another.
2. Use the full entry for a comparable item as a starting point, then change its name to the confirmed class. Choose the population, lifetime, restock and quantity values deliberately; copying the Canteen’s fill range onto a tool would not make sense.
3. Keep the complete flags element. Check which inventory contexts you want counted, and retain the appropriate spawning flags for the item. Vehicles, crafted items and event-only loot need their own configuration; don’t turn one of those into ordinary ground loot by copying this example.
4. Select the category and location filters from the active mission’s definitions below. The Canteen has no value or tag elements; those filters are not required in every complete entry. Add them only when you intend to restrict eligible positions that way.
5. Put the completed entry inside a <types> root in a separate mission file, such as custom_ce/new-items.xml. Register that filename with type="types" using the registration procedure, retaining other registrations.
6. Parse the complete file and cfgeconomycore.xml, then upload while the test server is stopped. Check fresh logs, a natural spawn, pickup and persistence after a restart. An admin-spawned item alone doesn’t verify the economy entry.

Keep the original mission and storage for rollback. This is a procedure for constructing and checking a definition; it supplies no verified spawn settings for an unspecified class. If the item needs behavior you cannot establish from its package or author, hold that entry instead of guessing.

Quantity, condition and cost

quantmin and quantmax control the quantity inside each spawned item, where the item supports it. They don’t set the number of items on the map. The Canteen entry uses a range of 10 to 90 percent of capacity. For a test that fills newly spawned canteens, change both values to 100 in that entry or a registered types override. Keep quantmin less than or equal to quantmax.

The script API exposes these quantities as fractions from 0.0 to 1.0. Bohemia’s item creation code chooses a quantity within that range and applies it to supported items or their energy manager. Magazine handling is separate. Check newly CE-spawned examples of the exact class you’re editing; an existing saved item or one created by an admin tool may follow a different path.

Don’t read -1 as an instruction to spawn an empty item. The same stock file uses -1 for both quantity fields on CanOpener and HikingBoots_Black, and the generic item code only applies its CE quantity override when the returned maximum is positive. Preserve negative defaults rather than replacing every occurrence across the file.

For item condition, use the damage globals below or the relevant spawnable-type setup. Filling a canteen doesn’t make it pristine or establish that its liquid is safe to drink.

Bohemia’s GetCost() comment describes priority during respawn and cleanup. It does not define cost as a percentage spawn chance. The stock Canteen value is 100; keep it while tuning abundance through nominal and min. The public script declares a native function, so it doesn’t reveal the queue algorithm or establish which change would make your item spawn sooner.

Category, usage, value and tag filters

The pinned cfglimitsdefinition.xml lists the names available to this mission. Preserve their spelling and case:

Filter	Chernarus names and what to check
category	tools, containers, clothes, lootdispatch, food, weapons, books, explosives. Check which categories the building’s loot containers accept. The Canteen uses food.
usage	Military, Police, Medic, Firefighter, Industrial, Farm, Coast, Town, Village, Hunting, Office, School, Prison, Lunapark, SeasonalEvent, ContaminatedArea, Historical. These select location uses; an item can list several.
value	Tier1, Tier2, Tier3, Tier4, Unique. These are area-value filters. Check the active terrain’s area flags rather than assuming another map’s tier boundaries apply.
tag	floor, shelves, ground. These distinguish placement tags within loot groups.

Scroll to see all columns →

Bohemia’s terrain setup documentation links these limiters to the terrain’s area flags and building loot definitions. mapgroupproto.xml defines loot containers and positions; adding a filter name doesn’t create more positions.

For example, the stock Mag_STANAG_30Rnd entry uses Military, Tier3 and Tier4. To also allow Tier2 while preserving its other settings, a registered type="types" override can contain this complete file:

<?xml version="1.0" encoding="UTF-8"?>
<types>
    <type name="Mag_STANAG_30Rnd">
        <value name="Tier2" />
        <value name="Tier3" />
        <value name="Tier4" />
    </type>
</types>

The value list replaces the old list, so include all three tiers you want. The existing Military usage and population settings stay in place. Check that the test terrain has suitable military loot positions in the added tier, then inspect newly spawned magazines. Use the override registration procedure below with your types filename and type="types".

The supplied cfglimitsdefinitionuser.xml also defines groups such as Tier234 and TownVillage. Those are user-defined groups of flags; keep their definitions with any mission that uses them.

events.xml: check the event type first

An event’s field names alone don’t tell you how it spawns. The pinned events.xml contains these different combinations:

Event	Parent nominal / min / max	limit	Children in the supplied file
VehicleOffroadHatchback	8 / 5 / 11	mixed	Three Ada variants, each with child min="3" and max="5".
StaticHeliCrash	3 / 0 / 0	child	Wreck_UH1Y, with child min="1" and max="3".
AmbientFox	0 / 0 / 25	mixed	Animal_VulpesVulpes, with child min="100" and max="0".

Scroll to see all columns →

These are file values, not interchangeable population presets. In particular, the fox child’s min="100" is a weight, not a request for one hundred foxes. For vehicle population and parts, follow vehicle spawns; for encounters tied to terrain zones, follow animal spawns or infected spawns. Keep the event’s supplied position, limit and flags while changing one supported setting.

Ambient event fields

Bohemia’s ambient spawner reference describes the following behavior for that spawner:

Field	Ambient-event behavior
active	Enables or disables spawning.
Parent max	Caps entities from that event across the map.
distanceradius	A nearby player can activate the zone within this radius.
cleanupradius	The zone remains active while players are within this radius. Nearby entities also have cleanup avoidance.
Child min	Selects the relative weight of each animal type; the weights should total 100.
Territory dmin / dmax	Chooses the zone’s spawn count from the inclusive range.

Scroll to see all columns →

After a zone deactivates, it must finish its cooldown before spawning again. Check both the event’s restock and zoneTouchDisableEditPeriodSec in cfgenvironment.xml. The supplied fox event has max=25, distanceradius=80 and cleanupradius=120. Changing its territory count cannot bypass its map-wide cap. Don’t apply these ambient rules to a car or helicopter-crash event just because the XML contains the same field names.

globals.xml fields

Each <var> has a name, type and value. Bohemia’s configuration reference defines type 0 as an integer, 1 as a float and 2 as a string. Keep the variable’s existing type. In the three pinned missions, only LootDamageMin and LootDamageMax use type 1; all other fields below use 0.

All three missions contain the same 30 globals and values. The tables group them by task so you can find a setting without changing unrelated ones.

Cleanup and item lifetime

Field	Reference value and purpose
CleanupAvoidance	100 metres. Required distance from a player for cleanup deletion.
CleanupLifetimeDeadAnimal	1200 seconds. Dead-animal lifetime.
CleanupLifetimeDeadInfected	330 seconds. Dead-infected lifetime.
CleanupLifetimeDeadPlayer	3600 seconds. Dead-player lifetime.
CleanupLifetimeDefault	45 seconds. Fallback for entities without a specific economy setup whose damage is at least 1.0.
CleanupLifetimeRuined	330 seconds. Ruined-loot lifetime.
CleanupLifetimeLimit	50 items. Maximum deleted together during ordinary cleanup.
FlagRefreshFrequency	432000 seconds, or five days. Interval between flag-driven item-lifetime refreshes.
FlagRefreshMaxDuration	3456000 seconds, or forty days. Duration for which the flag can continue refreshing items.

Scroll to see all columns →

These settings have different jobs from an individual item’s lifetime in types.xml. Increasing a cleanup timer won’t restore a deleted item. A flag also doesn’t establish that every nearby modded object participates in lifetime refresh; check the object and mod’s own rules.

Loot creation and respawning

Field	Reference value and purpose
InitialSpawn	100 percent. Initial loot population when starting without existing storage.
RestartSpawn	0 percent. Additional population toward the nominal target at restart.
SpawnInitial	1200 attempts. Initial item-placement tests allowed.
RespawnAttempt	2 attempts for an individual item’s respawn.
RespawnLimit	20 items of one type spawned together.
RespawnTypes	12 different item types respawned together.
LootProxyPlacement	1, enabled. Allows loot in dispatch containers.
LootSpawnAvoidance	100 metres. Player-distance condition for spawning loot inside a loot group.
LootDamageMin	0.0, float. Lower bound of damage applied to CE-spawned items.
LootDamageMax	0.82, float. Upper bound of damage applied to CE-spawned items.

Scroll to see all columns →

The damage values use a 0–1 scale. They describe damage, not the amount of ammunition, food or liquid in an item. Use the loot guide for quantity, condition and spawn filters.

The wiki’s older defaults list LootSpawnAvoidance as 50 and LootDamageMax as 0. The pinned mission files explicitly use 100 and 0.82. Start from your installed values instead of copying the older table. Raising respawn work limits does not create extra suitable loot positions or prove that the server can handle the added work.

Animals, infected and item updates

Field	Reference value and purpose
AnimalMaxCount	200. Global cap for spawned non-ambient animals.
ZombieMaxCount	1000. Global cap for infected across zones.
ZoneSpawnDist	300 metres. Player distance that activates spawning in a nearby dynamic infected zone.
WorldWetTempUpdate	1, enabled. Updates wetness and temperature on world items.
FoodDecay	1, enabled. Allows food decay; requires WorldWetTempUpdate to be enabled.

Scroll to see all columns →

The caps don’t fill every territory to that number. Use the animal or infected procedure to check the events and zones that request those populations.

Empty-server behavior and connection timers

Field	Reference value and purpose
IdleModeCountdown	60 seconds. Delay before economy idle mode on an empty server.
IdleModeStartup	1, enabled. Allows idle mode at startup. Setting it to 0 does not prevent later idle mode when IdleModeCountdown is nonzero.
TimeHopping	60 seconds. Server-hopping penalty timer.
TimeLogin	15 seconds. Login timer; the wiki documents a maximum of 65536.
TimeLogout	15 seconds. Logout timer; the wiki documents a maximum of 65536.
TimePenalty	20 seconds. Penalty for a player still considered in a play session.

Scroll to see all columns →

Don’t use an empty-server observation as proof of normal occupied-server economy behavior. For a timer change, follow the login/logout procedure and check reconnecting, forced disconnects and any mods that change the process.

economy.xml flags

Bohemia’s terrain-economy reference describes four switches for each entity group: init controls initialization, load reads saved state, respawn allows respawning, and save writes state. 1 enables a switch and 0 disables it. Keep all four attributes when overriding a group.

The three pinned missions use these exact combinations:

Entity group	init / load / respawn / save
dynamic	1 / 1 / 1 / 1
animals	1 / 0 / 1 / 0
zombies	1 / 0 / 1 / 0
vehicles	1 / 1 / 1 / 1
randoms	0 / 0 / 1 / 0
custom	0 / 0 / 0 / 0
building	1 / 1 / 0 / 1
player	1 / 1 / 1 / 1

Scroll to see all columns →

dynamic is the loot group. These switches operate on groups, so they are a poor way to remove one unwanted item or adjust one vehicle event. Use the relevant item or event definition. Keep the supplied randoms, custom and other group settings unless the feature you are configuring explicitly requires a change.

Disabling load or save changes how the group uses persistence. Don’t try those switches on a live world to repair a spelling error or missing loot. A later return to 1 is not a substitute for a verified backup and restore.

cfgeconomycore.xml root classes

The <classes> section identifies the parent classes the economy manages. A <rootclass> entry can use:

• name: the exact parent classname.
• act: character, car or none. Bohemia documents a missing act, or none, as loot handling. Keep the correct character or vehicle handling where required.
• reportMemoryLOD: controls missing-memory-LOD messages. Its documented default is yes; several supplied classes explicitly use no.

The three pinned files contain DefaultWeapon, DefaultMagazine, Inventory_Base, HouseNoDestruct, SurvivorBase, DZ_LightAI, CarScript and BoatScript. The last two use act="car"; SurvivorBase and DZ_LightAI use act="character". Keep these current definitions when an older example shows Car_DZ or omits boats.

Root classes do not replace types.xml entries or install a missing mod. Add a custom root only when the mod’s current instructions require it, retaining the existing classes and attributes.

cfgeconomycore.xml defaults

Values in <defaults> use <default name="..." value="..." />. This format differs from a globals <var> and has no type attribute. Preserve the format belonging to the file you are editing.

Dynamic-event loot allowance

An item’s deloot="1" flag assigns it to dynamic-event loot. If fewer of these items appear at an event than you expected, check both their nominal targets and randomloot_deloot_perevent in cfgeconomycore.xml. In a 24 February 2022 support reply, Bohemia explains that the latter controls the per-event amount and defaults to 2 when omitted. The reply also says that no eligible items are selected from this pool when they have all reached their nominal counts.

To make that documented allowance explicit, add this fragment inside the existing <defaults> block of your test mission’s cfgeconomycore.xml:

<default
    name="randomloot_deloot_perevent"
    value="2" />

If the named entry already exists, edit it instead of adding a duplicate. Keep the other defaults, classes and file registrations. This is a core default, so don’t put it in types.xml or a globals <var> entry. A deliberate test of a different allowance changes this value; keep the item targets and other event settings unchanged for that comparison.

Back up and parse the complete file, upload while stopped, then inspect fresh events and dynamic-event diagnostics. Record the game build, event, eligible item counts and observed loot. Raising the allowance alone doesn’t establish that a particular item will spawn. Restore the saved configuration if the result differs from your intended balance. The setting is documented in that dated support reply; its behavior on the current game build has not been tested here.

Dynamic infected zones

Field	Value in all three pinned missions
dyn_radius	30 metres: fallback zone size.
dyn_smin	0: fallback minimum static count.
dyn_smax	0: fallback maximum static count.
dyn_dmin	1: fallback minimum dynamic count.
dyn_dmax	5: fallback maximum dynamic count.

Scroll to see all columns →

The wiki identifies these as float-valued zone defaults, although the mission files write whole numbers. Its older table lists 20 for dyn_radius and 0 for dyn_dmin. The current mission values shown here differ. Check the actual territory or zone definition before assuming that changing a fallback will change a particular town.

Diagnostics and startup files

Field	Pinned value and purpose
log_ce_loop	false. CE loop diagnostics. The pinned files use this spelling; the older wiki table spells it log_celoop.
log_ce_dynamicevent	false. Dynamic-event diagnostics.
log_ce_vehicle	false. Vehicle diagnostics.
log_ce_lootspawn	false. Loot-creation diagnostics.
log_ce_lootcleanup	false. Cleanup diagnostics, including entities other than loot.
log_ce_lootrespawn	false. Loot-respawn diagnostics.
log_ce_statistics	false. Economy statistics.
log_ce_zombie	false. Infected diagnostics.
log_ce_animal	false in Livonia only. Animal diagnostics; absent from the pinned Chernarus and Sakhal files.
log_storageinfo	false. Periodic storage information.
log_hivewarning	true. Hive warnings.
log_missionfilewarning	true. Mission-file warnings.
save_events_startup	true. Startup creation of data/events.bin.
save_types_startup	true. Startup creation of data/types.bin.

Scroll to see all columns →

Enable only the diagnostics needed for the incident, save the resulting logs and restore the previous settings afterwards. The server-log procedure explains how to identify the active output. Absence of an optional field from one mission is not proof that the engine rejects it, but it also isn’t a reason to copy another terrain’s complete configuration.

Optional persistence-backup settings

The wiki documents the following fields, but none is explicitly set in the three pinned mission files. These are documented engine defaults, not values read from those XML files:

Field	Documented default and purpose
world_segments	12 integer segments for Chernarus. Affects how CE divides saving, loading, cleanup and other processing.
backup_period	60 minutes between persistence backups; documented minimum 15.
backup_count	12 retained backup folders.
backup_startup	false. When enabled, creates a backup after startup loading and initial/additional respawn.

Scroll to see all columns →

If you need an explicit override, place it inside the existing <defaults> block and retain the other entries. For example, this fragment expresses a thirty-minute interval and twelve retained folders:

<default
    name="backup_period"
    value="30" />
<default
    name="backup_count"
    value="12" />

It is a fragment, not a complete replacement for cfgeconomycore.xml. Observe whether the expected backups are created before relying on the setting. Native persistence backups do not establish that mission edits, profiles, mod-owned databases and all other required files are recoverable; keep the broader backup and restore procedure.

Register a small override

Bohemia’s mission-file merge rules allow a <ce> registration inside the existing <economycore> root. folder names a mission-relative directory, file name identifies the XML file and type tells CE how to interpret it.

For example, add this registration alongside the existing classes, defaults and other registrations:

<ce folder="custom_ce">
  <file
    name="login-globals.xml"
    type="globals" />
</ce>

Create custom_ce/login-globals.xml under the active mission with this complete file:

<?xml version="1.0"
    encoding="UTF-8"?>
<variables>
    <var name="TimeLogout"
        type="0" value="30" />
</variables>

This changes the example logout timer without copying every global. Keep the name, type and value attributes together. Check for an existing override of the same variable before adding another, then use the linked timer procedure to verify the result and restore the previous registration and file if needed.

The supported registration types are types, spawnabletypes, globals, economy, events and messages. They don’t all merge the same way:

• A globals entry needs all its attributes and must keep its variable type. An economy-group override needs all four flags.
• Existing types and events can have partial overrides, but grouped flags need complete definitions. Replacing a types usage, tag or value list replaces its previous list.
• Spawnable-type cargo and attachment definitions replace the corresponding previous definitions. A new unique or hoarder flag resets the previous flags; default damage affects new or redefined entries.
• Existing event children remain and can be modified or extended. Messages are appended, so a second message file won’t replace an old announcement.

For item and cargo changes, follow the loot procedure instead of borrowing the globals example’s XML structure.

Check the result and restore the baseline

After a stopped upload and restart, read the fresh logs for XML, mission and registration errors. Test the setting’s actual effect: time a logout, observe an eligible spawn away from players, inspect cleanup after the relevant lifetime, or confirm a backup is created. Record the terrain, game build, mission files, mods, original value and result.

If the result fails, stop the test instance and restore the changed XML and registrations together. If the experiment changed saved data, restore the matching saved-world backup as well. Editing a value back cannot reverse every persistence change.

This reference covers the item examples, ambient-event behavior and global/core settings described above. The precise native cost ordering algorithm, general event-limit modes and mod-specific behavior need separate evidence. Keep unrelated fields at their supplied values while testing a change.

This page used AI-assisted research and drafting on 7 and 8 October 2026. The original nine mission XML files and three Bohemia reference pages were read, followed by the cited item/event entries, limiter definitions, ambient reference and script sections. The configuration and merge pages were last edited in April 2023, and the terrain page in November 2023. File comparison and XML checks do not establish current-game behavior, backup recovery or performance. Those server tests have not been performed here.