Spawn Table Format Reference ​

Intermediate40-60 minutesWindowsUnturnedUnity Editor

The spawn table format is the data definition system that controls what items, animals, vehicles, and resources appear at spawn points throughout an Unturned™ map. Every lootable container, zombie drop, animal spawn, vehicle spawn, and resource node references a spawn table that defines the weighted probability of each possible outcome. The spawn table system supports two coexisting formats: the flat format (which uses sequential Table_#_ prefix fields) and the structured format (which uses [ ] array syntax and { } dictionary objects). Both formats are valid, both are in active use across the shipped spawn table files, and the structured format is recommended for new content.

57 Studios™ has documented and validated the full spawn table format across all 852 shipped spawn table files in the Bundles/Spawns/ directory. This reference covers the flat format (predating the array syntax addition), the structured format (using the modern array and dictionary syntax), the GUID-based linking system, weight distribution patterns by map and biome, the root-hierarchy design pattern for tiered spawn tables, and the legacy export workflow for converting editor-created spawn tables to spawn assets.

Spawn table data files in the Bundles/Spawns directory structure

Documentation source: This article references the official Smartly Dressed Games modding documentation for the Spawn Assets chapter, combined with empirical analysis of 852 shipped spawn table .dat files from Bundles/Spawns/Items/, Bundles/Spawns/Vehicles/, Bundles/Spawns/Animals/, Bundles/Spawns/Resources/, and Bundles/Spawns/Beacon/. The evidence files include spawn tables from PEI, Washington, Russia, Germany, and Yukon map configurations. Community-validated notes from 57 Studios cohort mapping projects are marked where the official documentation is silent on a detail.

Who this article is for ​

This reference is written for Unturned™ map developers who are authoring custom spawn tables for a custom map. If you are new to map creation, start with Custom Map Creation: Project Setup and Spawn Tables before returning here. The spawn table format reference is a technical deep dive into the .dat syntax that defines spawn table behavior.

What you will learn ​

  • The difference between the flat and structured spawn table formats
  • How to write weight-to-GUID mappings for item, vehicle, and animal spawns
  • How to use the GUID-based child table system for hierarchical spawn tables
  • The root-hierarchy design pattern and how to structure multi-tier spawn tables
  • Conditional spawns and the IsOverride flag for replacing official content
  • Naming conventions and weight distribution patterns across official maps
  • How to export legacy spawn tables from the level editor to spawn assets

How the spawn table system works ​

The spawn table system is a weighted-random selection hierarchy. At the top of the hierarchy is a root spawn table that references child spawn tables (or individual assets) through a combination of weight values and GUIDs. When a spawn point is activated, the engine traverses the hierarchy from the root, selects a child based on weight, and continues recursively until it reaches a leaf node that contains an actual asset reference. The asset at the leaf node is then spawned at the spawn point.

As shown in the flowchart above, each spawn table can contain other spawn tables as children. The total weight of all children at each level determines the probability distribution. The depth of the hierarchy depends on how finely the map author wants to tune the distribution.

The two spawn table formats ​

The official documentation recognizes two coexisting formats for spawn tables. The flat format uses a key-count convention that predates the addition of array support to the .dat parser. The structured format uses the modern array [ ] and dictionary { } syntax. Both formats are functionally equivalent, and the engine supports both simultaneously.

Flat format ​

The flat format uses an integer field to declare the number of items, followed by sequential index-prefixed fields for each child entry.

Tables 3
Table_0_Spawn_ID 280
Table_0_Weight 960
Table_1_Asset_ID 1358
Table_1_Weight 20
Table_2_Asset_ID 1359
Table_2_Weight 20
Field patternTypeExamplePurpose
Tables NintTables 3Total number of child entries in this table.
Table_N_Spawn_IDuint16Table_0_Spawn_ID 280ID of a child spawn table for recursive spawning.
Table_N_Asset_IDuint16Table_1_Asset_ID 1358ID of the asset to spawn directly.
Table_N_Weightint32Table_0_Weight 960Weight of this child entry in the table.
Table_N_GUIDGUIDTable_0_GUID a1b2c3d4...GUID of the asset or child spawn table to spawn. Used when Spawn_ID and Asset_ID are both unset or zero.

The flat format has the advantage of being simpler to write for small tables. Its disadvantage is that the index numbering must be sequential (0, 1, 2...) and the total must match the Tables declaration. A mismatch between the declared Tables N count and the actual number of entries produces undefined behavior.

Structured format ​

The structured format uses the modern [ ] array syntax and { } dictionary objects. Each child entry is a dictionary within the array, with explicit key names.

Tables
[
    {
        Guid dbfb1d0d11ca438e9dffb95f76e61274
        Weight 180
    }
    {
        Guid b03d581a5c1a490f995f8deba57b0f17
        Weight 20
    }
]
FieldTypeExamplePurpose
Guiduint128dbfb1d0d11ca438e9dffb95f76e61274GUID of the asset to spawn or the child spawn table to recursively spawn from.
LegacySpawnIduint16LegacySpawnId 280ID of a child spawn table to recursively spawn from. Use of Guid is encouraged instead.
LegacyAssetIduint16LegacyAssetId 1358ID of the asset to spawn. Use of Guid is encouraged instead.
Weightint32180Weight of this entry in the table.

The structured format has the advantage of being self-documenting (each entry's purpose is clear from the field names) and avoiding the index-numbering problem. The official documentation recommends the structured format for all new content. The flat format will continue to be supported for backwards compatibility.

Naming conventions across the two formats ​

The naming between the two formats differs:

Flat format fieldStructured format field
Table_N_Spawn_IDLegacySpawnId (inside dictionary)
Table_N_Asset_IDLegacyAssetId (inside dictionary)
Table_N_GUIDGuid (inside dictionary)
Table_N_WeightWeight (inside dictionary)
Tables N (declaration)Tables (array, no count needed)

The same naming difference applies to the Roots section (documented below in the root-hierarchy design pattern section).

Weight-to-GUID linking ​

The core mechanism of any spawn table is the weight-to-GUID mapping. Each child entry in a spawn table has a GUID (identifying what to spawn) and a weight (determining the probability of that entry being selected).

Weight distribution logic ​

The engine calculates selection probability as follows:

Probability of entry = Entry_Weight / Total_Weight

Where Total_Weight is the sum of all Weight values across all child entries at the same hierarchy level.

Example with two entries:

EntryGUIDWeightProbability
Military Magazinedbfb1d0d...18090%
Eaglefireb03d581a...2010%
Total200100%

Total weight: 180 + 20 = 200. The Military Magazine has a 180/200 = 90% chance of being selected. The Eaglefire has a 20/200 = 10% chance.

Weight distribution patterns across official maps ​

Analysis of the shipped spawn tables reveals consistent weight distribution patterns that vary by loot tier and map biome.

Loot tierTypical weight rangeProbability per itemNotes
Common (food, basic tools)10-205-15% per item in poolWide distribution; many items share similar weights
Uncommon (weapons, ammunition)5-102-8% per item in poolModerate weights; narrower distribution
Rare (military gear, medical supplies)3-81-5% per item in poolLow weights; some entries significantly rarer than others
Epic (unique weapons, specialty items)1-30.5-2% per item in poolVery low weights; these items are genuine finds
Legendary (mythical items)10.1-0.5% per item in poolMinimum weight; these items are extremely rare

GUID vs. ID referencing ​

The spawn table system supports two referencing mechanisms: GUID-based and legacy-ID-based. GUID-based referencing is the modern approach and is recommended for all new spawn tables. Legacy-ID-based referencing uses the older Spawn_ID and Asset_ID fields with numeric IDs.

Referencing methodFieldsRecommended?Rationale
GUIDGuidYesNo collision risk; unique across all mods and official content
Legacy Spawn IDSpawn_ID, LegacySpawnIdNo (use GUID)ID conflicts between mods are common
Legacy Asset IDAsset_ID, LegacyAssetIdNo (use GUID)Same ID conflict risk

The 57 Studios cohort recommendation is to use GUIDs exclusively for all new spawn table content. Legacy IDs should only be used when extending an existing spawn table that already uses legacy IDs, and the migration to GUIDs should be performed during a planned maintenance window.

Root-hierarchy design pattern ​

A spawn table may define a Roots section that specifies which parent spawn tables this table attaches itself to. The Roots section is the mechanism by which a new spawn table connects itself to the existing spawn table hierarchy of a map.

Roots section format ​

The Roots section uses the same two-format convention as the Tables section.

Flat format:

Roots 2
Root_0_Spawn_ID 500
Root_0_Weight 10
Root_0_Override
Root_1_Spawn_ID 501
Root_1_Weight 5

Structured format:

Roots
[
    {
        Guid a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d
        IsOverride true
        Weight 10
    }
    {
        Guid b1c2d3e4f5a64a7b8c9d0e1f2a3b4c5e
        IsOverride false
        Weight 5
    }
]

Roots field reference ​

FieldTypeDefaultPurpose
Guiduint128-GUID of the parent spawn table to attach to. Used if LegacySpawnId is unset or zero.
LegacySpawnIduint16-ID of parent spawn table. Use of Guid is encouraged instead.
IsOverrideboolfalseIf true, zeroes the weight of default spawns in the parent spawn table. Useful for mods intended to replace official content.
Weightint32-Weight of this entry in the parent spawn table.

IsOverride flag ​

The IsOverride flag is one of the most powerful features of the spawn table system. When set to true for a root entry, the engine zeroes the weights of all default entries in the parent table. This allows a mod to completely replace a parent table's content rather than simply adding entries alongside the existing ones.

The 57 Studios cohort recommendation for IsOverride usage is to reserve it for total-conversion mods where the mod's intent is to replace official content entirely. For standard mods that add content alongside existing spawns, set IsOverride to false or omit it entirely.

Conditional spawns ​

The spawn table system supports basic conditional behavior through the IsOverride mechanism and through the spawn table hierarchy itself. There is no field-level conditional logic (such as "spawn this item only at night" or "spawn this item only when a specific player is nearby") in the base spawn table format.

The recommended approach for time-based or player-state-based spawn conditions is to use multiple spawn tables with different root weights and to control which table is active through the map's Config.json or the Level Asset configuration. For advanced conditional spawning, server-side plugin code is required.

Naming conventions by map ​

Analysis of the shipped spawn table files reveals consistent naming conventions across all official maps. The conventions help map authors organize spawn tables into a comprehensible hierarchy.

PatternExamplePurpose
{Map}_{Type}Washington_ItemsMap-specific item spawn table
{Map}_{Region}_{Type}AlphaValley_Arena_Ammunition_MilitaryRegion and type within a map
{Category}Food_OrganicCross-map generic category
{Location}_{Category}Lighthouse_SnacksLocation-specific category
{Category}_{Subcategory}Vehicle_SpraypaintsSubcategory within a category

The naming conventions are not enforced by the engine but are valuable for human readability. The 57 Studios cohort recommendation is to adopt a consistent naming scheme for all spawn tables in a mod project. The most robust scheme is {ModPrefix}_{Map}_{Region}_{Type}_{Subtype}, where ModPrefix is a short code that identifies the mod.

Weight distribution examples from shipped files ​

The following examples are taken from empirical analysis of the shipped spawn table files.

Example 1: Airport item table (flat format, higher-level table):

GUID 71a473c050e2436eba63b054f68b81a9
Type Spawn
ID 539

Tables 3
Table_0_Spawn_ID 280
Table_0_Weight 960
Table_1_Asset_ID 1358
Table_1_Weight 20
Table_2_Asset_ID 1359
Table_2_Weight 20

This table has three children. The first child (weight 960) is a spawn table with ID 280, which means 96% of the time the engine recursively processes the child table rather than spawning an item directly from this level. The second and third children (each weight 20) are direct asset references for items 1358 and 1359, representing 2% each.

Example 2: Food Organic table (structured format, leaf-level):

GUID b18d83d25d44459ea94e34c82ee3679d
Type Spawn

Tables
[
    { LegacyAssetId 464 Weight 10 } // Cheese
    { LegacyAssetId 329 Weight 10 } // Carrot
    { LegacyAssetId 335 Weight 10 } // Corn
    { LegacyAssetId 338 Weight 10 } // Lettuce
    { LegacyAssetId 342 Weight 10 } // Potato
    { LegacyAssetId 340 Weight 10 } // Tomato
    { LegacyAssetId 344 Weight 10 } // Wheat
]

This table uses the structured format. Each child has the same weight of 10, meaning each food item has an equal 1/7 (approximately 14.3%) chance of being selected. This is the standard approach for creating a uniform-distribution loot pool.

Example 3: Lighthouse Snacks table (structured format, leaf-level with GUIDs):

GUID 814793db2bea43aa924078c96364885d
Type Spawn

Tables
[
    { Guid e3d11c5882d3407496c264d272acf886 Weight 15 }
    { Guid a829ea9d0ccb4766a4c761e8a1193361 Weight 15 }
    { Guid 2a1350f9ca41402fa0f10297b878cc3c Weight 15 }
    { Guid f81d68ebb2a8490dbe1545d432b9c099 Weight 10 }
    { Guid 4714142193e64af2ae6b5f3f69e3c0ae Weight 15 }
    { Guid 51dc7aaf89d34ebf9b4df35b4ab01d33 Weight 15 }
    { Guid 2c66de826a964b189e34c8e2a56ccb04 Weight 10 }
]

This table uses the recommended GUID-based linking. The weight distribution varies slightly: most items have weight 15, while water-type items have weight 10. This produces a higher probability of food items appearing than drinks.

Exporting legacy spawn tables ​

Maps that were created using the legacy spawn system within the level editor can export their spawn tables as spawn assets. This conversion process is documented in the official SDG modding documentation.

To export legacy spawn tables:

  1. Open the map in the level editor.
  2. Open the pause menu.
  3. Next to the button labeled "LegacySpawns", enter a number above 1000 that should be used as the starting ID for the converted tables.
  4. Click the "Legacy Spawns" button. The engine generates spawn assets based on the legacy spawn tables.
  5. All legacy spawn tables on the map are automatically updated to point to the newly-created spawn assets.
  6. Save the game before exiting.

The generated files appear within a subfolder named Exported_Legacy_Spawn_Tables, located within the map's folder. Root tables are prefixed with the map's name, while the converted tiers are prefixed with the table's name. To start using the converted tables, create a folder named Bundles within the map folder and move the contents of the Exported_Legacy_Spawn_Tables folder into it.

The export process also generates a spreadsheet named IDs.csv that can be used to more easily keep track of the IDs of each spawn asset. The 57 Studios cohort recommendation is to retain this CSV in the map project folder for reference.

Proxy tables ​

The "ProxyTables" button in the export dialog generates empty spawn asset files without converting any legacy data. This is a quick way to get started with creating spawn assets on a newly-created map where there are no legacy spawn tables that need conversion. The generated proxy tables have the correct folder structure and naming conventions but contain no entries; the map author populates each table manually.

Worked examples ​

Worked example 1: Creating a custom weapon spawn table ​

This worked example traces the creation of a spawn table for a custom weapon mod called "Survival Rifle" (item ID 51000, GUID s1r2v3a4l5r6i7f8l9e0g1u2i3d4e5f6). The weapon should appear in military loot spawns but be rarer than standard military weapons.

Create a new spawn table in structured format:

GUID s1p2a3w4n5t6a7b8l9e0g1u2i3d4e5f7
Type Spawn
ID 51001

Tables
[
    {
        Guid s1r2v3a4l5r6i7f8l9e0g1u2i3d4e5f6
        Weight 3
    }
]

Attach this table to a parent military spawn table with a low weight to ensure rarity:

Roots
[
    {
        Guid m1i2l3i4t5a6r7y8p9a0r1e2n3t4g5u
        Weight 5
    }
]

The parent military table has existing children with weights ranging from 10 to 50. With weight 5, this table is selected less frequently than standard military items, making the new rifle an uncommon find.

Worked example 2: Converting a legacy spawn table ​

This worked example traces the conversion of a legacy spawn system on a custom map called "SurvivalValley."

  1. Open the map in the level editor.
  2. Pause the game and note the "LegacySpawns" button.
  3. Enter starting ID 5000 (above the official content range).
  4. Click "LegacySpawns." The engine generates spawn assets in the Exported_Legacy_Spawn_Tables folder.
  5. Create a Bundles folder in the map root. Move the exported files into it.
  6. Open the generated IDs.csv file to see the mapping of old table IDs to new spawn asset names.

The map now uses spawn assets instead of legacy spawn tables. The generated assets can be edited individually to adjust weights, add new entries, or replace legacy IDs with GUIDs.

FAQ ​

Can I mix flat and structured format in the same spawn table? ​

No. A spawn table must use either the flat format (with Tables N declaration) or the structured format (with Tables [ ] array) consistently. Mixing the two formats within the same table produces undefined behavior. The engine attempts to parse the table based on the first format it detects.

How deep should a spawn table hierarchy be? ​

The official documentation does not specify a maximum depth, but practical considerations limit hierarchies to 3-5 levels. A very deep hierarchy (6+ levels) is difficult to maintain and debug. The 57 Studios cohort recommendation is to use at most 4 levels: root (map-wide), region (town/biome), category (loot type), and item (individual asset).

What happens if the total weight across all children is zero? ​

If the sum of all Weight values is zero, the engine cannot select any child. The spawn table effectively produces no output, and no item is spawned. This is a degenerate configuration that should not occur in practice. The 57 Studios cohort recommendation is to ensure that every spawn table's total weight is a positive value.

Can I use a spawn table to spawn other spawn tables? ​

Yes. This is the standard pattern for hierarchical spawn tables. A child entry can reference another spawn table by GUID. The engine recursively processes the child table when that entry is selected. This allows the hierarchy to branch into increasingly specific subtables.

What is the difference between a spawn table and a spawn point? ​

A spawn table is a data file that defines the weighted probability of different items appearing. A spawn point is a location in the map (a vector position) where items can appear. Spawn points reference spawn tables by GUID or ID. The spawn table determines what appears; the spawn point determines where it appears. Multiple spawn points can reference the same spawn table.

How do I add a spawn table to an official map without modifying the map files? ​

Create a new spawn table asset and use the Roots section to attach it to an existing root table on the official map. Set the Weight value to control how often the new table's content appears relative to the official content. Do not use IsOverride unless you intend to replace the official content entirely.

Is there a practical limit to the number of children in a spawn table? ​

There is no hard limit, but performance degrades with very large tables (500+ children) because the engine must sum all weights on each selection. The 57 Studios cohort recommendation is to keep tables under 50 children. For larger item pools, split into multiple tables with a parent table distributing entries among them.

How do I make an item appear in only one region of a map? ​

Create a region-specific spawn table that references the item, then attach that region-specific table to the map's region root table. The region root table distributes loot differently across map regions. This is the standard approach for making certain items exclusive to specific biome or location types.

Best practices ​

  • Use the structured format for all new spawn tables
  • Use GUID-based linking instead of legacy ID-based linking
  • Keep hierarchy depth to 4 levels or fewer
  • Keep individual tables under 50 children
  • Document weight values with // comments in structured format tables
  • Use consistent naming conventions across all spawn tables in a project
  • Maintain the IDs.csv file generated during legacy export for reference
  • Set IsOverride to false (or omit) unless replacing official content
  • Use uniform weights for items that should appear at equal probabilities
  • Test spawn table weights by spawning the table multiple times and recording the distribution

Appendix A: Spawn table format comparison table ​

AspectFlat formatStructured format
SyntaxTables N + Table_N_WeightTables [ ] with { Weight } dictionaries
Child countMust match Tables N declarationInferred from array length
Asset referenceTable_N_Asset_ID or Table_N_GUIDGuid or LegacyAssetId
Sub-table referenceTable_N_Spawn_ID or Table_N_GUIDGuid or LegacySpawnId
Recommended forLegacy maintenance onlyAll new content
Backwards compatibleYesYes (engine supports both)
Human readabilityPoor (index numbering)Good (self-documenting fields)
Error-proneYes (index gaps, count mismatches)No (array handles its own length)

Appendix B: Diagnostic table for spawn table issues ​

SymptomMost likely causeResolution
Item never spawnsTotal weight is zero or GUID is incorrectVerify Weight sum is positive; confirm GUID matches the target asset
Wrong item spawnsIncorrect GUID or legacy ID on the entryVerify GUID in the entry matches the intended asset's .dat GUID field
Spawn table not found in gameRoot not attached or root GUID incorrectVerify Roots section GUID points to an existing parent table
Legacy export produces no filesMap has no legacy spawn tables to convertUse "ProxyTables" button to create empty tables manually
IDs.csv missingExport process did not complete successfullyRe-run legacy export with a valid starting ID above 1000
Item spawns too frequentlyWeight value too high relative to peersReduce weight to be comparable to similar items in the table
Item never despawns after pickupSpawn point misconfigured, not spawn tableCheck spawn point's respawn timer configuration
IsOverride eliminates all official lootIsOverride set to true on a root entryChange to false or remove the flag from the root entry

Appendix C: Spawn table directory structure (shipped files) ​

The shipped spawn table files are organized under Bundles/Spawns/ by category. Each category contains subdirectories for map-specific and generic tables.

Bundles/Spawns/
├── Animals/      ← Animal spawn tables
├── Beacon/       ← Beacon (NPC communication) spawn tables
├── Carepackage/  ← Care package drop spawn tables
├── Fishing/      ← Fishing loot spawn tables
├── Items/        ← Item spawn tables (largest category)
│   ├── Airport_Canada.dat
│   ├── Airport_Peaks.dat
│   ├── Airport_Russia.dat
│   ├── Alien_Guns/
│   ├── Alien_Magazines/
│   ├── Arena_Ammunition_Military.dat
│   ├── Food_Organic.dat
│   ├── Lighthouse_Snacks.dat
│   ├── Lighthouse_Tools.dat
│   └── Vehicle_Spraypaints.dat
├── Resources/    ← Resource node spawn tables
└── Vehicles/     ← Vehicle spawn tables

Appendix D: External references ​

Advanced considerations ​

Spawn table performance at scale ​

When a map has thousands of spawn points and a deep spawn table hierarchy, the cumulative time for weight summation and child selection can become noticeable on server tick performance. The 57 Studios cohort recommendation for large maps is to flatten the spawn table hierarchy where possible, moving from a deep tree structure to a wider, shallower structure. A table with 20 children at a single level is processed faster than a table with 5 children at 3 levels of depth.

Dynamic spawn table swapping through server plugins ​

The base spawn table system does not support dynamic swapping at runtime. Server operators who want to change spawn tables without restarting the server or updating the Workshop item must use an OpenMod or Rocket plugin that intercepts the spawn selection logic and applies its own distribution. The plugin approach is more flexible but requires C# scripting expertise and is outside the scope of the base spawn table format.

Spawn tables and the curated maps program ​

Curated maps that use custom spawn tables should follow the same weight distribution patterns that official maps use. SDG reviewers may flag spawn tables with extreme weight disparities (a common item with weight 1 and a rare item with weight 1000, for example) as balance concerns. The 57 Studios cohort recommendation is to keep the weight ratio between the most common and rarest item in any spawn table within a factor of 100:1.

Authoring checklist ​

Before publishing a map, confirm the following spawn table items:

  • [ ] All spawn tables use GUID-based linking (not legacy IDs)
  • [ ] Structured format is used for all tables (no flat format)
  • [ ] Every table has a valid Roots section attaching to a parent
  • [ ] Total weight in every table is a positive non-zero value
  • [ ] No overlapping root entries with conflicting GUIDs
  • [ ] Hierarchy depth is 4 levels or fewer
  • [ ] Individual tables have 50 children or fewer
  • [ ] Naming convention is consistent across all tables
  • [ ] If converted from legacy, IDs.csv is retained for reference
  • [ ] Weight distribution has been tested by spawning the table multiple times

Document history ​

VersionDateAuthorNotes
1.02026-07-2657 StudiosInitial publication. Complete spawn table format reference with flat and structured formats, weight distribution, root hierarchy design, naming conventions, and FAQ.

Cross-references ​

57 Studios logo with slogan

Beginner-friendly guides for Unturned modding, tools, publishing, server operations, and troubleshooting.

Learn

Getting StartedSteam SetupInstalling Unturned

Explore

ItemsSelf-HostingTroubleshootingHome

Built for Unturned creators, server staff, and 57 Studios™ contributors.

Copyright © 57 Studios™. All rights reserved. 57 Studios™, its branding, guides, and associated original content are protected by applicable copyright and trademark law.