DayZ Files Explained

• The stock Chernarus file defines 8 root classes and 18 default values before the rest of the CE XML is processed.
• Character-style roots in this file are SurvivorBase, DZ_LightAI.
• Vehicle-style roots in this file are CarScript, BoatScript.
• The default block includes dynamic-event seed values such as dyn_radius, dyn_smin, dyn_smax, dyn_dmin, and dyn_dmax, plus 11 CE logging toggles.

• 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]
  ]
}

• The stock Chernarus file registers 13 territory source files and maps them into 13 logical territory definitions.
• It currently uses 10 herd territories and 3 ambient territories.
• Herd definitions in this file include Deer, Cow, Goat, Sheep, RoeDeer, Wolf, WildBoar, Pig, ....
• Ambient definitions in this file include AmbientHen, AmbientHare, AmbientFox.
• The raw source currently repeats env/hare_territories.xml, so flattening the XML into generic rows loses useful detail.

• The stock Chernarus file defines 83 named event groups.
• Sample group names from this file: Train_Abandoned_Cherno, Train_Abandoned_Kamarovo, Train_Abandoned_Kamy, Train_Abandoned_Myshkino, Train_Abandoned_Petrovka, Train_Abandoned_Prigorodki, Train_Abandoned_Skalisty, Train_Abandoned_Svetlo, ....
• Group size ranges from 3 to 23 child objects in this file.
• 336 child objects in this file explicitly carry a spawnsecondary attribute.

• type is the object classname spawned as part of the group.
• x, z, and y are offsets from the group anchor, not full world coordinates.
• a is the per-child heading relative to the group placement.
• lootmin and lootmax are the child-level secondary loot bounds used when the object supports them.
• deloot marks whether the child is part of dynamic-event style loot handling.

• The stock Chernarus file defines 34 event-position blocks with 1435 fixed <pos> entries.
• Events using an explicit <zone> block in this file include StaticHeliCrash, StaticSantaCrash, StaticBonfire, StaticContaminatedArea, StaticPoliceCar, StaticAirplaneCrate, StaticTrain, StaticMilitaryConvoy, ....
• Most vehicle-style event blocks are just lists of fixed world coordinates and headings. Event-zone blocks are the exception, not the rule.

• event name ties this file back to the matching entry in db/events.xml.
• pos x and pos z are world coordinates on Chernarus.
• pos a is the heading used when the event/object is spawned at that slot.
• zone smin/smax/dmin/dmax/r defines zone-based event logic such as zone radius and min/max density-style values for events like heli crashes.

• 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
  }
}

The stock Chernarus file currently ignores 24 classes. These are object classes the CE should skip when generating or evaluating proxy/loot support data.

Current examples: Bandage, BandanaMask_BlackPattern, BandanaMask_CamoPattern, BandanaMask_GreenPattern, BandanaMask_PolkaPattern, BandanaMask_RedPattern, CattleProd, DallasMask, Defibrillator, EngineOil

• This file defines 8 categories, 3 tags, 17 usage flags, and 5 value tiers.
• Categories in this file are tools, containers, clothes, lootdispatch, food, weapons, books, explosives.
• Usage flags include Military, Police, Medic, Firefighter, Industrial, Farm, Coast, Town, Village, Hunting, ... and value tiers include Tier1, Tier2, Tier3, Tier4, Unique.
• Tags stay deliberately small in this file: floor, shelves, ground.

• These identifiers are the vocabulary reused across db/types.xml, mapgroupproto.xml, and the CE world-data files.
• category, usage, tag, and value are not free-text notes. They are the filter names the CE matches against when deciding what can spawn where.
• EconomyMapStrings.Category(...) and EconomyMapStrings.Tag(...) in centraleconomy.c are built around the same identifiers, so these names also drive CE debug/map tooling.

• This file defines 2 named usage combinations and 6 named value-tier combinations.
• TownVillage = Town, Village
• TownVillageOfficeSchool = Town, Village, Office, School
• Tier12 = Tier1, Tier2
• Tier23 = Tier2, Tier3
• Tier34 = Tier3, Tier4
• Tier123 = Tier1, Tier2, Tier3
• Tier234 = Tier2, Tier3, Tier4
• Tier1234 = Tier1, Tier2, Tier3, Tier4

• 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 is for ordinary fresh spawns.
• hop is for same-map server hopping logic.
• travel is for cross-map travel spawn handling.
• spawn_params controls distance checks against infected, players, and nearby statics.
• generator_params controls the search grid and steepness filters used to generate actual spawn points inside the bubbles.
• generator_posbubbles is the real coastal/world anchor list that the generator works from.

• MissionServer.OnInit() loads gameplay data first, then player-spawn related handlers, so spawn logic starts after the gameplay settings are already resolved.
• The spawn-point XML is part of the mission startup contract even though the heavy lifting is handled deeper in engine/gameplay code rather than a single easy Enforce loader file.

• This file defines 43 cargo presets and 35 attachment presets.
• Cargo preset names in this file include foodHermit, foodVillage, foodCity, foodArmy, toolsHermit, toolsVillage, toolsCity, toolsMedic, toolsPolice, toolsHunter, ....
• Attachment preset names in this file include optics, hatsFarm, bagsHunter, vestsHunter, hatsVillage, handsVillage, bagsVillage, glassesVillage, hatsCity, handsCity, ....
• The largest cargo preset contains 27 candidate items, while the largest attachment preset contains 20 candidate items.

• 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.

• The stock Chernarus file defines 574 spawnable-type override rows.
• 17 rows are simple hoarder markers, 59 define explicit damage ranges, 426 define cargo presets/items, and 230 define attachment pools.
• This file is about how a spawned item is rolled once it already exists as a valid CE item, not whether that item exists in the economy at all.

• 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.

• The stock Chernarus file contains 59 event definitions.
• Common event names in this file include AmbientFox, AmbientHare, AmbientHen, AnimalBear, AnimalCow, AnimalDeer, AnimalGoat, AnimalPig, AnimalRoeDeer, AnimalSheep, ....
• Position modes currently used: fixed (31), player (27), uniform (1).
• Limit modes currently used: mixed (21), custom (20), child (17), parent (1).

• nominal, min, and max are the basic target and cap values for the event family.
• lifetime and restock control how long spawned content can stay around and how quickly the CE tries to refill it.
• saferadius, distanceradius, and cleanupradius define the distance checks used by the CE around players and spawned content.
• children is the actual spawn mix for that event, usually item or animal classnames with child-level min/max bounds.

• ECE_EQUIP_CONTAINER is the CE spawn flag that tells the engine to populate dynamic-event or group containers during spawn.
• ECE_DYNAMIC_PERSISTENCY is the flag used for objects that should start non-persistent and only become persistent once players interact with them.
• The Enforce-side CE API in centraleconomy.c is mostly a debugging/export surface. The actual event spawning logic is still executable-side, so events.xml changes work even without an Enforce implementation of the entire event pipeline.

These examples keep the common server-owner explanations from the original /dayz/ page and place them directly under db/events.xml so the file reference stays in one tab.

The init_random attribute determines initialization randomness for entities when spawned by an event.

• When init_random="1": Spawns vary in quantities and may include random attachments from cfgspawnabletypes.xml. Child entity counts vary between their configured min and max.
• When init_random="0": Entities spawn with consistent, predictable configurations tied to your spawnable setup.

Use cases: Set to 1 for wildlife and roaming encounters to add unpredictability. Set to 0 for static weapons caches or vehicles where consistency matters.

<event name="ItemWeaponSpawn">
  <nominal>10</nominal>
  <min>5</min>
  <max>15</max>
  <lifetime>600</lifetime>
  <saferadius>2000</saferadius>
  <distanceradius>500</distanceradius>
  <cleanupradius>1500</cleanupradius>
  <flags deletable="0" init_random="0" remove_damaged="1" />
  <position>fixed</position>
  <limit>custom</limit>
  <active>1</active>
  <children>
    <child lootmax="0" lootmin="0" max="10" min="5" type="AKM"/>
    <child lootmax="0" lootmin="0" max="10" min="5" type="M4A1"/>
    <child lootmax="0" lootmin="0" max="10" min="5" type="FAMAS"/>
  </children>
</event>

Behavior with init_random="0": Spawns 5-10 of each weapon type (AKM, M4A1, FAMAS) with attachments from cfgspawnabletypes.xml. Use this pattern for fixed-location weapon caches where you want consistent, controlled spawning.

<event name="AnimalSpawn">
  <nominal>10</nominal>
  <min>5</min>
  <max>10</max>
  <lifetime>1800</lifetime>
  <saferadius>300</saferadius>
  <distanceradius>2000</distanceradius>
  <cleanupradius>500</cleanupradius>
  <flags deletable="1" init_random="0" remove_damaged="1" />
  <position>fixed</position>
  <limit>mixed</limit>
  <children>
    <child lootmax="0" lootmin="0" max="1" min="1" type="Animal_CapreolusCapreolus"/>
    <child lootmax="0" lootmin="0" max="3" min="1" type="Animal_CapreolusCapreolusF"/>
  </children>
</event>

Behavior with mixed limits: Randomly spawns deer with variable counts. Perfect for roaming wildlife encounters. The deletable="1" allows animals to be deleted naturally.

<event name="VehicleHatchback_02">
  <nominal>10</nominal>
  <min>5</min>
  <max>10</max>
  <lifetime>1800</lifetime>
  <saferadius>300</saferadius>
  <distanceradius>100</distanceradius>
  <cleanupradius>100</cleanupradius>
  <flags deletable="1" init_random="0" remove_damaged="1" />
  <position>fixed</position>
  <limit>mixed</limit>
  <children>
    <child lootmax="0" lootmin="0" max="1" min="1" type="Hatchback_02"/>
  </children>
</event>

Use deletable="1" to allow vehicles to despawn normally. Perfect for spawning abandoned vehicles at fixed locations.

The position attribute controls where entities are spawned:

• fixed - Entities spawn at predefined coordinates specified in cfgEventSpawns.xml or equivalent files. Use for buildings, landmarks, vehicles, and controlled crash sites.
• player - Entities spawn dynamically around the player's current location. Use for roaming wildlife, random encounters, and mobile threats.

<position>fixed</position>
<position>player</position>

Combines event-level settings with child/global behaviour - useful for hybrid control where some rules come from the event and others from child configurations.

<event name="ItemGunSpawn">
  <nominal>10</nominal>
  <min>5</min>
  <max>15</max>
  <lifetime>600</lifetime>
  <limit>mixed</limit>
  <children>
    <child max="10" min="5" type="AKM"/>
    <child max="10" min="5" type="M4A1"/>
  </children>
</event>

All spawn rules are defined by the event itself; no external limits are applied. Perfect for completely custom spawn logic.

<event name="ItemGunSpawn">
  <nominal>10</nominal>
  <min>5</min>
  <max>15</max>
  <lifetime>600</lifetime>
  <limit>custom</limit>
  <children>
    <child max="10" min="5" type="AKM"/>
  </children>
</event>

Spawn limits lean on child element configurations. Each child's min/max values determine how many of that type spawn.

<event name="ItemGunSpawn">
  <nominal>10</nominal>
  <lifetime>600</lifetime>
  <limit>child</limit>
  <children>
    <child max="10" min="5" type="AKM"/>
    <child max="8" min="3" type="M4A1"/>
  </children>
</event>

Spawn limits use the child item type's global economy settings. Respects the types.xml economy tier and count rules.

<event name="ItemGunSpawn">
  <nominal>10</nominal>
  <lifetime>600</lifetime>
  <limit>global</limit>
  <children>
    <child type="AKM"/>
    <child type="M4A1"/>
  </children>
</event>

The deletable attribute determines whether spawned entities can despawn at the end of their lifetime.

• Value 0 - The entity cannot be deleted automatically. It persists until its lifetime expires or is manually cleaned up.
• Value 1 - The entity will despawn normally as if spawned like regular world loot.

Use case: Set to 0 for important mission items, event-specific weapons, or anything that shouldn't disappear prematurely. Set to 1 for standard loot and consumables.

The remove_damaged attribute controls whether damaged entities or objects are automatically cleaned up from the server.

• Value 0 - Damaged entities persist until their lifetime expires. Useful for persistent wreckage or terrain features.
• Value 1 - Damaged entities are automatically removed to improve server performance. Recommended for loot, vehicles, and consumables.

Use case: Set to 0 for landmark structures or important collision objects. Set to 1 for loot spawns and perishable items to prevent clutter from damaged items blocking spawns.

<event name="StaticHeliCrash">
  <nominal>3</nominal>
  <min>2</min>
  <max>3</max>
  <lifetime>2100</lifetime>
  <restock>0</restock>
  <saferadius>500</saferadius>
  <distanceradius>1500</distanceradius>
  <cleanupradius>2000</cleanupradius>
  <secondary>InfectedArmy</secondary>
  <flags deletable="0" init_random="1" remove_damaged="1" />
  <position>fixed</position>
  <limit>mixed</limit>
  <active>1</active>
  <children>
    <child lootmax="15" lootmin="5" max="10" min="1" type="Wreck_UH1Y"/>
  </children>
</event>

Purpose: Spawns static helicopter crash sites with military-level zombies. Use secondary="InfectedArmy" for harder enemies, or secondary="none" for safe loot areas. The lifetime=2100 keeps crashes for 35 minutes.

<event name="StaticHeliCrashHard">
  <nominal>3</nominal>
  <min>2</min>
  <max>3</max>
  <lifetime>3600</lifetime>
  <restock>0</restock>
  <saferadius>3000</saferadius>
  <distanceradius>1500</distanceradius>
  <cleanupradius>2000</cleanupradius>
  <secondary>InfectedArmyHard</secondary>
  <flags deletable="0" init_random="0" remove_damaged="1" />
  <position>fixed</position>
  <limit>mixed</limit>
  <active>1</active>
  <children>
    <child lootmax="25" lootmin="3" max="10" min="1" type="Wreck_UH1Y"/>
  </children>
</event>

Enhanced variant: Lasts 1 hour with lootmax="25" for more valuable items, and InfectedArmyHard for tougher enemies. Perfect for high-tier military gear rewards.

• 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.

• The Chernarus world tree in this workspace does not include a local db/messages.xml, so the example below uses the stock mission-template format instead.
• The template currently contains 0 live message entries and mostly serves as a commented format/example file.
• Message fields and common restart/welcome patterns are shown without inventing a Chernarus message payload that is not present locally.

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.

• The stock Chernarus file contains 1941 per-item economy rows.
• Common categories in this file include clothes, tools, weapons, lootdispatch, containers, food.
• Common usage tags include Town, Village, Military, Industrial, Farm, Hunting.
• Value tiers seen in this file include Tier2, Tier3, Tier4, Tier1, Unique.

• 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.

• 34 rows currently set deloot="1", meaning those items are intended for dynamic-event style spawning rather than ordinary world loot pools.
• 313 rows currently set crafted="1", marking items that exist through craft/manual creation logic instead of ordinary world spawning.
• count_in_map, count_in_player, count_in_cargo, and count_in_hoarder decide which locations contribute to the global count that nominal/min are measured against.

• 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.

When crafted="1", items are marked as expected to be created through crafting rather than normal spawning.

On console, some coloured or variant items rely on this flag and will not spawn as regular loot without it.

Example: Weapon colour variants, crafted clothing, and custom items often need crafted="1" to show up in loot economy.

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" - A crafted weapon variant that only appears through crafting, not as natural loot:

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

• 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.

• This file is binary and is 83886104 bytes long.
• The first six 32-bit header integers in this copy are (4096, 4096, 15360, 15360, 32, 0).
• Unlike the XML/JSON files, this is generated map data for the Central Economy world layer rather than a normal hand-authored config.

• This file is the area-flag grid consumed by the CE/executable side when evaluating map-based area rules.
• EconomyLogCategories.SAreaflags in centraleconomy.c is the debug/log category that points at this area-flag layer.
• These source files do not expose a friendly text format for the per-cell payload, so this stays a binary reference section instead of inventing hand-written byte meanings.

Binary header ints: (4096, 4096, 15360, 15360, 32, 0)
First 64 bytes:
00 10 00 00 00 10 00 00 00 3c 00 00 00 3c 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

• The stock Chernarus file defines 55 named export mappings and 55 cluster prototypes.
• Common trajectory/export links in this file include TrajectoryStones, TrajectoryConiferous, TrajectoryDeciduous, TrajectoryApple, TrajectoryPear, TrajectoryCanina, TrajectorySambucus, TrajectoryHumus.
• This file is the cluster equivalent of mapgroupproto.xml: it ties model exports and trajectory names to cluster loot-point definitions used by the world-data layer.

• 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.

• This chunk contains 50000 placed cluster rows using 53 distinct names.
• Common names in this chunk include PearTree2, PearTree3, AppleTree2, SambucusBush1, FagusSylvatica_stumpC, PlumTree1, CaninaBush1, CaninaBush2, FagusSylvatica_stump, FagusSylvatica_fallenB.
• These files are not normal gameplay tuning files. They are chunked placement exports that belong to the same map-cluster data family as mapclusterproto.xml.
• CEApi.ExportClusterData() in centraleconomy.c is the export hook that explains why these files exist.

• 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.

• This chunk contains 50000 placed cluster rows using 55 distinct names.
• Common names in this chunk include PlumTree1, PearTree2, FagusSylvatica_fallenC, QuercusRobur_stumpB, FagusSylvatica_stumpC, FagusSylvatica_fallen, PearTree3, FagusSylvatica_fallenB, SambucusBush1, CaninaBush2.
• These files are not normal gameplay tuning files. They are chunked placement exports that belong to the same map-cluster data family as mapclusterproto.xml.
• CEApi.ExportClusterData() in centraleconomy.c is the export hook that explains why these files exist.

• 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.

• This chunk contains 50000 placed cluster rows using 54 distinct names.
• Common names in this chunk include AppleTree1, CaninaBush1, PlumTree1, PearTree3, CaninaBush2, SambucusBush1, PearTree2, QuercusRobur_2d, AppleTree2, Haybale.
• These files are not normal gameplay tuning files. They are chunked placement exports that belong to the same map-cluster data family as mapclusterproto.xml.
• CEApi.ExportClusterData() in centraleconomy.c is the export hook that explains why these files exist.

• 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.

• This chunk contains 50000 placed cluster rows using 54 distinct names.
• Common names in this chunk include PinusSylvestris_3d, PinusSylvestris_fallen, PinusSylvestris_fallenB, PinusSylvestris_stump, PinusSylvestris_stumpB, PinusSylvestris_fallenc, PiceaAbies_3d, PiceaAbies_fallenB, PiceaAbies_stump, PiceaAbies_fallenC.
• These files are not normal gameplay tuning files. They are chunked placement exports that belong to the same map-cluster data family as mapclusterproto.xml.
• CEApi.ExportClusterData() in centraleconomy.c is the export hook that explains why these files exist.

• 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.

• This chunk contains 17373 placed cluster rows using 54 distinct names.
• Common names in this chunk include AppleTree3, PiceaAbies_fallen, PiceaAbies_fallenB, PiceaAbies_stumpB, PiceaAbies_stump, PiceaAbies_fallenC, PiceaAbies_3d, PiceaAbies_2d, PathD30, PathD10.
• These files are not normal gameplay tuning files. They are chunked placement exports that belong to the same map-cluster data family as mapclusterproto.xml.
• CEApi.ExportClusterData() in centraleconomy.c is the export hook that explains why these files exist.

• 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.

• The stock Chernarus file defines 10 defaults and 426 named map-group prototypes.
• Common container names in this file include lootFloor, lootweapons, lootshelves, loot, lootGround, lootFactory, lootgalery, lootroom.
• Common usage tags include Village, Industrial, Military, Town, Farm, Hunting, Police, Coast.
• This file is the loot-point definition side of the map-group system. It describes what a named building/object prototype can spawn and where inside that model those points live.

• 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.

• main() calls CreateHive() and InitOffline() to boot the offline economy.
• After the CE starts, the script forces the world date into a September 20 window if the current date drifts outside the intended range.
• CreateCustomMission() returns a CustomMission instance, which is the mission implementation used by the offline template.

• Body clothing gets randomized health, then receives a BandageDressing and one random chemlight.
• The player also gets one random fruit: Apple, Pear, or Plum.
• The script explicitly randomizes the health of the spawned clothing/items instead of handing out pristine gear.