DayZ Files Explained

cfgeconomycore.xml starts the CE with root class families and default values before files like events.xml and types.xml are processed.

• Root classes tell CE which broad object families can be scanned, logged, or managed. Examples include survivor, infected/animal, car, and boat roots.
• Defaults are fallback name/value pairs used before more specific economy files override behavior.
• Dynamic event values such as radius and min/max values provide starting values for event placement logic.
• Logging toggles control CE diagnostics such as memory LOD reporting and economy output.

• rootclass name is the parent class family the Central Economy should scan and manage.
• act="character" marks roots that represent spawned characters such as players, infected, or animals.
• act="car" marks moveable vehicle families such as cars and boats.
• reportMemoryLOD="no" tells the export/bootstrap layer not to rely on memory LOD reporting for that root class.
• default name/value pairs are the CE bootstrap defaults that exist before per-file economy data like events.xml and types.xml are applied.

• Areas - Root array of contaminated-zone definitions. Current Chernarus file: 9 areas.
• AreaName - Human label for the zone. Current names include Ship-Bow , Ship-Center , Ship-Stern , Ship-East , Pavlovo-North-Uphill , Pavlovo-South-Building1 , Pavlovo-South-Building2 , Pavlovo-South-Downhill , Pavlovo-West-Uphill .
• Type - Class name spawned for the zone body. Current Chernarus example: ContaminatedArea_Static .
• TriggerType - Trigger class attached to the area. Current Chernarus example: ContaminatedTrigger .
• Data - World-space size, shell, timing, and particle settings for the zone.
• PlayerData - Close-range particles and PPE settings applied while the player is inside the area.
• SafePositions - Root array of 2D fallback points written as [x, z] . Current Chernarus file: 55 points.

• EffectAreaLoader checks $mission:cfgeffectarea.json first and falls back to dz/worlds/<world>/ce/cfgeffectarea.json if the mission file does not exist.
• missionserver.c calls EffectAreaLoader.CreateZones() on mission start, so edits here matter at mission boot rather than through CE restock logic.
• missiongameplay.c also calls EffectAreaLoader.CreateZones() in local developer/single-player startup, so this file also appears outside pure dedicated-server flow.
• If Data.Radius is 0 or lower, the loader rejects the area and logs an error instead of spawning it.
• If Data.Pos[1] is 0 , the loader snaps the area to SurfaceRoadY and creates it with ECE_PLACE_ON_SURFACE .
• If Type does not inherit from EffectArea , the spawn cast fails and the zone never finishes setup.

• AreaName - Used as the zone identifier in logs and warnings. Current example: Ship-Bow .
• Type - Zone class to create. Current example: ContaminatedArea_Static . This must inherit from EffectArea .
• TriggerType - Trigger class passed into the effect-area parameter bundle. Current example: ContaminatedTrigger .
• Data.Pos - Zone origin as [x, y, z] . Current example: [13917, 0, 11178] .
• Data.Radius - Main zone radius in meters. Current Chernarus range: 60 to 100 .
• Data.PosHeight - Height above the origin used by the trigger/effect volume. Current example: 20 .
• Data.NegHeight - Depth below the origin used by the volume. Current example: 3 .

• Data.InnerRingCount - Number of inner shell rings. Accepted by the JSON class even when the current Chernarus file leaves it unset.
• Data.InnerPartDist - Inner particle spacing. Current example: 80 .
• Data.OuterRingToggle - Turns the outer gas shell on or off. Accepted by the loader even though the current Chernarus file does not set it explicitly.
• Data.OuterPartDist - Outer shell particle spacing. Accepted by the loader even when unused in the current file.
• Data.OuterOffset - Pushes the outer shell away from the main radius. Current example: 30 .
• Data.VerticalLayers and Data.VerticalOffset - Add stacked particle layers above the base shell. The local effectarea.c code supports these even though current Chernarus does not use them.
• Data.ParticleName - Main world particle resource. Current example: graphics/particles/contaminated_area_gas_bigass . The loader converts this string into a particle id.
• Data.EffectInterval , Data.EffectDuration , and Data.EffectModifier - Timing and modifier values forwarded into EffectArea . These are accepted by code even when the current Chernarus file leaves them empty.

• PlayerData.AroundPartName - Player-close gas particle. Current example: graphics/particles/contaminated_area_gas_around .
• PlayerData.TinyPartName - Smaller close-range particle. Current example: graphics/particles/contaminated_area_gas_around_tiny .
• PlayerData.PPERequesterType - PPE requester typename for the zone. Current example: PPERequester_ContaminatedAreaTint .
• Blank particle names are allowed. The loader simply skips the particle-id conversion for whichever string is empty.
• SafePositions - 2D points written as [x, z] . Current first point: [434, 13624] .

• OuterRingToggle , VerticalLayers , and VerticalOffset are accepted by shared loader/effect code even though Chernarus does not currently use them.
• EffectInterval , EffectDuration , and EffectModifier are another overlooked set because the loader forwards them straight into the area object.
• PPERequesterType is just a string typename in the JSON, so alternative requester wiring is the sort of thing people tend not to test on console-hosted missions.

Minimal static gas-zone example matching the accepted JSON shape from the local loader classes.

                          {
  "Areas": [
    {
      "AreaName": "MilitaryGasTest",
      "Type": "ContaminatedArea_Static",
      "TriggerType": "ContaminatedTrigger",
      "Data": {
        "Pos": [4500, 0, 9800],
        "Radius": 85,
        "PosHeight": 12,
        "NegHeight": 8,
        "InnerPartDist": 80,
        "OuterOffset": 30,
        "ParticleName": "graphics/particles/contaminated_area_gas_bigass"
      },
      "PlayerData": {
        "AroundPartName": "graphics/particles/contaminated_area_gas_around",
        "TinyPartName": "graphics/particles/contaminated_area_gas_around_tiny",
        "PPERequesterType": "PPERequester_ContaminatedAreaTint"
      }
    }
  ],
  "SafePositions": [
    [4600, 9900],
    [4380, 9670]
  ]
}
                        

cfgenvironment.xml is not the event budget file. It is the registry that points DayZ at territory XML files, then maps those territory files to logical animal, ambient, or infected territory definitions.

• Territory files such as env/wolf_territories.xml , env/bear_territories.xml , and env/zombie_territories.xml describe where a territory exists.
• cfgenvironment.xml tells the CE which territory file belongs to which logical territory type.
• db/events.xml still controls the actual event budget, active state, lifetime, cleanup, children, and secondary event references.

A territory does not replace db/events.xml . If a setup relies on a territory-driven animal, ambient, or infected spawn, the matching event must still exist in db/events.xml as an <event name="..."> block.

• The territory side says where that event type is allowed to be considered.
• The event side says whether that event exists, whether it is active, how many can run, what classnames spawn, how long they live, and how cleanup works.
• If the event name is missing or disabled, adding territory zones alone will not give the CE a usable event budget.

• x and z are the world coordinates of the territory-zone center.
• r is the territory-zone radius in meters.
• smin and smax are the low and high strength values stored for that zone.
• dmin and dmax are the low and high density / count-style values used by the system consuming the territory.
• name is the logical zone name, while color groups zones under the same territory-color block.

This is the important shape: territory files provide the allowed areas, but db/events.xml still needs the actual event entry.

                          <events>
  <event name="AnimalWolf">
    <nominal>5</nominal>
    <min>2</min>
    <max>5</max>
    <lifetime>1800</lifetime>
    <restock>0</restock>
    <saferadius>300</saferadius>
    <distanceradius>1000</distanceradius>
    <cleanupradius>500</cleanupradius>
    <flags deletable="1" init_random="1" remove_damaged="1" />
    <position>player</position>
    <limit>child</limit>
    <active>1</active>
    <children>
      <child type="Animal_CanisLupus" min="1" max="3" lootmin="0" lootmax="0" />
    </children>
  </event>
</events>
                        

Use the event name and child classname that match the spawn you are actually building. The point is the relationship: territory files define allowed areas; events.xml defines the live event.

cfgeventgroups.xml is used when a position in cfgeventspawns.xml has a group="..." attribute. The event position gives the world anchor; the group gives the local layout around that anchor.

• cfgeventspawns.xml controls the world coordinate and heading.
• cfgeventgroups.xml controls the child objects placed relative to that coordinate.
• db/events.xml controls whether the parent event is active, how many can exist, and how long they remain.

                          <eventgroupdef>
  <group name="ExampleConvoyGroup">
    <child type="StaticObj_Misc_Container" x="0.0" y="0.0" z="0.0" a="0.0" lootmin="0" lootmax="3" deloot="0" spawnsecondary="false" />
    <child type="Wreck_HMMWV" x="6.0" y="0.0" z="2.0" a="90.0" lootmin="0" lootmax="0" deloot="0" spawnsecondary="false" />
  </group>
</eventgroupdef>
                        

The group name must match the group="ExampleConvoyGroup" value used on the matching <pos> entry in cfgeventspawns.xml .

A group by itself is only a reusable layout. It will not appear in-game unless a fixed event position references it and a matching <event name="..."> exists in db/events.xml .

cfgeventspawns.xml is the position file for events that need explicit world slots or zones. It does not define the event budget. The event still needs a matching <event name="..."> in db/events.xml .

• Use <pos> entries for exact fixed map positions and headings.
• Use <zone> entries for event-zone style logic where the CE chooses inside a configured area.
• Use group="..." on a <pos> when the position should spawn a layout from cfgeventgroups.xml .

                          <eventposdef>
  <event name="StaticConvoyExample">
    <pos x="7500.0" y="12.5" z="8500.0" a="90.0" group="ExampleConvoyGroup" />
  </event>
</eventposdef>
                        

StaticConvoyExample must also exist in db/events.xml . ExampleConvoyGroup must exist in cfgeventgroups.xml .

                          <eventposdef>
  <event name="StaticHeliCrash">
    <zone smin="1" smax="3" dmin="5" dmax="25" r="50" />
  </event>
</eventposdef>
                        

A <zone> block gives the event a configured area/radius style rule. It still depends on the matching <event name="StaticHeliCrash"> block in db/events.xml for the event budget, lifetime, flags, active state, and children.

• <position>fixed</position> events normally need fixed positions, zones, or another fixed-position source for that event name.
• Territory-driven animal, ambient, or infected setups are different: their allowed areas come from environment territory files, but they still need the matching db/events.xml event.
• If the names do not match across files, the CE cannot connect the event definition to the position, group, or territory setup you intended.

• version - File version marker. Current Chernarus value: 123 .
• GeneralData - Server-wide damage and respawn toggles mirrored from server.cfg when the JSON path is disabled.
• PlayerData - Personal light, map, stamina, movement, drowning, weapon obstruction, and starter-gear hooks.
• WorldsData - Object spawner files, environment overrides, wetness weights, and restricted-area file hooks.
• BaseBuildingData - Hologram and construction validation switches.
• UIData - 3D map and hit-indicator tuning.
• MapData - Ownership checks, player marker display, and nav legend behavior.
• VehicleData - Vehicle-specific tuning currently exposing boatDecayMultiplier .

• CfgGameplayHandler.LoadData() checks $mission:cfggameplay.json first and falls back to dz/worlds/<world>/ce/cfggameplay.json if the mission file is missing.
• server.cfg controls whether this path is even used through enableCfgGameplayFile . If that switch is off, the handler initializes defaults from script and from server.cfg instead of reading JSON.
• After loading, every registered data block is validated. Invalid blocks are reset through their own InitServer() path rather than left half-broken.
• The final CfgGameplayJson object is synced to clients through RPC_CFG_GAMEPLAY_SYNC, letting UI and map settings change client behavior as well as server logic.
• The class comments are explicit: member names must match the JSON keys. Missing keys become default script values or plain 0 / false / [] depending on the field.
• missiongameplay.c , mapmenu.c , playerbase.c , hologram.c , boatscript.c , cfgplayerspawnhandler.c , and cfgplayerrestrictedareahandler.c all consume pieces of this file directly.

• GeneralData.disableBaseDamage - Stops normal damage on base parts. Current Chernarus value: false . If the file is disabled, InitServer() mirrors server.cfg disableBaseDamage .
• GeneralData.disableContainerDamage - Stops damage on world containers. Current Chernarus value: false .
• GeneralData.disableRespawnDialog - Removes the normal respawn dialog. Current Chernarus value: false .
• GeneralData.disableRespawnInUnconsciousness - Blocks respawn while unconscious. Current Chernarus value: false .
• PlayerData.disablePersonalLight - Disables the personal light. Current Chernarus value: false .
• PlayerData.disable2dMap - Accepted by the JSON class and exposed by CfgGameplayHandler . Current Chernarus value: not set in current Chernarus file . No direct Enforce-script consumer is obvious in the local scripts, so this is one of the better engine-side or console-test candidates.
• PlayerData.spawnGearPresetFiles - Array of extra mission JSON files for starter gear. Current Chernarus value: not set in current Chernarus file . cfgplayerspawnhandler.c loads these from $mission: only.

• PlayerData.StaminaData.staminaWeightLimitThreshold - Carry threshold before stamina penalties really bite. Current Chernarus value: 6000.0 .
• PlayerData.StaminaData.staminaMax - Maximum stamina pool. Current Chernarus value: 100.0 . Validation rejects 0 and resets it.
• PlayerData.StaminaData.staminaKgToStaminaPercentPenalty - Weight-to-stamina penalty ratio. Current Chernarus value: 1.75 .
• PlayerData.StaminaData.staminaMinCap - Floor after penalties. Current Chernarus value: 5.0 .
• PlayerData.StaminaData.sprintStaminaModifierErc - Standing sprint drain multiplier. Current Chernarus value: 1.0 .
• PlayerData.StaminaData.sprintStaminaModifierCro - Crouch sprint drain multiplier. Current Chernarus value: 1.0 .
• PlayerData.StaminaData.sprintSwimmingStaminaModifier - Swim sprint drain multiplier. Current Chernarus value: 1.0 .
• PlayerData.StaminaData.sprintLadderStaminaModifier - Fast-climb drain multiplier. Current Chernarus value: 1.0 .
• PlayerData.StaminaData.meleeStaminaModifier - Melee/evasion drain multiplier. Current Chernarus value: 1.0 .
• PlayerData.StaminaData.obstacleTraversalStaminaModifier - Vault and climb drain multiplier. Current Chernarus value: 1.0 .
• PlayerData.StaminaData.holdBreathStaminaModifier - Hold-breath drain multiplier. Current Chernarus value: 1.0 .
• PlayerData.ShockHandlingData.shockRefillSpeedConscious - Shock refill while conscious. Current Chernarus value: 5.0 .
• PlayerData.ShockHandlingData.shockRefillSpeedUnconscious - Shock refill while unconscious. Current Chernarus value: 1.0 .
• PlayerData.ShockHandlingData.allowRefillSpeedModifier - Allows other systems to modify refill speed. Current Chernarus value: true .

• PlayerData.MovementData.timeToStrafeJog - Blend time into jog strafe. Current Chernarus value: 0.1 . The getter clamps it to at least 0.01 .
• PlayerData.MovementData.rotationSpeedJog - Jog rotation speed. Current Chernarus value: 0.3 .
• PlayerData.MovementData.timeToSprint - Blend time into sprint. Current Chernarus value: 0.45 .
• PlayerData.MovementData.timeToStrafeSprint - Blend time into sprint strafe. Current Chernarus value: 0.3 .
• PlayerData.MovementData.rotationSpeedSprint - Sprint rotation speed. Current Chernarus value: 0.15 .
• PlayerData.MovementData.allowStaminaAffectInertia - Lets stamina state affect inertia. Current Chernarus value: true .
• PlayerData.DrowningData.staminaDepletionSpeed - Drowning stamina damage. Current Chernarus value: 10.0 .
• PlayerData.DrowningData.healthDepletionSpeed - Drowning health damage. Current Chernarus value: 10.0 .
• PlayerData.DrowningData.shockDepletionSpeed - Drowning shock damage. Current Chernarus value: 10.0 .
• PlayerData.WeaponObstructionData.staticMode - Static obstruction mode. Current Chernarus value: 1 . Modes are 0=DISABLED , 1=ENABLED , 2=ALWAYS .
• PlayerData.WeaponObstructionData.dynamicMode - Dynamic obstruction mode. Current Chernarus value: 1 . weapon_base.c reads these modes for lift/obstruction behavior.

• WorldsData.lightingConfig - Lighting profile id. Current Chernarus value: 0 . Defaults come from server.cfg lightingConfig when JSON is disabled.
• WorldsData.objectSpawnersArr - Array of mission JSON files loaded by ObjectSpawnerHandler . Current Chernarus value: [] .
• WorldsData.environmentMinTemps - 12 monthly minimum temperatures. Current Chernarus value: [-3, -2, 0, 4, 9, 14, 18, 17, 13, 11, 9, 0] . World scripts only apply it when the array length is exactly 12 .
• WorldsData.environmentMaxTemps - 12 monthly maximum temperatures. Current Chernarus value: [3, 5, 7, 14, 19, 24, 26, 25, 18, 14, 10, 5] .
• WorldsData.wetnessWeightModifiers - Five wetness-to-weight multipliers. Current Chernarus value: [1.0, 1.0, 1.33, 1.66, 2.0] . Validation rejects any count other than 5 .
• WorldsData.playerRestrictedAreaFiles - Array of restricted-area JSON files. Current Chernarus value: not set in current Chernarus file . If absent, cfgplayerrestrictedareahandler.c falls back to the world defaults from GetWorldData().GetDefaultPRAPaths() .

• UIData.use3DMap - Switches into the 3D map path. Current Chernarus value: false . missiongameplay.c and playerbase.c both branch on this when opening the map.
• UIData.HitIndicationData.hitDirectionOverrideEnabled - Enables custom hit-indicator tuning. Current Chernarus value: false .
• UIData.HitIndicationData.hitDirectionBehaviour - Hit-indicator behavior id. Current Chernarus value: 1 .
• UIData.HitIndicationData.hitDirectionStyle - Indicator style id. Current Chernarus value: 0 .
• UIData.HitIndicationData.hitDirectionIndicatorColorStr - Indicator color string. Current Chernarus value: 0xffbb0a1e . CfgGameplayHandler converts it with HexToInt() .
• UIData.HitIndicationData.hitDirectionMaxDuration - Maximum display time. Current Chernarus value: 2.0 .
• UIData.HitIndicationData.hitDirectionBreakPointRelative - Relative breakpoint used by the hit-indicator math. Current Chernarus value: 0.2 .
• UIData.HitIndicationData.hitDirectionScatter - Scatter/variance amount. Current Chernarus value: 10.0 .
• UIData.HitIndicationData.hitIndicationPostProcessEnabled - Enables the old post-process hit effect. Current Chernarus value: true .
• MapData.ignoreMapOwnership - Lets players open the map without carrying a paper map. Current Chernarus value: false . missiongameplay.c uses this together with !GetUse3DMap() for the keyboard map toggle path.
• MapData.ignoreNavItemsOwnership - Lets GPS and compass features work without owning those items. Current Chernarus value: false . mapmenu.c checks this repeatedly when deciding what to show.
• MapData.displayPlayerPosition - Shows the player marker. Current Chernarus value: false . mapmenu.c only uses it when the GPS rules pass.
• MapData.displayNavInfo - Controls the map legend/navigation info. Current Chernarus value: true .
• VehicleData.boatDecayMultiplier - Multiplier for passive boat damage over time. Current Chernarus value: 1 . boatscript.c skips the decay branch entirely when this is 0 or lower.

• BaseBuildingData.HologramData.disableIsCollidingBBoxCheck - Skips hologram bounding-box collision checks. Current Chernarus value: false .
• BaseBuildingData.HologramData.disableIsCollidingPlayerCheck - Skips player collision checks during placement. Current Chernarus value: false .
• BaseBuildingData.HologramData.disableIsClippingRoofCheck - Skips roof clipping checks. Current Chernarus value: false .
• BaseBuildingData.HologramData.disableIsBaseViableCheck - Skips general base-viability checks. Current Chernarus value: false .
• BaseBuildingData.HologramData.disableIsCollidingGPlotCheck - Skips garden plot collision checks. Current Chernarus value: false .
• BaseBuildingData.HologramData.disableIsCollidingAngleCheck - Skips angle-based collision rejection. Current Chernarus value: false .
• BaseBuildingData.HologramData.disableIsPlacementPermittedCheck - Skips generic placement-permitted checks. Current Chernarus value: false .
• BaseBuildingData.HologramData.disableHeightPlacementCheck - Skips height-difference checks. Current Chernarus value: false .
• BaseBuildingData.HologramData.disableIsUnderwaterCheck - Skips underwater placement rejection. Current Chernarus value: false .
• BaseBuildingData.HologramData.disableIsInTerrainCheck - Skips terrain-intersection checks. Current Chernarus value: false . hologram.c reads this directly.
• BaseBuildingData.HologramData.disableColdAreaPlacementCheck - Runtime field name declared in cfggameplaydatajson.c . Current Chernarus value: not set in current Chernarus file .
• BaseBuildingData.HologramData.disableColdAreaBuildingCheck - Legacy key still present in the current Chernarus JSON. Current value: false . The runtime class does not declare this spelling, so treat it as a mismatch, not the safe key to copy.
• BaseBuildingData.HologramData.disallowedTypesInUnderground - Set of classnames blocked from underground placement. Current Chernarus value: ["FenceKit", "TerritoryFlagKit", "WatchtowerKit"] . playerbase.c enforces this in placement logic.
• BaseBuildingData.ConstructionData.disablePerformRoofCheck - Skips roof checks during build actions. Current Chernarus value: false .
• BaseBuildingData.ConstructionData.disableIsCollidingCheck - Skips construction collision checks. Current Chernarus value: false .
• BaseBuildingData.ConstructionData.disableDistanceCheck - Skips construction distance checks. Current Chernarus value: false .

• spawnGearPresetFiles - Array of mission-relative starter-gear preset files. cfgplayerspawnhandler.c loads each file from $mission: , picks weighted presets, and spawns slot and cargo gear from them.
• objectSpawnersArr - Array of mission-relative object spawner files. objectspawner.c loads them from $mission: and spawns every listed row.
• playerRestrictedAreaFiles - Array of restricted-area files. cfgplayerrestrictedareahandler.c loads them, validates shapes, and playerbase.c teleports players out after load if they spawn inside those areas.

• spawnWeight - Weight used when choosing between preset files or discrete item sets. The validation code rejects anything below 1 .
• name - Optional preset name used by GetCharacterPresetByName() and for debugging.
• characterTypes - Allowed survivor classes for that preset. If empty, the normal/default character path is used.
• attachmentSlotItemSets - Per-slot worn or equipped gear definitions.
• slotName - Inventory slot target. shoulderL is remapped to Shoulder and shoulderR is remapped to Melee before validation.
• discreteItemSets - Weighted alternatives for one slot. Each valid row can carry item type, quickbar slot, attributes, and child items.
• itemType - Main classname to spawn. Empty values are tolerated in some slot cases but not for complex child definitions.
• quickBarSlot - Assigned if the item successfully spawns and the player exists.
• attributes - healthMin , healthMax , quantityMin , and quantityMax for the spawned item.
• complexChildrenTypes - Nested child objects with their own attributes and children.
• simpleChildrenTypes - Simple child class list spawned into the parent inventory.
• simpleChildrenUseDefaultAttributes - Keeps child items at their defaults instead of reusing the current attribute block.
• discreteUnsortedItemSets - Weighted loose cargo sets chosen separately from the slot equipment.

Minimal valid preset file shape accepted by the local player gear spawn classes.

                          {
  "spawnWeight": 3,
  "name": "coast_fresh",
  "characterTypes": ["SurvivorM_Mirek", "SurvivorF_Eva"],
  "attachmentSlotItemSets": [
    {
      "slotName": "Body",
      "discreteItemSets": [
        {
          "spawnWeight": 1,
          "itemType": "TShirt_Blue",
          "quickBarSlot": -1,
          "attributes": {
            "healthMin": 0.45,
            "healthMax": 0.75,
            "quantityMin": 0.0,
            "quantityMax": 1.0
          },
          "simpleChildrenTypes": ["BandageDressing"]
        }
      ]
    }
  ],
  "discreteUnsortedItemSets": [
    {
      "spawnWeight": 1,
      "name": "food_roll",
      "attributes": {
        "healthMin": 0.7,
        "healthMax": 1.0,
        "quantityMin": 0.4,
        "quantityMax": 1.0
      },
      "simpleChildrenTypes": ["Apple", "SodaCan_Cola"]
    }
  ]
}
                        

• Objects - Root array of rows to spawn. Every row is passed into SpawnObject() .
• name - Classname or supported .p3d path. If the string contains a slash, objectspawner.c treats it as a model path and only allows its hardcoded whitelist.
• pos - World position written as [x, y, z] .
• ypr - Orientation written as [yaw, pitch, roll] .
• scale - Object scale. If set to 0 , the code silently treats it as 1 .
• enableCEPersistency - If true, the object is spawned without ECE_DYNAMIC_PERSISTENCY and ECE_NOLIFETIME so CE persistence can take over.
• customString - Extra payload consumed by specific classes. staticflagpole.c uses it as a flag classname, while land_warheadstorage_main.c and land_warheadstorage_bunker_facility.c parse undergroundTriggerTag=TAG_NAME entries from it.

This shape is accepted by ObjectSpawnerHandler and shows the underused customString hooks.

                          {
  "Objects": [
    {
      "name": "StaticFlagPole",
      "pos": [3000, 57, 3000],
      "ypr": [0, 0, 0],
      "scale": 1,
      "enableCEPersistency": true,
      "customString": "Flag_Bohemia"
    },
    {
      "name": "Land_WarheadStorage_Main",
      "pos": [4990, 12, 9580],
      "ypr": [0, 0, 0],
      "scale": 1,
      "enableCEPersistency": false,
      "customString": "undergroundTriggerTag=mainEntrance"
    }
  ]
}
                        

• areaName - Optional label that also shows up in teleport/admin log text.
• PRABoxes - 3D restricted boxes written as [sizeXYZ, rotationXYZ, positionXYZ] . Each inner array must contain exactly three numbers.
• PRAPolygons - 2D restricted polygons written as arrays of [x, z] points. Each polygon needs at least three points.
• safePositions2D - 2D safe destinations. The loader converts these to 3D using terrain height.
• safePositions3D - Explicit 3D safe destinations used as-is.

This shape matches the local validation code in CfgPlayerRestrictedAreaJsonData.

                          {
  "areaName": "northwest_safe_gap",
  "PRABoxes": [
    [
      [40, 12, 18],
      [0, 0, 0],
      [4200, 310, 10600]
    ]
  ],
  "PRAPolygons": [
    [
      [4100, 10540],
      [4280, 10540],
      [4320, 10690],
      [4090, 10720]
    ]
  ],
  "safePositions2D": [
    [4370, 10790],
    [4020, 10480]
  ],
  "safePositions3D": [
    [4400, 312, 10830]
  ]
}
                        

• spawnGearPresetFiles , objectSpawnersArr , and playerRestrictedAreaFiles are loaded by shared mission/server scripts with no local console-only exclusion in the local scripts.
• MapData.ignoreMapOwnership , ignoreNavItemsOwnership , displayPlayerPosition , displayNavInfo , and UIData.use3DMap are some of the best console-visible candidates because missiongameplay.c , playerbase.c , and mapmenu.c all consume them.
• PlayerData.disable2dMap is accepted by the JSON class and exposed by the handler but does not show an obvious direct script consumer here. That makes it exactly the sort of field worth testing on console before dismissing it.
• playerRestrictedAreaFiles is easy to miss. The data is loaded and players can be kicked to safe positions after store-load if they spawn inside those areas.
• customString in object spawner JSON is another overlooked hook because it already drives flagpole content and underground-trigger attachment tags in the local scripts.
• boatDecayMultiplier is a simple but real server-visible lever. Setting it to 0 removes the passive boat decay branch in boatscript.c .

This example focuses on fields that the local.c files clearly accept and consume.

                          {
  "version": 123,
  "PlayerData": {
    "spawnGearPresetFiles": [
      "gear/coast_fresh.json"
    ]
  },
  "WorldsData": {
    "objectSpawnersArr": [
      "spawns/static_world.json"
    ],
    "playerRestrictedAreaFiles": [
      "pra/nwaf_blocked.json"
    ],
    "environmentMinTemps": [-5, -3, 0, 4, 8, 13, 17, 16, 11, 7, 3, -1],
    "environmentMaxTemps": [2, 4, 8, 13, 18, 23, 26, 25, 19, 14, 8, 4],
    "wetnessWeightModifiers": [1.0, 1.1, 1.35, 1.7, 2.1]
  },
  "BaseBuildingData": {
    "HologramData": {
      "disableColdAreaPlacementCheck": true,
      "disallowedTypesInUnderground": ["FenceKit", "TerritoryFlagKit"]
    }
  },
  "UIData": {
    "use3DMap": true
  },
  "MapData": {
    "ignoreMapOwnership": true,
    "ignoreNavItemsOwnership": true,
    "displayPlayerPosition": true,
    "displayNavInfo": true
  },
  "VehicleData": {
    "boatDecayMultiplier": 0
  }
}
                        

cfgIgnoreList.xml lists classnames CE should skip when building or checking proxy and loot-support data.

• Use it for objects that exist in game data but should not be treated as spawnable support/proxy candidates.
• Do not use it for normal loot balancing. Use types.xml , categories, usage, values, and events for that.
• Practical check if a classname is ignored here, do not expect CE tooling to treat it like a normal economy target.

This file is the dictionary the Central Economy uses when types.xml says an item belongs to a category, usage area, loot point tag, or value tier. If the name is not defined here or in cfglimitsdefinitionuser.xml the reference is not a useful loot filter.

• category answers what kind of thing the classname is. Base categories here are tools , containers , clothes , lootdispatch , food , weapons , books , and explosives .
• usage answers what area type can receive it. Examples are Military , Police , Medic , Industrial , Farm , Coast , Town , Village , Hunting , Office , School , Prison , SeasonalEvent , ContaminatedArea , and Historical .
• tag answers which loot point style can hold it inside a map group. This file only defines floor , shelves , and ground .
• value answers which tier/value band it belongs to. Base tiers are Tier1 , Tier2 , Tier3 , Tier4 , and Unique .

Example: a rifle with <category name="weapons"/> , <usage name="Military"/> , and <value name="Tier3"/> is not just labelled for humans. Those names tell CE to look for military-compatible weapon spawn points in Tier 3 areas.

• db/types.xml uses these names on each item type so CE knows what the item is and where it is allowed to spawn.
• mapgroupproto.xml and related world-data files describe the loot positions and containers those types can match against.
• category , usage , tag , and value are filters, not notes. Spelling, casing, and whether the name exists matter.
• cfglimitsdefinitionuser.xml can create combined aliases like TownVillage or Tier123 when you want one reusable name to mean multiple base flags.
• EconomyMapStrings.Category(...) and EconomyMapStrings.Tag(...) use the same identifiers for CE debug/map tooling, so these names also affect what you can inspect while testing loot.

cfglimitsdefinitionuser.xml creates reusable aliases that combine multiple base usage or value names from cfglimitsdefinition.xml .

• Usage aliases let one name stand for several areas, such as a combined town/village style rule.
• Value aliases let one tier name cover several value tiers, such as a lower-tier or wide-tier range.
• Where they are used reference them from types.xml with usage user="..." or value user="..." .
• Rule user aliases must still be built from real base names. They are shortcuts, not new free-text spawn zones.

• Each user name is a reusable alias for a longer list of usage or value flags.
• That lets the CE data refer to one combined label instead of repeating the same Town/Village or Tier1/Tier2/Tier3 combinations everywhere.
• This file is additive shorthand for the main vocabulary in cfglimitsdefinition.xml , not a separate loot system.

• fresh controls ordinary fresh-spawn selection.
• hop controls same-map server-hop spawn handling.
• travel controls cross-map travel spawn handling.
• The same child blocks can be used under fresh , hop , and travel .

• spawn_params tells the spawn selector what must be avoided or respected.
• generator_params tells the generator how to search the terrain inside the bubble.
• group_params tells the server how grouped spawn bubbles behave.
• generator_posbubbles contains the actual named position bubbles the generator uses.

                          <playerspawnpoints>
  <fresh>
    <spawn_params>
      <min_dist_static>0</min_dist_static>
      <max_dist_static>500</max_dist_static>
      <min_dist_player>25</min_dist_player>
      <max_dist_player>500</max_dist_player>
      <min_dist_infected>25</min_dist_infected>
      <max_dist_infected>500</max_dist_infected>
      <min_dist_trigger>0</min_dist_trigger>
      <max_dist_trigger>500</max_dist_trigger>
    </spawn_params>
    <generator_params>
      <grid_density>4</grid_density>
      <grid_width>200</grid_width>
      <grid_height>200</grid_height>
      <min_dist_static>0</min_dist_static>
      <max_dist_static>500</max_dist_static>
      <min_steepness>0</min_steepness>
      <max_steepness>45</max_steepness>
    </generator_params>
    <group_params>
      <enablegroups>true</enablegroups>
      <groups_as_regular>false</groups_as_regular>
      <lifetime>3600</lifetime>
      <counter>0</counter>
    </group_params>
    <generator_posbubbles>
      <group name="FreshExample">
        <pos x="7500.0" y="12.5" z="8500.0" />
      </group>
    </generator_posbubbles>
  </fresh>
</playerspawnpoints>
                        

Spawn-point XML is part of the mission startup configuration. Gameplay data is resolved first, then player-spawn related handling uses the loaded spawn-point rules to pick safe candidate positions.

cfgrandompresets.xml defines named random rolls that other files can reuse for cargo and attachment choices.

• Cargo presets fill inventory/cargo with weighted item choices. They are useful for food packs, tool sets, medical rolls, and similar bundles.
• Attachment presets choose attachments for a spawned parent item, such as weapon parts or gear add-ons.
• How they connect files like cfgspawnabletypes.xml can reference preset names instead of repeating the same cargo or attachment list everywhere.
• Spawn chance the item weights inside the preset decide which entry is picked when the preset is used.

• cargo chance or attachments chance is the weight of the whole preset when another file references that preset by name.
• Each nested item chance is the relative weight for the individual item entries inside that preset.
• This file does not decide whether an item exists in the economy. It only decides which contents/attachments are rolled once a spawnable type points at a preset.
• cfgspawnabletypes.xml is the file that consumes these preset names most directly.

cfgspawnabletypes.xml does not decide whether a classname may exist in the economy. That starts in types.xml . This file controls how valid spawned items are rolled after CE chooses them.

• attachments define weighted parts that may spawn on the parent item.
• cargo defines items that may appear inside the parent item.
• damage and quantity set condition or quantity ranges for the spawned result.
• hoarder marks storage-style items that can receive extra cargo behavior.
• presets can pull reusable rolls from cfgrandompresets.xml instead of listing every item inline.

• damage clamps the spawn health/condition range for that item.
• cargo defines cargo content directly or by preset name.
• attachments defines weighted attachments that can be mounted when the item spawns.
• hoarder marks containers that should be treated as persistent storage for economy counting logic.

• Triggers - Root array of underground trigger definitions. Current Chernarus file: 0 rows.
• CustomSpawn - Marks the trigger as parent-driven instead of normal auto-spawn.
• Tag - Identifier used when linking triggers to spawned or map objects.
• ParentNetworkId - Two-int network id pair used for parented trigger lookup.
• Position , Orientation , and Size - Placement and trigger box values.
• EyeAccommodation , InterpolationSpeed , UseLinePointFade , AmbientSoundType , and AmbientSoundSet - Lighting and sound behavior.
• Breadcrumbs - Transition refinement points that control distance fade, raycasts, light lerp, and external controllers.

• UndergroundAreaLoader checks $mission:cfgundergroundtriggers.json first and falls back to dz/worlds/<world>/ce/cfgundergroundtriggers.json if the mission file is missing.
• missionserver.c calls UndergroundAreaLoader.SpawnAllTriggerCarriers() during mission init. missiongameplay.c also does it in the local developer/single-player path.
• Non-custom rows are spawned immediately as trigger carriers. Rows with CustomSpawn=true are skipped until a parent object matches their ParentNetworkId .
• The loader syncs the parsed JSON to clients through RPC_UNDERGROUND_SYNC , then each carrier creates a local UndergroundTrigger child client-side.
• If a trigger has no breadcrumbs, undergroundtrigger.c treats EyeAccommodation == 1.0 as an OUTER trigger and anything else as INNER.
• If a trigger has more than 32 breadcrumbs, UndergroundTrigger.Init() throws an error.

• CustomSpawn - When true, the row is not spawned in the normal pass. It waits for a matching parent object path.
• Tag - Free-form id used by object spawner hooks and manual linking. This is the name compared against undergroundTriggerTag=... values in bunker object customString data.
• ParentNetworkId - Must contain exactly two integers [low, high] for the parented spawn path.
• Position - Carrier origin written as [x, y, z] .
• Orientation - Carrier orientation written as [yaw, pitch, roll] .
• Size - Trigger extents written as [x, y, z] and used to build the carrier box.

• EyeAccommodation - Base eye-accommodation target for the trigger.
• InterpolationSpeed - How quickly the client lerps toward the new accommodation value.
• UseLinePointFade - If true and there are at least two breadcrumbs, undergroundhandlerclient.c uses line-segment fade instead of the weighted breadcrumb path.
• AmbientSoundType - Ambient controller string used by the underground sound path.
• AmbientSoundSet - Optional explicit sound-set override for the ambient loop.

• Breadcrumbs[].Position - Point written as [x, y, z] .
• Breadcrumbs[].EyeAccommodation - Eye-accommodation contribution for that point.
• Breadcrumbs[].UseRaycast - When true, the non-line-point path checks line of sight before using that breadcrumb.
• Breadcrumbs[].Radius - Optional distance cap for that breadcrumb. Use -1 to keep the default behavior.
• Breadcrumbs[].LightLerp - Extra lighting-lerp value used by the line-point path.
• Breadcrumbs[].ExternalValueController.Type - External controller typename. The local scripts ship a DoorState controller.
• Breadcrumbs[].ExternalValueController.Params - String parameters for the external controller. For DoorState , Params[0] is the door selection name checked on the parent building.

This matches the accepted JSON shape from undergroundarealoader.c and the client underground handler.

                          {
  "Triggers": [
    {
      "CustomSpawn": false,
      "Tag": "mainEntrance",
      "Position": [12450, 6, 12570],
      "Orientation": [0, 0, 0],
      "Size": [8, 5, 8],
      "EyeAccommodation": 1.0,
      "InterpolationSpeed": 7.0,
      "UseLinePointFade": true,
      "AmbientSoundType": "Underground",
      "AmbientSoundSet": "Underground_Ambient_SoundSet",
      "Breadcrumbs": [
        {
          "Position": [12448, 6, 12560],
          "EyeAccommodation": 1.0,
          "UseRaycast": false,
          "Radius": -1,
          "LightLerp": true
        },
        {
          "Position": [12448, 2, 12545],
          "EyeAccommodation": 0.15,
          "UseRaycast": false,
          "Radius": -1,
          "LightLerp": true,
          "ExternalValueController": {
            "Type": "DoorState",
            "Params": ["door_1_1"]
          }
        }
      ]
    }
  ]
}
                        

• CustomSpawn plus Tag gives you a way to attach underground trigger carriers to spawned or placed objects without baking everything into the world file.
• undergroundTriggerTag=TAG_NAME in object spawner customString is already parsed by the local bunker building scripts. That is the kind of hook people tend to miss.
• UseLinePointFade , LightLerp , and DoorState are all shared-script features, not something the current Chernarus file uses, so they are strong candidates for console testing if the host accepts this JSON.
• AmbientSoundSet is another underused field because the client handler will explicitly stop and replace the playing sound set when it changes.

• The stock Chernarus file ships with enable="0" and reset="0" .
• That means the world includes a full weather profile, but the standalone file is disabled by default until the server uses it.
• The file still defines all the main controllers: overcast , fog , rain , windMagnitude , windDirection , snowfall plus a dedicated storm block.

• Each weather block uses the same pattern: current for the starting state, limits for absolute bounds, timelimits for how quickly values can change, and changelimits for how large each change can be.
• In the current Chernarus file, rain is gated by overcast thresholds, so heavy rain only becomes eligible once overcast is already high enough.
• The storm block is density=1.0 , threshold=0.9 , and timeout=45 .

• scripts/4_world/classes/worlds/chernarusplus.c contains the world-specific weather logic for Chernarus, including the clear/cloudy/bad-weather cycle and the server-side storm threshold setup.
• ChernarusPlusData.Init() explicitly forces snowfall limits to zero and seeds random starting overcast on multiplayer server start.
• That matters because cfgweather.xml exists, but the Chernarus script logic is still doing its own weather orchestration in code.

• init controls whether that CE channel is initialized on startup.
• load controls whether the channel loads existing persistence/storage data.
• respawn controls whether the channel actively repopulates content.
• save controls whether the channel writes its state back to persistence.
• The current Chernarus file keeps dynamic, vehicles, building, and player data fully active, while animals and zombies respawn without using storage loads/saves.

db/events.xml is the control file for DayZ dynamic events. It does not store every coordinate. It defines the event itself: the name, how many can exist, how long they live, whether the event is active, what children can spawn, and which other files need to match that event name.

• Fixed-position events match to cfgeventspawns.xml by <event name="..."> .
• Grouped fixed events can also match to cfgeventgroups.xml through pos @group .
• Territory-driven animal, ambient, or infected events still need an <event name="..."> block here because territory files only describe allowed areas.

• fixed means the event uses explicit fixed positions, zones, or fixed-position data for that event name. Use it for vehicles, trains, convoys, crash sites, static loot events, and other controlled locations.
• player means the event is evaluated around players / runtime player context instead of only using a fixed coordinate list.
• uniform means the event is distributed by the CE placement mode rather than being tied to one player or a fixed position list.

If you set <position>fixed</position> , make sure the matching event name has usable fixed-position data such as a cfgeventspawns.xml <event name="..."> block.

• child uses child definitions as the main limit source.
• mixed combines event-level and child-level logic.
• custom is for event types with custom handling.
• parent is used when the parent event/budget relationship controls the limit.

Do not invent limit names. The accepted values here are child , mixed , custom , and parent .

• deletable="0" keeps the event from being normally deleted by the event cleanup path; deletable="1" allows normal deletion.
• init_random="0" keeps initialization predictable where the event type supports predictable setup; init_random="1" allows initialization randomisation where the event type supports it.
• remove_damaged="0" allows damaged spawned content to remain until other cleanup rules remove it; remove_damaged="1" allows damaged spawned content to be cleaned up.

secondary is an event-name reference, not a classname. It points at another event the CE can use as supporting content, such as infected around a crash, convoy, bonfire, police, medic, industrial, or military event.

Observed secondary references include InfectedArmy , InfectedMedic , InfectedSanta , InfectedBonfire , InfectedArmyConvoy , InfectedIndustrial , InfectedPoliceHard , and InfectedFirefighter .

                          <events>
  <event name="StaticConvoyExample">
    <nominal>2</nominal>
    <min>1</min>
    <max>2</max>
    <lifetime>3600</lifetime>
    <restock>0</restock>
    <saferadius>500</saferadius>
    <distanceradius>1500</distanceradius>
    <cleanupradius>2000</cleanupradius>
    <secondary>InfectedArmyConvoy</secondary>
    <flags deletable="0" init_random="1" remove_damaged="1" />
    <position>fixed</position>
    <limit>mixed</limit>
    <active>1</active>
    <children>
      <child type="Wreck_HMMWV" min="1" max="1" lootmin="0" lootmax="4" />
    </children>
  </event>
</events>
                        

Because this example uses <position>fixed</position> , it also needs matching position data under <event name="StaticConvoyExample"> in cfgeventspawns.xml .

                          <eventposdef>
  <event name="StaticConvoyExample">
    <pos x="7500.0" y="12.5" z="8500.0" a="90.0" group="ExampleConvoyGroup" />
  </event>
</eventposdef>
                        

The name is the connection. StaticConvoyExample in cfgeventspawns.xml points back to StaticConvoyExample in db/events.xml .

                          <events>
  <event name="AnimalBear">
    <nominal>2</nominal>
    <min>1</min>
    <max>2</max>
    <lifetime>1800</lifetime>
    <restock>0</restock>
    <saferadius>500</saferadius>
    <distanceradius>1000</distanceradius>
    <cleanupradius>500</cleanupradius>
    <flags deletable="1" init_random="1" remove_damaged="1" />
    <position>player</position>
    <limit>child</limit>
    <active>1</active>
    <children>
      <child type="Animal_UrsusArctos" min="1" max="1" lootmin="0" lootmax="0" />
    </children>
  </event>
</events>
                        

The bear territory file can describe where bear territory exists, but this <event name="AnimalBear"> block is still what gives the CE a live event to run.

                          <events>
  <event name="ItemWeaponExample">
    <nominal>10</nominal>
    <min>5</min>
    <max>10</max>
    <lifetime>600</lifetime>
    <restock>0</restock>
    <saferadius>200</saferadius>
    <distanceradius>500</distanceradius>
    <cleanupradius>1500</cleanupradius>
    <flags deletable="1" init_random="0" remove_damaged="1" />
    <position>fixed</position>
    <limit>child</limit>
    <active>1</active>
    <children>
      <child type="AKM" min="1" max="3" lootmin="0" lootmax="0" />
      <child type="M4A1" min="1" max="2" lootmin="0" lootmax="0" />
    </children>
  </event>
</events>
                        

• If it uses fixed positions, the event name must exist in both db/events.xml and cfgeventspawns.xml .
• If a <pos> uses group="..." , that group must exist in cfgeventgroups.xml .
• If it uses territory files, the territory only defines where it can be considered; the matching <event name="..."> still needs to exist and be active in db/events.xml .
• If children are not spawning, check the child classname, child min/max, event min/max, event limit mode, and active value.
• If supporting infected are missing, check that secondary references a real event name, not an item or AI classname.

• deadline is the countdown in seconds before a timed event such as shutdown/restart messaging.
• shutdown marks a message as part of a shutdown chain rather than a normal announcement.
• delay waits before showing a connect-time or repeating message.
• repeat is the repeat interval in minutes for recurring notices.
• onconnect shows the message to joining players, and text is the actual message body with placeholders such as #name and #tmin .

db/messages.xml is optional mission messaging. If a map or template does not ship active messages, the file can still show the format for restart warnings, welcome text, and timed server notices.

• message is one scheduled or triggered notice.
• deadline is the target time/countdown behavior for restart-style warnings.
• shutdown controls whether the message is tied to server shutdown timing.
• text is the message players see. Keep it clear and short enough to read in game.

These examples keep restart-warning and repeated-message patterns beside the db/messages.xml file reference.

                          <message>
  <deadline>180</deadline>
  <shutdown>1</shutdown>
  <text>#name will restart in #tmin minutes</text>
</message>

<message>
  <repeat>5</repeat>
  <onconnect>1</onconnect>
  <text>Join the Discord for updates and support</text>
</message>
                        

• Restart warnings use deadline and shutdown together. Example: <deadline>300</deadline> for 5-minute warnings.
• Rules, promos, and reminders typically use repeat to show periodically throughout the day.
• Server welcome messages use onconnect to greet players when they join.
• Placeholders like #tmin (time in minutes), #name (server name), and #count (player count) are replaced by live values.
• Combine multiple message blocks to create a shutdown sequence with escalating urgency.

Each types.xml row is one class name the central economy can manage. The important parts are the item count, how long it stays alive, how often it restocks, and where it is allowed to spawn.

• Counts - nominal is the target amount, min is the low-water mark, and quantmin/quantmax control starting quantity for things like ammo, food, and liquids.
• Flags - count_in_cargo, count_in_hoarder, count_in_map, and count_in_player decide where existing copies are counted before the economy spawns more.
• Lifetime and restock - lifetime controls cleanup time, restock delays replacement after the item drops below min, and cost is a priority weight used by the economy.
• Placement labels - category, tag, usage, and value must match names defined in cfglimitsdefinition.xml or cfglimitsdefinitionuser.xml.

• nominal is the target world count the CE tries to maintain.
• min is the lower threshold that prompts restocking when counts fall too far.
• lifetime is how long the item can persist before the CE considers it expired.
• restock is the refill timing in seconds once the item becomes eligible to return.
• quantmin and quantmax define spawn fill/condition style ranges for compatible items such as ammo, liquids, and batteries.

• EconomyMapStrings.Category(...) and EconomyMapStrings.Tag(...) exist specifically so CE debug/map tools can filter loot by the same category/tag values used in types.xml and the map-group prototype files.
• EconomyOutputStrings.STATUS and EconomyOutputStrings.WORLD are the CE-side debug outputs that summarize overall world/economy state when you need to validate whether your type counts are behaving.
• That is the practical reason category/tag names matter beyond raw XML structure: the CE tools and debug outputs in centraleconomy.c are built around the same identifiers.

These examples explain the flags that usually cause loot economy confusion: deloot, count_in_map, count_in_player, count_in_hoarder, crafted, and practical item-type patterns.

                          <type name="AK101">
  <nominal>5</nominal>
  <lifetime>21600</lifetime>
  <restock>0</restock>
  <min>2</min>
  <quantmin>40</quantmin>
  <quantmax>100</quantmax>
  <cost>100</cost>
  <flags count_in_cargo="1" count_in_hoarder="1" count_in_map="1" count_in_player="1" crafted="0" deloot="1"/>
  <value name="Tier3"/>
</type>
                        

This example shows a military rifle with deloot="1" (managed by events) configured to spawn with 40-100% condition, maintain a minimum of 2 worldwide, but a desired nominal of 5. The cost of 100 gives it high spawn priority.

When count_in_map="0" , placed items on the ground are not counted when deciding whether more of that item should spawn.

This allows you to keep rare items flowing more predictably, independent of how many are currently lying around.

Example: Set M4A1s to count_in_map="0" to ensure steady spawning even if players hoard items on the ground.

When count_in_player="0" , player inventories do not suppress new spawns for that item.

Useful when you do not want players hoarding items to block the item from respawning in the world.

Example: Set survival tools to count_in_player="0" so players can't prevent their respawn by stockpiling.

When count_in_hoarder="0" , stashes, tents, and similar storage are excluded from that type's total count.

This prevents buried or stored gear from choking the economy and keeping items from spawning.

Example: Set rare items to count_in_hoarder="0" so stored caches don't prevent new spawns.

crafted="1" marks the item as something the game expects to come from crafting/manual creation, not from normal CE loot spawning.

On console, if crafted="1" is enabled on a type, do not expect that type to spawn naturally as regular world loot. Having crafted enabled means it has to be crafted or created by the matching gameplay path.

Tripwires and some crafted/variant items use this pattern: the type can exist in types.xml , but the flag tells the economy it is not normal map loot.

M70_Tundra with count_in_map="0" - Deer rifle that spawns heavily and persists longer; items found on the ground don't suppress respawns:

                          <type name="M70_Tundra">
  <nominal>3</nominal>
  <lifetime>28800</lifetime>
  <restock>0</restock>
  <min>1</min>
  <quantmin>70</quantmin>
  <quantmax>100</quantmax>
  <cost>100</cost>
  <flags count_in_cargo="1" count_in_hoarder="1" count_in_map="0" count_in_player="1" crafted="0" deloot="0"/>
  <category name="weapons"/>
  <usage name="Hunting"/>
  <value name="Tier2"/>
</type>
                        

FNX45 with count_in_player="0" - Rare pistol that ignores player inventory counts, so hoarding doesn't block spawns:

                          <type name="FNX45">
  <nominal>10</nominal>
  <lifetime>10800</lifetime>
  <restock>0</restock>
  <min>5</min>
  <quantmin>20</quantmin>
  <quantmax>80</quantmax>
  <cost>100</cost>
  <flags count_in_cargo="1" count_in_hoarder="1" count_in_map="1" count_in_player="0" crafted="0" deloot="0"/>
  <category name="weapons"/>
  <usage name="Town"/>
  <value name="Tier4"/>
</type>
                        

AliceBag_Green with count_in_hoarder="0" - Military backpack that ignores stored items, so buried caches don't prevent spawns:

                          <type name="AliceBag_Green">
  <nominal>15</nominal>
  <lifetime>43200</lifetime>
  <restock>0</restock>
  <min>8</min>
  <quantmin>-1</quantmin>
  <quantmax>-1</quantmax>
  <cost>50</cost>
  <flags count_in_cargo="1" count_in_hoarder="0" count_in_map="1" count_in_player="1" crafted="0" deloot="0"/>
  <category name="containers"/>
  <usage name="Military"/>
  <value name="Tier4"/>
</type>
                        

SawedoffMosin9130_Black with crafted="1" - Example of a crafted-only variant. With crafted="1" enabled, this is not regular natural loot. It should come from the crafting path or another explicit spawn path, not ordinary map spawning.

                          <type name="SawedoffMosin9130_Black">
  <nominal>0</nominal>
  <lifetime>3</lifetime>
  <restock>0</restock>
  <min>0</min>
  <quantmin>-1</quantmin>
  <quantmax>-1</quantmax>
  <cost>100</cost>
  <flags count_in_cargo="1" count_in_hoarder="1" count_in_map="1" count_in_player="1" crafted="1" deloot="0"/>
  <category name="weapons"/>
  <usage name="Farming"/>
  <value name="Tier1"/>
</type>
                        

Add the file path to WorldsData.objectSpawnersArr in cfggameplay.json . The mission file should sit at dayzOffline.{map}/custom/objectSpawner.json .

                          {
  "WorldsData": {
    "objectSpawnersArr": ["custom/objectSpawner.json"]
  }
}
                        

• Objects - Objects is the root array. Each entry is one object row.
• name - Class name to spawn, or a supported .p3d path from the hard-coded DZ/plants* or DZ/rocks* folders.
• pos - World position as [x, y, z] .
• ypr - Rotation as [yaw, pitch, roll] in degrees.
• scale - Scale multiplier. Missing or 0 is treated as 1 .
• enableCEPersistency - When true, the object keeps normal CE persistency instead of being forced as a no-lifetime dynamic spawn.
• customString - Extra text passed to spawned objects. Useful live hooks include flagpole content and undergroundTriggerTag=... for bunker/underground trigger linking.

                          {
  "Objects": [
    {
      "name": "StaticFlagPole",
      "pos": [3000, 57, 3000],
      "ypr": [0, 0, 0],
      "scale": 1,
      "enableCEPersistency": true,
      "customString": "Flag_Bohemia"
    },
    {
      "name": "Land_WarheadStorage_Main",
      "pos": [4990, 12, 9580],
      "ypr": [0, 0, 0],
      "scale": 1,
      "enableCEPersistency": false,
      "customString": "undergroundTriggerTag=mainEntrance"
    }
  ]
}
                        

Add the file path to WorldsData.playerRestrictedAreaFiles in cfggameplay.json . The file itself belongs at dayzOffline.{map}/custom/playerRestrictedArea.json .

                          {
  "WorldsData": {
    "playerRestrictedAreaFiles": ["custom/playerRestrictedArea.json"]
  }
}
                        

• areaName - Optional name used to identify the area while testing or debugging.
• PRABoxes - 3D box volumes. Each box is [sizeXYZ, rotationXYZ, positionXYZ] . Use this for rectangular building, bunker, or base zones.
• PRAPolygons - 2D polygon volumes. Each polygon contains at least three [x, z] points. Use this for irregular map shapes.
• safePositions2D - Safe destinations as [x, z] . Runtime fills in terrain height.
• safePositions3D - Safe destinations as [x, y, z] when you need exact height control.

                          {
  "areaName": "north_bunker_exit",
  "PRABoxes": [
    [[30, 12, 40], [0, 0, 0], [4990, 12, 9580]]
  ],
  "PRAPolygons": [
    [[4960, 9550], [5020, 9550], [5035, 9610], [4970, 9630]]
  ],
  "safePositions2D": [
    [4920, 9500],
    [5075, 9650]
  ],
  "safePositions3D": [
    [4920, 68, 9500]
  ]
}
                        

Add the file path to PlayerData.spawnGearPresetFiles in cfggameplay.json . The preset file should sit at dayzOffline.{map}/custom/playerSpawnGear.json .

                          {
  "PlayerData": {
    "spawnGearPresetFiles": ["custom/playerSpawnGear.json"]
  }
}
                        

• spawnWeight - Preset selection weight. Higher numbers make this preset more likely when several preset files are listed.
• name - Preset name. Any readable label is fine.
• characterTypes - Allowed survivor class names for this preset, such as SurvivorM_Mirek or SurvivorF_Eva .
• attachmentSlotItemSets - Gear placed into character slots. Each slot uses slotName plus weighted discreteItemSets .
• slotName - The target character slot: Body , Legs , Feet , shoulderL , shoulderR , Vest , Back or Eyewear .
• discreteUnsortedItemSets - Loose cargo choices placed into available inventory space.
• itemType - Class name to spawn.
• quickBarSlot - Quickbar slot number, or -1 to leave it unassigned.
• attributes - Randomized item condition and quantity using healthMin , healthMax , quantityMin , and quantityMax .
• simpleChildrenTypes - Plain child items under the parent item.
• complexChildrenTypes - Child items with their own attributes, quickbar slot, and children.
• simpleChildrenUseDefaultAttributes - Controls whether simple children inherit default attributes instead of custom values.

                          {
  "spawnWeight": 3,
  "name": "coast_fresh",
  "characterTypes": ["SurvivorM_Mirek", "SurvivorF_Eva"],
  "attachmentSlotItemSets": [
    {
      "slotName": "Body",
      "discreteItemSets": [
        {
          "spawnWeight": 1,
          "itemType": "TShirt_Blue",
          "quickBarSlot": -1,
          "attributes": {
            "healthMin": 0.45,
            "healthMax": 0.75,
            "quantityMin": 0.0,
            "quantityMax": 1.0
          },
          "simpleChildrenTypes": ["BandageDressing"]
        }
      ]
    }
  ],
  "discreteUnsortedItemSets": [
    {
      "spawnWeight": 1,
      "name": "food_roll",
      "attributes": {
        "healthMin": 0.7,
        "healthMax": 1.0,
        "quantityMin": 0.4,
        "quantityMax": 1.0
      },
      "simpleChildrenTypes": ["Apple", "SodaCan_Cola"]
    }
  ]
}
                        

• This file contains 13 territory color groups and 71 zone entries.
• Zone names in this file include Graze .
• Zone radius ranges from 100 to 300 meters.
• Density values range from dmin=0 up to dmax=0 .
• Territory color markers in this file include 4294923520 , 4294923520 , 4294923520 , 4294923520 , 4294923520 , 4294923520 ,....

• x and z are the world coordinates of the zone center.
• r is the zone radius in meters.
• smin and smax are the low/high strength values stored for that zone definition.
• dmin and dmax are the low/high density or count-style values used by the system consuming this territory.
• name is the logical territory type, while color groups zones under the same territory-color block.
• These files only define zone geometry and zone numbers. The behavior assigned to those zones is registered separately in cfgenvironment.xml .

• This file contains 39 territory color groups and 215 zone entries.
• Zone names in this file include Graze , Rest , Water .
• Zone radius ranges from 50 to 200 meters.
• Density values range from dmin=0 up to dmax=0 .
• Territory color markers in this file include 864420070 , 864420070 , 864420070 , 864420070 , 864420070 , 864420070 ,....

• x and z are the world coordinates of the zone center.
• r is the zone radius in meters.
• smin and smax are the low/high strength values stored for that zone definition.
• dmin and dmax are the low/high density or count-style values used by the system consuming this territory.
• name is the logical territory type, while color groups zones under the same territory-color block.
• These files only define zone geometry and zone numbers. The behavior assigned to those zones is registered separately in cfgenvironment.xml .

• This file contains 39 territory color groups and 215 zone entries.
• Zone names in this file include Graze , Rest , Water .
• Zone radius ranges from 50 to 200 meters.
• Density values range from dmin=0 up to dmax=0 .
• Territory color markers in this file include 864420070 , 864420070 , 864420070 , 831654630 , 864420070 , 864420070 ,....

• x and z are the world coordinates of the zone center.
• r is the zone radius in meters.
• smin and smax are the low/high strength values stored for that zone definition.
• dmin and dmax are the low/high density or count-style values used by the system consuming this territory.
• name is the logical territory type, while color groups zones under the same territory-color block.
• These files only define zone geometry and zone numbers. The behavior assigned to those zones is registered separately in cfgenvironment.xml .

• This file contains 1 territory color groups and 384 zone entries.
• Zone names in this file include Zone_fox .
• Zone radius ranges from 50 to 50 meters.
• Density values range from dmin=0 up to dmax=2 .
• Territory color markers in this file include 4294945280 .

• x and z are the world coordinates of the zone center.
• r is the zone radius in meters.
• smin and smax are the low/high strength values stored for that zone definition.
• dmin and dmax are the low/high density or count-style values used by the system consuming this territory.
• name is the logical territory type, while color groups zones under the same territory-color block.
• These files only define zone geometry and zone numbers. The behavior assigned to those zones is registered separately in cfgenvironment.xml .

• This file contains 1 territory color groups and 882 zone entries.
• Zone names in this file include Zone_Hare .
• Zone radius ranges from 50 to 50 meters.
• Density values range from dmin=0 up to dmax=2 .
• Territory color markers in this file include 4289352960 .

• x and z are the world coordinates of the zone center.
• r is the zone radius in meters.
• smin and smax are the low/high strength values stored for that zone definition.
• dmin and dmax are the low/high density or count-style values used by the system consuming this territory.
• name is the logical territory type, while color groups zones under the same territory-color block.
• These files only define zone geometry and zone numbers. The behavior assigned to those zones is registered separately in cfgenvironment.xml .

• This file contains 127 territory color groups and 355 zone entries.
• Zone names in this file include Zone_hen .
• Zone radius ranges from 75 to 150 meters.
• Density values range from dmin=0 up to dmax=2 .
• Territory color markers in this file include 3556750600 , 3556750600 , 3556750600 , 3556750600 , 3556750600 , 3556750600 ,....

• x and z are the world coordinates of the zone center.
• r is the zone radius in meters.
• smin and smax are the low/high strength values stored for that zone definition.
• dmin and dmax are the low/high density or count-style values used by the system consuming this territory.
• name is the logical territory type, while color groups zones under the same territory-color block.
• These files only define zone geometry and zone numbers. The behavior assigned to those zones is registered separately in cfgenvironment.xml .

• This file contains 30 territory color groups and 182 zone entries.
• Zone names in this file include Graze , Rest , Water .
• Zone radius ranges from 50 to 100 meters.
• Density values range from dmin=0 up to dmax=0 .
• Territory color markers in this file include 872381884 , 872381884 , 872381884 , 872381884 , 872381884 , 872381884 ,....

• x and z are the world coordinates of the zone center.
• r is the zone radius in meters.
• smin and smax are the low/high strength values stored for that zone definition.
• dmin and dmax are the low/high density or count-style values used by the system consuming this territory.
• name is the logical territory type, while color groups zones under the same territory-color block.
• These files only define zone geometry and zone numbers. The behavior assigned to those zones is registered separately in cfgenvironment.xml .

• This file contains 35 territory color groups and 255 zone entries.
• Zone names in this file include Graze , Rest , Water .
• Zone radius ranges from 50 to 165 meters.
• Density values range from dmin=0 up to dmax=0 .
• Territory color markers in this file include 856817408 , 856817408 , 856817408 , 856817408 , 856817408 , 856817408 ,....

• x and z are the world coordinates of the zone center.
• r is the zone radius in meters.
• smin and smax are the low/high strength values stored for that zone definition.
• dmin and dmax are the low/high density or count-style values used by the system consuming this territory.
• name is the logical territory type, while color groups zones under the same territory-color block.
• These files only define zone geometry and zone numbers. The behavior assigned to those zones is registered separately in cfgenvironment.xml .

• This file contains 40 territory color groups and 276 zone entries.
• Zone names in this file include Graze , Rest , Water .
• Zone radius ranges from 50 to 195 meters.
• Density values range from dmin=0 up to dmax=0 .
• Territory color markers in this file include 1090576876 , 1090576876 , 1090576876 , 1090576876 , 1090576876 , 1090576876 ,....

• x and z are the world coordinates of the zone center.
• r is the zone radius in meters.
• smin and smax are the low/high strength values stored for that zone definition.
• dmin and dmax are the low/high density or count-style values used by the system consuming this territory.
• name is the logical territory type, while color groups zones under the same territory-color block.
• These files only define zone geometry and zone numbers. The behavior assigned to those zones is registered separately in cfgenvironment.xml .

• This file contains 31 territory color groups and 151 zone entries.
• Zone names in this file include Graze , Rest .
• Zone radius ranges from 50 to 150 meters.
• Density values range from dmin=0 up to dmax=0 .
• Territory color markers in this file include 872412928 , 872412928 , 872412928 , 872412928 , 872412928 , 872412928 ,....

• x and z are the world coordinates of the zone center.
• r is the zone radius in meters.
• smin and smax are the low/high strength values stored for that zone definition.
• dmin and dmax are the low/high density or count-style values used by the system consuming this territory.
• name is the logical territory type, while color groups zones under the same territory-color block.
• These files only define zone geometry and zone numbers. The behavior assigned to those zones is registered separately in cfgenvironment.xml .

• This file contains 30 territory color groups and 207 zone entries.
• Zone names in this file include Graze , Rest , Water .
• Zone radius ranges from 50 to 200 meters.
• Density values range from dmin=0 up to dmax=0 .
• Territory color markers in this file include 2841534046 , 2841534046 , 822083584 , 2841534046 , 2841534046 , 2841534046 ,....

• x and z are the world coordinates of the zone center.
• r is the zone radius in meters.
• smin and smax are the low/high strength values stored for that zone definition.
• dmin and dmax are the low/high density or count-style values used by the system consuming this territory.
• name is the logical territory type, while color groups zones under the same territory-color block.
• These files only define zone geometry and zone numbers. The behavior assigned to those zones is registered separately in cfgenvironment.xml .

• This file contains 24 territory color groups and 276 zone entries.
• Zone names in this file include HuntingGround , Rest , Water .
• Zone radius ranges from 45 to 300 meters.
• Density values range from dmin=0 up to dmax=0 .
• Territory color markers in this file include 4291611852 , 4291611852 , 4291611852 , 4291611852 , 4291611852 , 4291611852 ,....

• x and z are the world coordinates of the zone center.
• r is the zone radius in meters.
• smin and smax are the low/high strength values stored for that zone definition.
• dmin and dmax are the low/high density or count-style values used by the system consuming this territory.
• name is the logical territory type, while color groups zones under the same territory-color block.
• These files only define zone geometry and zone numbers. The behavior assigned to those zones is registered separately in cfgenvironment.xml .

• This file contains 18 territory color groups and 768 zone entries.
• Zone names in this file include InfectedVillage , InfectedSolitude , InfectedCityTier1 , InfectedVillageTier1 , InfectedIndustrial , InfectedCity , InfectedReligious , InfectedArmy .
• Zone radius ranges from 50 to 160 meters.
• Density values range from dmin=1 up to dmax=20 .
• Territory color markers in this file include 2193199729 , 3082523903 , 2615190015 , 3014176010 , 1129709567 , 2575065676 ,....

• x and z are the world coordinates of the zone center.
• r is the zone radius in meters.
• smin and smax are the low/high strength values stored for that zone definition.
• dmin and dmax are the low/high density or count-style values used by the system consuming this territory.
• name is the logical territory type, while color groups zones under the same territory-color block.
• These files only define zone geometry and zone numbers. The behavior assigned to those zones is registered separately in cfgenvironment.xml .

mapclusterproto.xml maps named vegetation/object cluster prototypes to export shapes and trajectory groups used by map placement data.

• export gives a friendly name to a world model or shape path.
• cluster defines a reusable cluster prototype.
• de entries connect the cluster to export/trajectory groups such as trees, bushes, stumps, branches, or stones.
• Why it matters the placement files can then place the named cluster without repeating the full prototype definition each time.

• export maps a friendly name to a world model shape path.
• cluster name is the prototype identifier used later by cluster placement data.
• de entries bind the cluster to exported trajectory groups such as apple, pear, plum, coniferous, or branch-style harvest routes.
• container and point blocks work the same way as map-group prototypes, but for cluster exports instead of building groups.

• CEApi.ExportClusterData() is the CE export hook that generates the cluster placement export chain.
• CEApi.ExportProxyProto() and ExportProxyData() are the matching proxy-side exports, so the cluster and proxy XML files make more sense as one generated family rather than isolated config files.
• The CE debug/export comments in centraleconomy.c are the clearest description of why these map-cluster files exist.

mapgroupcluster.xml is one placement chunk from the exported cluster placement set. Treat the numbered cluster files as continuations of the same map placement data, not separate configuration systems.

• name is the cluster or exported object identifier to place.
• pos is the world position in x y z order.
• a is the heading/azimuth for the placed entry.
• Workflow edit these only when you know you are changing world placement data, not loot economy counts.

• name is the exported cluster or object identifier being placed.
• pos is the world position in x y z order.
• a is the heading/azimuth used for the placed entry.
• The numbered files are continuation chunks of the same exported placement set, so they look like repeated rows rather than hand-written config sections.

mapgroupcluster01.xml is one placement chunk from the exported cluster placement set. Treat the numbered cluster files as continuations of the same map placement data, not separate configuration systems.

• name is the cluster or exported object identifier to place.
• pos is the world position in x y z order.
• a is the heading/azimuth for the placed entry.
• Workflow edit these only when you know you are changing world placement data, not loot economy counts.

• name is the exported cluster or object identifier being placed.
• pos is the world position in x y z order.
• a is the heading/azimuth used for the placed entry.
• The numbered files are continuation chunks of the same exported placement set, so they look like repeated rows rather than hand-written config sections.

mapgroupcluster02.xml is one placement chunk from the exported cluster placement set. Treat the numbered cluster files as continuations of the same map placement data, not separate configuration systems.

• name is the cluster or exported object identifier to place.
• pos is the world position in x y z order.
• a is the heading/azimuth for the placed entry.
• Workflow edit these only when you know you are changing world placement data, not loot economy counts.

• name is the exported cluster or object identifier being placed.
• pos is the world position in x y z order.
• a is the heading/azimuth used for the placed entry.
• The numbered files are continuation chunks of the same exported placement set, so they look like repeated rows rather than hand-written config sections.

mapgroupcluster03.xml is one placement chunk from the exported cluster placement set. Treat the numbered cluster files as continuations of the same map placement data, not separate configuration systems.

• name is the cluster or exported object identifier to place.
• pos is the world position in x y z order.
• a is the heading/azimuth for the placed entry.
• Workflow edit these only when you know you are changing world placement data, not loot economy counts.

• name is the exported cluster or object identifier being placed.
• pos is the world position in x y z order.
• a is the heading/azimuth used for the placed entry.
• The numbered files are continuation chunks of the same exported placement set, so they look like repeated rows rather than hand-written config sections.

mapgroupcluster04.xml is one placement chunk from the exported cluster placement set. Treat the numbered cluster files as continuations of the same map placement data, not separate configuration systems.

• name is the cluster or exported object identifier to place.
• pos is the world position in x y z order.
• a is the heading/azimuth for the placed entry.
• Workflow edit these only when you know you are changing world placement data, not loot economy counts.

• name is the exported cluster or object identifier being placed.
• pos is the world position in x y z order.
• a is the heading/azimuth used for the placed entry.
• The numbered files are continuation chunks of the same exported placement set, so they look like repeated rows rather than hand-written config sections.

The stock Chernarus file here is just an empty <map> root. There is no additional dirt-group payload in this snapshot to explain beyond the container itself.

This export places 11680 map-group instances across Chernarus, using 270 distinct prototype names.

mapgroupproto.xml describes loot-capable world objects and the containers/points inside them.

• group is the world object/classname being described.
• container splits that object into logical loot regions such as floor, shelf, room, or weapon spots.
• point is an individual spawn point with position, range, height, and flags.
• category, usage, tag, value are the same CE filters used by types.xml , so they decide which item types can match each point.
• defaults provide fallback point/container values used by many groups so the file does not repeat the same settings everywhere.

• group name is the world object/classname whose loot behavior is being described.
• container blocks split a prototype into logical spawn regions such as floor, shelves, or room loot.
• category , usage , tag , and value are the filters the CE uses when matching items from db/types.xml .
• point rows are the real local-space loot points inside the model.
• dispatch/proxy blocks describe attached proxy objects that the CE also needs to understand for that prototype.

• CEApi.ExportProxyProto() is the explicit CE export hook that generates storage/export/mapgroupproto.xml .
• CEApi.ExportProxyData() generates the matching placed map-group export mapgrouppos.xml .
• CEApi.MarkCloseProxy() , RemoveCloseProxy() , and ListCloseProxy() exist to find and clean up bad or overlapping loot points in these proxy exports.
• That means this file is not arbitrary hand-authored XML. It is part of the CE proxy export pipeline documented directly in scripts/3_game/ce/centraleconomy.c .