![Day[Z] Titan Launcher logo](/assets/img/logo2.webp?v=1781090027){kind=logo}
Day[Z] Titan Launcher
If you have ever opened a DayZ server config and seen tags, entries, types, events and protos thrown around in a Discord without explanation, this guide is for you. We walk through the core economy XML files one at a time, briefly and plainly, so you can see how they connect and where to make a change when you want to “boost” your loot or zombies. It is deliberately a beginner-level rundown - just enough to click the big ideas into place.
Work through these in order. Each file does one job, and the trick is seeing how a name in one file matches a name in another - that matching is what actually makes loot and events appear in the world.
Before touching anything, get the words straight: tags, entries, types, events and protos. These five terms come up constantly and they are the entire reason the files feel confusing at first. Each one lives in a specific file and refers to a specific thing, and once you can name them you can follow any tutorial or Discord thread without getting lost.
The mental model that makes everything else click is this: the DayZ Central Economy is a giant game of “tag and catch”. A name defined in one file is referenced by a name in another, and when those names match, something spawns. Keep that idea in your head as you read each file below - you are mostly just learning where each name is born and where it gets used.
Every entry in types.xml calls a class name. It is called a class name because the game scripts create the item by class - the entry simply tells the economy that this class exists and how it should behave. This is the file most people open first when they want to change how much of something spawns.
The two values the economy plays with most are nominal and min: nominal is the target amount the economy aims to keep in the world, and min is the floor that triggers more to spawn. lifetime is how long, in seconds, the item persists before cleanup. The quantmin and quantmax values set how full an item is when it spawns - for a canteen, for example, that is anywhere from zero to one hundred percent.
To “boost” an item you usually raise its nominal and min. That alone tells the economy to keep more of it alive in the world, without touching any other file.
All of your tags, usage flags and categories are “born” in cfglimitsdefinition.xml. This is their definition file: once a name exists here, the game recognises it across every other file. You then put those names onto a types entry to say where and how that item is allowed to appear.
Usage values are things like Military, Medic, Police, Firefighter, Industrial, Farm, Coast, Town, Village, Hunting, Office, School, Prison and Lunapark. The categories and tier flags (tier one through tier four, area flags and so on) also live here. The game genuinely does not care what you name them - you could call a usage “hostess snack cake” and it would still work, as long as the exact name is properly placed on an item entry down the line.
So where do the type entries actually end up in the world? A proto is the answer. A proto names an item - say, a garbage pile - and you tag that item with the usage and category names you defined in your limits file. The proto also carries coordinates for individual loot points mapped around a centre point of the item.
A proto name can be anything you like. What matters is the next step: that name has to match a position name elsewhere, which is what we look at next. On its own a proto is just a definition saying “this object holds loot tagged like so”.
mapgrouppos.xml holds the positions. As long as a proto name (a mapping) matches a pos name (a position), that proto sits at that position holding whatever loot is tagged for its matching usages. This is the “tag and catch” pairing in action: the proto is the catcher and the pos is the place it stands.
Put plainly, the proto says “I am a garbage pile that holds town and village loot,” and the matching pos says “place that garbage pile here.” Get the two names identical and loot appears at that spot; mistype one and nothing spawns. From here, anything used in events follows the same matching logic.
events.xml and cfgeventspawns.xml go together exactly like proto and pos. An event has a name, and that name carries a prefix: Item, Static or Vehicle. The matching event-spawn name lists the map positions where that named event is allowed to exist.
Inside an event you set the minimum, maximum and nominal outputs, plus a radius the spawned objects (or zombies) can wander within, and the children - the actual things the event puts out. Three extra fields control behaviour: safe radius is how close to a player the event may spawn, distance is how far it must be from another event, and cleanup is how far you have to walk away before it deactivates.
When the child itself is the limit, the output is controlled between each child’s own minimum and maximum together with the overall nominal - no separate event-wide minimum or maximum is needed.
A Vehicle-prefixed event works the same way - the event name matches an event-spawn name, so the event goes to those positions. The new piece is the “a=” value, which is the direction the vehicle faces. The hood points along that angle: 0 or 360 is north, 180 is south, and a little mental math gets you any heading around the circle.
Vehicle events usually use a “mixed” limit. Instead of forcing every listed child to spawn at every exact position (which would pile cars up), you tell the economy to keep an overall total within a min and max around the nominal - for example a total of 11 to 15 vehicles, aiming for about 13, with no more than one to three of each child type in the mix.
The rest behaves like any event: lifetime governs how long a vehicle lasts, and the same safe radius, distance and cleanup rules apply. When a vehicle is ruined the event removes it and pops a fresh one the next time it rotates.
An infected (zombie) event talks to an environment file known as a territory, which defines where that infected group belongs. The territory side is a deeper topic worth its own tutorial, but the basics are enough to make changes.
To simply boost zombies, raise the minimum and nominal outputs of the infected event - you rarely need to touch the maximum for this. You can also mix and match different infected children into other events to spread them around the map wherever you want more of them.
Random presets are the middleman between types.xml and spawnable types. A preset creates a named cargo or attachment loot pool: a list of types or classes, each with a hit chance. When that chance rolls, one of the children in the pool is chosen.
This is how you get variety inside or on an object - for example a cargo preset that fills a container, or an attachment preset that puts a hat or backpack on a zombie. The preset only defines the pool; it is the spawnable type, next, that tells an item to actually use it.
cfgspawnabletypes.xml is what tells a type to have other types attached to it or held within it. It is the consumer of the random presets you defined a moment ago: a spawnable type points at a cargo or attachment preset by name, and the preset’s hit chances then decide what actually appears.
In short, types.xml says an item exists, the random preset defines a pool of possible extras, and the spawnable type wires the two together so a freshly spawned item arrives carrying the right cargo and attachments.
globals.xml holds the server-wide switches, and it is more powerful than it looks. Near the bottom is the overall infected counter - raise or lower it to set the maximum AI allowed. Vanilla sits somewhere around 1000 to 1200; in the source build it was lowered to 850. Alongside it you will find the animal count and how quickly a dead body cleans up.
A key pair of values are the idle settings. Set both idle values to zero and your economy keeps rotating even when no one is online, so loot and events stay fresh on a 24/7 server. Other switches here control how many pieces of loot spawn initially, and let you toggle systems like wet, world and tents.
This is only the beginner’s rundown - there are more files and far deeper videos on each one. But knowing how these core files reference each other is enough to start safely tuning your own server’s loot and zombies.
Start in types.xml and raise the nominal and min of the item you want more of. nominal is the target amount the economy keeps in the world and min is the floor that triggers fresh spawns.
For an overall cap, raise the infected counter in globals.xml. To make a specific area busier, raise the minimum and nominal of the relevant infected event in events.xml - you usually do not need to touch the maximum.
Almost always a name mismatch. A proto name must exactly match a pos name, and an event name must exactly match an event-spawn name. Check spelling and capitalisation on both sides.
A random preset (cfgrandompresets.xml) defines a named pool of possible cargo or attachments with hit chances. A spawnable type (cfgspawnabletypes.xml) tells an actual item to use that pool, so the preset is the middleman between types.xml and what an item spawns carrying.
In globals.xml set both idle values to zero. The economy then keeps rotating around the clock, so a 24/7 server stays stocked with fresh loot and events.