Bases
The base overview answers three questions, in this order of importance:
- Where is my map being settled? This is the real value — a picture of where people build.
- Which base may be torn down or taken over? The clean-up job, which used to be pure manual labour.
- Who owns the thing at coordinate X? Deliberately weak. For a reliable answer, use the Log Explorer.
Navigation path:
Server Admin→Bases
Access requirements
| Right | What it unlocks |
|---|---|
admin.bases.access | See the overview, rename a base, recalibrate the size bands |
admin.bases.review | Record what was found on site: "still standing" or "nothing left" |
admin.bases.delete | Delete a wrong entry |
review and delete are deliberately separate. Recording a finding is the routine daily job of
whoever drives out there; deleting throws data away and now means one thing only — this was never a
base.
How a base is detected
A base is a set of anchors, not a point. One compound with four flag poles is one base with four anchors, and the marker sits on the pole, because in-game that coordinate is the actual territory centre.
- The radius is 60 m — the DayZ territory radius.
- Flag poles chain. A new pole within reach of two bases' anchors proves they were one territory all along, and the two are merged.
- Build and placement events never chain. They attach to the nearest anchor in range, or start a new one. If they chained too, half the map would grow into a single base.
Every relevant event lands somewhere; there is no threshold in the detection itself. Size thresholds are only ever display filters, which is why changing them is harmless.
Detection reads flag raises and lowers, building and dismantling, and the placing, packing and folding of objects. Player positions are not a signal — somebody walking past a ruin says nothing about whether the ruin is still there.
Size
Size is measured in substance: net build and placement events. A flag pole adds nothing by itself — it
is one object, and it already counts through its own build events, through the decay window and through
ownership. Only items tagged base or container in the platform item catalogue count, which is what keeps a
campfire in the woods from putting a phantom build site on your map, and a fence kit from having its
fence counted twice.
The raw number is never shown. It is bucketed into five bands:
| Band | Roughly |
|---|---|
| Build site | Under two fences |
| Small | Two to ten fences |
| Medium | Ten to fifty fences |
| Large | Fifty to two hundred fences |
| Fortress | More than that |
Substance is cumulative and does not expire. A maintained fortress must not appear to shrink while nobody is tearing it down — and "is it still alive" is answered separately. Dismantling and packing subtract, and that is self-cleaning enough.
Folding does not. A fence is only foldable once every part has been dismantled, so folding it up picks the empty kit back off the ground — and the kit was never counted in the first place. It still counts as activity, and for a flag pole it is the moment the pole stops being counted.
Recalibrating the bands
The default numbers travel across servers, because the unit is game mechanics rather than server policy — a fence is about five build events everywhere. They are still only defaults. Recalibrate on the Bases page derives the four bands from your own server's distribution and sets the map's default floor to the top quarter. The histogram above the table shows the consequence of every band before you commit to one.
The bands are then plain numbers again, editable under Settings → World. A percentile is used to
calibrate them once, never to classify: otherwise a base would drop from Large to Medium because
somebody built somewhere else entirely.
Status: is anything still standing
| Status | Meaning |
|---|---|
| Active | Flag fresh, or building activity, or a valid sighting |
| Decaying | The decay window has opened and nothing has happened since |
| No signs left | Even the longest-lived part would be through by now |
Two things are worth knowing about this.
"No signs left" never means "does not exist." The despawn timer can be refreshed in-game without producing a single log line — turning a lock, or starting a dismantle animation on a wall. The decay clock is therefore an estimate by construction. It decides what is prominent; it may not claim non-existence.
Building activity without a flag keeps a base active, and the overview says so rather than dressing it up as a fresh flag. Whether the builder was the owner restructuring, an intruder digging out, or an attacker raising a ramp is not knowable from a log line and does not need to be — what is usable is "somebody was at a structure here". The Log Explorer answers the why.
The decay window is taken per base, over the item types actually standing there: a fortress of fences
and towers gets the fence window, a bush camp the shelter one. The lifetimes come from your server's own
db/types.xml and are refreshed on every mod transfer.
The takeover case
Lowering a flag starts the clock immediately, regardless of when it was last raised. A base whose flag is down but whose substance is still there is flagged as a takeover — it becomes claimable once the timer runs out. This combination was completely invisible before.
Ownership
Everyone who flagged, built, dismantled or placed at a base is recorded as a contributor, with their event count. This replaces the old hand-maintained list of usernames, which a rename silently falsified.
The displayed owner is the contributor with the highest time-weighted score. Raising a flag counts for much more than a build event, and every contribution fades with the server's own flag lifetime.
That fade is what makes the ranking honest. A finished faction base produces zero build events — only the flag still gets raised. A "most activity recently" counter would hand it to whichever attacker last built a jump tower, three to nothing. With decay, the owners keep scoring, one tower is one event against an accumulated account, and a genuine takeover overtakes on its own without any rule saying so. The lead only changes hands on a clear margin, so the name does not flicker.
When roughly three quarters of the weight belongs to one faction, the base is shown under the faction's name instead. Below that it falls back to the leading player, which is the honest answer for a mixed site.
A name you type yourself always wins and stops updating. It is the one thing here that is not derived.
Clean-up queue
Off by default — turn it on under Settings → World → Base clean-up queue if your team drives out
to decaying bases.
The queue is not a separate inbox. It is the Queue tab of the base list: everything decaying, sorted by size, so the biggest prize comes first. There are two outcomes on site:
- Still standing — counts as a sign of life for exactly one decay window. After that the base reappears in the queue by itself. A sighting is structurally the same thing as raising a flag: a timestamped life sign, only from a human.
- Nothing left — the base drops off the map. Any new event at that spot revives it automatically; nobody has to remember to undo the verdict.
Both are recorded with who, when, and an optional note, and both are written to the audit trail.
Neither is permanent, and that is the point. A verdict that stuck forever is how the old overview filled up with ghosts.
Wipes
Bases belong to the wipe they were built in. Setting a new wipe date empties the overview without deleting anything: the previous epoch stays queryable, and a mistyped date destroys nothing — correct it and everything is back.
Building at the same spot after a wipe creates a new base, which matches reality. The map really is empty after a wipe.
Map
The same data drives the map: dot size follows substance, decaying bases are dimmed, and only bases from Large upwards carry a label. Overlapping labels — not the dots — were what made the old map unreadable.
Operating notes
Two commands exist for operators:
app:bases:seed-item-tags— pre-fills thebase/containertags on the item catalogue. Substance counting is whitelist-based, so this has to run before anything is measured.app:bases:recompute <serverId>(or--all) — re-derives the numbers from the log events of the current wipe. Clusters stay exactly as they are, and so does everything a person typed onto a base: the name, the finding, the note. Run it after a formula change. Idempotent.app:bases:recompute --all --rebuild-clusters— additionally re-derives which events belong together. Base ids change and all admin-authored fields are lost. Right at the initial rollout, when there is nothing to lose, and essentially never afterwards: deciding what belongs together is the log import's job, done as events arrive.