Change player spawn locations on a DayZ PC server

By Niko Catarino

Updated 8 October 2026

Change fresh-player spawn locations in the active mission’s cfgplayerspawnpoints.xml. The coordinates define areas where DayZ generates suitable spawn candidates. A saved character logging back in is not a fresh-spawn test.

This procedure covers DayZ Standalone PC community servers. It requires mission-file access and a test server you can join. A spawn-selection mod can replace the vanilla behavior; check its configuration first.

Back up the correct spawn file

Read the startup configuration selected by -config, then find its mission template. Open that mission under mpmissions, stop the server and download cfgplayerspawnpoints.xml.

Save an untouched copy outside the live mission. Confirm the filename before replacing it: cfgspawnabletypes.xml controls item attachments and cargo, which is a different job. Save your mission and persistence backup before broader world changes.

If you need a reference, use Bohemia’s Chernarus mission file, or the matching mission for your map and build. That pinned Chernarus file matches the stock copy in our 1.29.163709 test installation. Compare its structure with your installed file; do not import another map’s coordinates.

Edit the fresh-player section

Bohemia’s player spawning reference distinguishes three sections. <fresh> is the relevant section for new characters here. <hop> and <travel> concern official-server transfers; editing those is not a fresh-spawn change for your community server.

Inside <fresh>, locate <generator_posbubbles>. Your file may hold named <group> elements or a flat list of <pos> entries. Keep the existing arrangement and replace one selected position with coordinates from your current map.

This is a template for a position element, not upload-ready XML:

<pos x="X_FROM_YOUR_MAP" z="Z_FROM_YOUR_MAP" />

Replace both labels with numeric world coordinates. x and z are the horizontal axes; do not paste a three-number position containing height into two attributes. Use a map or an authorised PC admin tool to collect the position, then inspect the ground in-game.

For the first test, choose accessible ground away from water, cliffs, toxic areas and enclosed structures. Check the surrounding area as well as the exact point. The generator samples a grid around each coordinate, so a centre on dry land can still produce unsuitable candidates near its edges.

Copy coordinates from an administration log

On your test server, enable administration logging and the periodic player list. Stand at the intended location until a new player-list entry records your character there. Match the name, identity and timestamp in the .ADM file. A hit record can also contain a position, but check which player’s position you are reading.

The standard player prefix writes coordinates as X, Z, height, with height last. Bohemia’s logging code explicitly rearranges the position vector in this order. For an illustrative record containing pos=<1234.5, 6789.0, 42.0>, the spawn element would be:

<pos x="1234.5" z="6789.0" />

Use your own recorded location; these numbers demonstrate the conversion and are not a recommended spawn. Leave out the third value, 42.0, because this XML element takes only horizontal coordinates. A mod can change log formatting, and admin tools may show the usual X, height, Z vector instead. Check that tool’s labels before copying values. Inspect the resulting area in-game before continuing.

Keep the generation and group rules

Section	What to review
generator_params	Grid dimensions, density and terrain restrictions used to generate candidates.
spawn_params	Runtime suitability checks, including nearby players and infected.
group_params	Whether groups are active and how the selected group rotates.

Scroll to see all columns →

Keep these values unchanged while testing a location edit. Bohemia documents group lifetime and counter behavior; groups_as_regular allows grouped positions to act as regular spawn points when enablegroups is disabled. An enabled group rotation means several respawns can use the same area; one result does not prove that the other groups are ignored.

Do not reduce exclusion distances to zero to force a bad point to work. Choose suitable ground first. Avoid turning every fresh spawn into a single shared location on a public server unless that is the mode you intend to run.

Replace the default spawn areas

After the one-position test passes, stop the test server and save another copy of the XML. In <fresh>/<generator_posbubbles>, keep only the locations you intend to use:

• With named groups, replace their positions with your tested coordinates and remove unwanted groups in full. Keep at least one group containing at least one <pos>.
• With a flat list, replace the default <pos> entries with your tested positions. Keep at least one entry.

For one shared spawn area, retain one group with one position, or one position in the existing flat list. Leave the generation, suitability and group settings unchanged for this test. Keep <hop> and <travel> intact. Check the complete <fresh> list so an overlooked default position cannot remain a candidate.

Bohemia’s spawning reference defines each position as the centre of a generated grid. A single position therefore selects one area; it does not guarantee every character appears on the exact same spot. Test fresh characters with other players nearby as described below. If the remaining area cannot produce suitable spawns, restore the saved file and choose another location.

Validate and run the acceptance test

Parse the complete XML in PowerShell before uploading it:

$spawnXml = [xml](Get-Content -LiteralPath './cfgplayerspawnpoints.xml' -Raw)
if ($null -eq $spawnXml.SelectSingleNode('/playerspawnpoints/fresh/generator_posbubbles')) {
    throw 'Missing the expected fresh-player spawn section.'
}
$spawnXml.playerspawnpoints.fresh.generator_posbubbles | Format-List

Check that the edited <pos> is live XML rather than text inside <!-- ... -->. This check detects malformed XML and a missing fresh-player section; numeric coordinates and game behavior still need review.

Upload while the test server is stopped, start it and inspect startup logs. Use a disposable test character or a separate test copy with fresh-character state:

1. Create a fresh character and record where it appears.
2. Repeat across the configured group rotation, checking each changed area.
3. Check access to cover, water and an exit route. Test the area with another connected player because runtime distance rules can change candidate selection.
4. Restart, create another fresh character and confirm the configuration still loads.

Do not delete live characters or world persistence to test a coordinate change. A reconnecting survivor should retain its saved position.

If nothing changes, confirm the selected mission, live filename, fresh section and any spawn-selection mod. If only one area fails, inspect its ground and generated grid. Roll back by restoring the original XML while stopped, then restart and retest.

Configure fixed locations with zSpawnSelection

If your server uses Pattow’s zSpawnSelection, item 2017605880, edit its generated configuration for the selection menu. The author requires CF and either VanillaPlusPlusMap or an Expansion map. A white menu background can mean the map dependency is missing. Follow the mod installation procedure and check the requirements of your chosen map package.

Start the test server once, then stop it and find the active profiles directory through its startup settings. Inside zSpawnSelect, back up the generated SpawnLocations.json. Preserve the filename’s actual capitalization. The author’s October 2024 update introduced automatic configuration generation; older instructions for manually copying a profile folder describe an earlier setup.

Edit one named entry in m_SpawnLocations, retaining the rest of the generated structure:

• LocationName is the label players select.
• SpawnCordinate is the position string. Keep that exact spelling, including the missing second “o”; the author’s field name is not SpawnCoordinate.
• SpawnRadius controls the area around that position. Check the whole area for unsuitable ground.
• AllowBodyBlock, BodyBlockDistance and BodyBlockTimer govern the nearby-body restriction. The description says this check is client-side and can be bypassed by logging off, so don’t rely on it to enforce a server rule.

The author’s Sakhal example shows the enclosing JSON structure. Use coordinates for your own terrain; the generated defaults are for Chernarus. A named location accepts one coordinate string. For several nearby destinations, create separate named entries rather than an array of coordinates inside one entry. Validate the complete JSON after editing; explanatory // comments from the description do not belong in a JSON file.

Keep AllowBaseSpawn at 0 while setting up fixed locations. The 28 January 2025 change changed the default base-spawn radius to 100 metres, superseding the older example’s value of 1. In March 2025 replies, the author still reported TerritoryFlag spawns resolving to 0 0 0 and uncertainty about base spawning. Those sources do not establish a current fix. Check exact-release behavior before enabling that feature; substituting another object is not a verified repair.

Restart the test copy and create fresh characters. Check each menu destination, the random choice, reconnect behavior and the selected terrain. If a saved survivor is relocated or a destination lands in water or below the map, restore the saved configuration and investigate before allowing players to use it. Keep the world and existing characters intact during these checks.

For a new character’s equipment, use the starter gear procedure. Return to the DayZ tutorial hub for other configuration jobs.

Source and verification scope

The vanilla coordinate and spawn-list instructions used AI-assisted research and drafting. They were checked against Bohemia’s spawning reference, administration-log reference and the linked logging-code revision on 8 October 2026. No game session or spawn-distribution test was run for these additions.

The zSpawnSelection section used AI-assisted research and drafting. On 7 October 2026, we read the original description, all 26 change entries, the complete pinned Sakhal thread and selected author replies. Current packaged code, generated files, client/server installation scope and gameplay have not been tested here. The base-spawn feature remains unverified; no community replacement package was substituted.