Beacon Asset Reference

Intermediate40-60 minutesWindowsNotepad++Unity Editor

A beacon asset in Unturned™ defines a placeable barricade that, when activated, starts a horde event - a timed wave-based encounter in which the beacon spawns a predetermined number of zombies that the player or player group must eliminate before the beacon can be destroyed. Successful completion rewards the participant or participants with items drawn from a designated spawn table, scaled optionally by the number of players who contributed. Beacons are defined by the ItemBeaconAsset class, which inherits from BarricadeAsset, and are configured entirely through .dat fields in the item's Asset.dat file.

This article is the 57 Studios™ canonical reference for the beacon asset type. It covers every .dat field specific to the beacon asset subclass, the horde event mechanics that govern wave behavior, the reward-scaling system that adjusts difficulty and loot for group play, the barricade inheritance shared with all placeable barricade-type items, and the complete integration between beacon configuration and the underlying zombie spawn system. The shared identity fields that appear on every item asset (ID, GUID, Rarity, Slot, Size_X, Size_Y) are documented in Item Asset Anatomy; this article focuses on the fields that are unique to the beacon subclass and the inheritance from BarricadeAsset.

Documentation source: This article references the official Smartly Dressed Games modding documentation for field definitions and game behavior. Community-validated notes are marked where the official documentation is silent on a detail.

Who this article is for

This article is written for Unturned™ mod authors who have already completed at least one barricade mod and are familiar with the master bundle pipeline and .dat authoring workflow. If you are new to Unturned™ modding, start with Project Folder Structure and GUIDs and How to Install Notepad++ before returning here. An understanding of the barricade system (placement, health, ownership) is assumed; the Objects, Structures, and Barricades Asset Guide covers that prerequisite ground.

What you'll learn

• The full .dat field set for beacon assets, including inherited barricade fields
• How horde events work: wave spawning, mega zombie guarantee, and completion criteria
• How Enable_Participant_Scaling modifies zombie health and reward count for group play
• The relationship between Wave, Rewards, and Reward_ID and how they interact with the spawn table system
• The barricade inheritance chain - which fields beacon assets inherit from BarricadeAsset
• How the wire range, fuel, and power system relate to beacon activation
• The reward distribution model for participant-scaled and fixed-reward beacons
• The server-authoritative behavior of horde events and how it affects mod design

Background: how the horde event system works

The horde event system is Unturned™'s runtime-driven wave combat mechanic. A beacon asset is placed in the world as a barricade item (with Useable Barricade and Build Beacon in its .dat fields). When deployed, it appears as a world-placed device that any player can interact with to start the event. Activating the beacon triggers a wave spawner that continuously spawns zombies within a designated radius around the beacon until the Wave count is reached.

The critical constraint in the horde event system is that the zombie spawner continuously spawns zombies to maintain pressure on the players. If players are not killing zombies fast enough, the wave spawner keeps producing zombies up to the area's spawn cap. The final zombie spawned by a horde event is guaranteed to be a mega zombie, providing a visible and audio-signaled climax to the encounter. If there are not enough zombies in the area for the horde event to meet its Wave target, zombies will respawn continuously until the target is met - the event does not fail solely due to insufficient ambient zombie population.

Participant scaling and health

When Enable_Participant_Scaling is true, the system applies two scaling formulas to balance the encounter for group play. Zombie health scales linearly: an encounter that spawns 10 zombies per participant, for example, would show each zombie with health proportional to the total participant count. The reward count scales with diminishing returns: the formula is 7 × sqrt(Initial Participants), meaning the marginal reward gain decreases as more participants join. A single participant earns 7 reward drops, four participants earn 14, nine participants earn 21, and sixteen participants earn 28 - the reward count grows but at a decreasing rate, which encourages group play without making large groups trivially over-rewarded.

As shown in the flowchart above, the participant scaling switch controls two independent systems: zombie health scales linearly, and reward count scales with diminishing returns.

File and folder structure

A complete beacon mod requires the following files:

Workshop/Content/304930/<modID>/
├── Bundles/
│   └── <BundleName>.unity3d          ← master bundle containing the prefab
└── Items/
    └── MyBeacon/
        ├── Asset.dat                 ← beacon configuration
        └── English.dat               ← display name and description

The folder name, the .dat filename stem, and the internal Name field should all match for consistency, though the engine does not enforce this equality.

Complete .dat field reference

Identity and barricade inheritance fields

Beacon assets inherit all barricade identity fields from BarricadeAsset. The fields below are the minimum identity block for any beacon item.

Field	Type	Example	Required	Purpose
ID	uint16	4010	Yes	Numeric item ID. Must be unique across all loaded mods. Use IDs in the 50000+ range to avoid collision with vanilla and established community mods.
GUID	uint128 hex	a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d	Yes	128-bit globally unique identifier. Generate a new GUID for every new item. Never reuse GUIDs.
Type	enum	Beacon	Yes	Must be Beacon for beacon items.
Useable	enum	Barricade	Yes	Must be Barricade - beacon items are a barricade subtype.
Build	enum	Beacon	Yes	Must be Beacon - this is the build type that drives the placement logic.
Name	string	MyBeacon	Yes	Internal name. Used in console commands and cross-reference in other .dat files.
Rarity	enum	Uncommon	No	Controls the inventory highlight color. Values: Common, Uncommon, Rare, Epic, Legendary, Mythical. Defaults to Common.
Slot	enum	None	No	Beacons are placeable items; they use None because the item is placed in the world, not equipped into a player hand slot.
Size_X	uint8	3	Yes	Width in inventory grid cells.
Size_Y	uint8	3	Yes	Height in inventory grid cells.
Health	uint16	200	No	The hit points of the deployed beacon. When health reaches zero, the beacon is destroyed and the horde event fails.

Barricade placement fields

Beacon assets inherit placement fields from BarricadeAsset. These fields control where and how the beacon can be placed.

Field	Type	Default	Purpose
Range	float	1.0	The maximum placement distance from the player.
Placeable_On_Surfaces	flag	not set	Controls which surface types accept placement (terrain, structure, etc.).
Place_Effect	GUID	not set	Visual effect GUID to play on placement.
Place_Sound	enum	not set	Audio category for the placement sound.

Beacon-specific fields

The fields below are unique to the ItemBeaconAsset class and control the horde event behavior.

Field	Type	Default	Example	Purpose
Wave	uint16	0	50	The number of zombies that must be killed to complete the beacon event. If there are not enough zombies in the area for the horde event to be completed, zombies will respawn continuously to ensure the target number can be met. The final zombie spawned by a horde event is guaranteed to be a mega zombie.
Rewards	byte	0	5	The base number of items to drop upon successfully completing the beacon event. When Enable_Participant_Scaling is true, the actual reward count is modified by the participant scaling formula.
Reward_ID	uint16	0	4011	The legacy numeric ID of the spawn table to use for determining which items to drop as rewards. A value of 0 means no rewards are dropped. For modern mods using GUID-based spawn tables, use Reward_GUID instead.
Reward_GUID	uint128 hex	not set	b9c3d4e5f6a74a8b9c0d1e2f3a4b5c6e	The GUID of the spawn table to use for rewarded items. Modern alternative to Reward_ID. Preferred for new mods because GUIDs do not collide across mods in the same way that legacy IDs do.
Enable_Participant_Scaling	bool	true	true	Whether zombie health and rewards dropped should scale based on the number of players who participated in the horde event. Zombie health scales linearly by participant count. Reward scaling uses the diminishing-returns formula 7 × sqrt(Initial Participants).

Participant scaling defaults to true

The Enable_Participant_Scaling field defaults to true in the engine. If you author a beacon intended for single-player encounters and do not want scaling, you must explicitly set Enable_Participant_Scaling false in the .dat file. Omitting the field leaves scaling active.

The Wave field and zombie respawning

The Wave field defines the total number of zombie kills required to complete the beacon event. The system does not require the player to kill every zombie once; if zombies wander away from the beacon area or are not killed, the spawner continues producing zombies to maintain pressure. Zombies that escape the event area or are killed by environmental damage still count toward the wave progress if they were spawned by the horde event spawner.

The guarantee of a mega zombie as the final spawn means that every beacon encounter ends with a high-HP, high-damage boss-type zombie. The mega zombie spawns when the remaining zombie count reaches one (the final kill target). Players who have killed the preceding wave should be prepared for this climactic spawn.

The Rewards and Reward_ID / Reward_GUID fields

Rewards are items drawn from a spawn table and dropped at the beacon's location on successful completion. The spawn table is identified either by legacy numeric ID (Reward_ID) or by GUID (Reward_GUID). The two fields are alternatives; if both are present, Reward_GUID takes precedence in modern Unturned versions.

The Rewards field is the base count before participant scaling is applied. With Enable_Participant_Scaling true and one participant, the base count equals 7 × sqrt(1) = 7. With four participants, the count equals 7 × sqrt(4) = 14. The scaling always uses the Initial Participants count - the number of participants registered when the event started, not the current live count. This prevents players from manipulating the scaling by joining and leaving mid-event.

Enable_Participant_Scaling: the scaling formula in detail

The participant scaling system adjusts two independent variables.

Variable	Scaling behavior	Formula
Zombie health	Linear per participant	Base_Health × Participants
Reward count	Diminishing returns	7 × sqrt(Participants)

Zombie health scales linearly because the threat presented by a single zombie scales with its hit points. A zombie with 200% base health takes twice as long to kill, giving it roughly twice the chance to land a damaging hit on a player. The linear scaling is intentional: more players means each zombie is more threatening individually, offsetting the numerical advantage of a group.

Reward count scales with diminishing returns because the marginal value of additional rewards drops as group size increases. The formula 7 × sqrt(Participants) produces the following reward counts for common participant numbers:

Participants	Reward count	Drops per participant
1	7	7.00
2	9	4.50
3	12	4.00
4	14	3.50
5	15	3.00
6	17	2.83
8	19	2.38
10	22	2.20
15	27	1.80
20	31	1.55

The table shows that increasing the group size from one to four participants doubles the total reward count while cutting the per-participant drop rate in half. Groups are incentivized to participate together (more total loot is better than one person's solo haul) but the per-player diminishing returns prevent groups from trivializing the reward economy.

Complete .dat example: basic horde beacon

The example below shows a complete beacon configuration for a medium-difficulty horde encounter suitable for group play on a survival server.

ID 50401
GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d
Type Beacon
Useable Barricade
Build Beacon
Name SupplyDropBeacon

Rarity Rare
Slot None
Size_X 3
Size_Y 3
Health 250

Wave 50
Rewards 5
Reward_GUID b9c3d4e5f6a74a8b9c0d1e2f3a4b5c6e
Enable_Participant_Scaling true

Companion English.dat:

Name Supply Drop Beacon
Description Deploy this beacon to call a horde event. Survive 50 waves for loot.

Complete .dat example: single-player challenge beacon

The example below shows a high-difficulty beacon designed for solo or small-group play on a hardcore server, with participant scaling disabled for fixed difficulty.

ID 50402
GUID c2d3e4f5a6b74a8c9d0e1f2a3b4c5d6e
Type Beacon
Useable Barricade
Build Beacon
Name BossArenaBeacon

Rarity Epic
Slot None
Size_X 3
Size_Y 3
Health 500

Wave 100
Rewards 10
Reward_GUID d3e4f5a6b7c84a9d0e1f2a3b4c5d6e7f
Enable_Participant_Scaling false

Companion English.dat:

Name Boss Arena Beacon
Description Triggers a 100-zombie horde event with fixed difficulty. Intended for solo challenge. Mega zombie guaranteed as final wave.

Complete .dat example: loot farming beacon

The example below shows a low-difficulty beacon designed for rapid repeat farming on a PvE server. Low wave count and high reward count per wave make this beacon efficient for farming common loot.

ID 50403
GUID e3f4a5b6c7d84a9e0f1a2b3c4d5e6f7a
Type Beacon
Useable Barricade
Build Beacon
Name LootFarmingBeacon

Rarity Common
Slot None
Size_X 3
Size_Y 3
Health 100

Wave 15
Rewards 3
Reward_GUID f4a5b6c7d8e94a0f1a2b3c4d5e6f7a8b
Enable_Participant_Scaling true

Companion English.dat:

Name Loot Farming Beacon
Description Low-difficulty horde event with quick waves. Best for farming common loot in a group.

Horde event lifecycle and failure modes

A horde event progresses through a defined lifecycle. Understanding each phase is essential for diagnosing player-reported issues with beacon mods.

As shown in the state diagram above, a horde event can end in two failure states (beacon destroyed or timer expired) and one success state (wave target reached). The success state is the only state that triggers reward spawning; failure states produce no loot.

Failure mode 1: beacon destroyed

If the deployed beacon's Health reaches zero before the Wave target is reached, the event fails: no rewards are dropped, the beacon is removed from the world, and all zombies spawned by the event despawn or return to idle behavior. The beacon item is not recoverable - the player must craft or acquire a new beacon item to attempt the event again.

Failure mode 2: timer expired

Each horde event has a runtime timer. The duration is server-defined and is not configurable through the beacon .dat file. If the timer expires before the wave target is reached, the event fails in the same way as the beacon-destroyed failure mode. The server timer is a global configuration that applies to all beacon events on the server.

Success and reward spawn

When the event succeeds, the reward items are spawned at the beacon's location. The items are drawn from the spawn table identified by Reward_ID or Reward_GUID. The reward items are dropped as world items at the beacon's position, distributed slightly around the location to prevent stacking. Players must physically pick up the reward items - they are not sent directly to the player's inventory.

Beacon prefab structure

The Unity prefab for a beacon item follows the same structure as any barricade prefab. The minimum cohort-validated hierarchy is:

MyBeaconPrefab (root, with InteractableBeacon script)
├── Body (MeshRenderer + MeshFilter for the beacon device mesh)
├── Collider (sphere or box collider covering the model volume)
└── Light (optional - visual indicator that the beacon is active while event is running)

The InteractableBeacon script is the Unity-side component that handles player interaction and activation. The script does not require any special configuration beyond being attached to the root of the prefab. The beacon's model should be visually distinct from other placeable barricades so players can immediately recognize it as a horde-event trigger.

Beacon model and visual guidance

Requirement	Details
Polygon budget	500-2000 tris (a compact device, not a large structure)
Scale	Should appear as a handheld device when in inventory and a deployed device slightly smaller than the player model when placed
Pivot origin	At the base of the device - this is the point that aligns with the ground placement surface
Active state visual	Consider including a sub-mesh or material channel that lights up when the beacon is active, giving players a visible confirmation that the horde event is running

The beacon does not need a complex animation rig. A static model with a small light-emitting element is the standard vanilla pattern.

Diagnostic table

Symptom	Most likely cause	Resolution
Beacon cannot be placed in world	Useable field is not Barricade or Build field is not Beacon	Confirm Useable Barricade and Build Beacon in .dat
Beacon placed but cannot be activated	Prefab missing InteractableBeacon script	Attach the script to the prefab root, rebuild bundle
Horde event starts but no zombies spawn	Server spawn cap reached or area has insufficient zombie spawn points	Check server spawn configuration; verify the area is within a zombie spawn zone
Horde event ends immediately after starting	Wave is 0 (no zombies to kill = immediate completion)	Set Wave to a positive value (e.g., 50)
Horde event completes but no rewards drop	Reward_ID is 0 and no Reward_GUID set, or spawn table has no entries	Set Reward_ID or Reward_GUID to a valid spawn table with configured item entries
Rewards drop count does not match expectations	Enable_Participant_Scaling is true and changes the count via the scaling formula	Calculate expected rewards with the formula 7 × sqrt(Participants), then adjust Rewards base field
Beacon is destroyed but zombies persist	Engine-side cleanup may have a delay; zombie despawn can take several seconds	Inform server operators that despawn delay is expected behavior
Mega zombie does not spawn	The wave target may not have been reached; mega zombie only spawns as final zombie	Confirm Wave count is accurate and all zombies have been killed
Reward_GUID is set but rewards are not from the expected table	GUID typo or incorrect GUID assigned	Verify the GUID matches exactly with the target spawn table's GUID - no hyphens
Beacon health depletes too fast	Health set too low relative to expected damage income	Increase Health to 300 or higher for group-play beacons
Participant scaling seems off	Initial Participants count may not match the current active group	Scaling uses the participant count at event start, not current player count

Best practices

• Author Wave values relative to the beacon's intended difficulty tier. A 15-wave beacon is a quick farming encounter; a 100-wave beacon is a boss-level challenge.
• Set Enable_Participant_Scaling true for open-world survival servers where player counts vary. Disable it for fixed-difficulty events (quest beacons, scripted encounters).
• Use Reward_GUID instead of Reward_ID for new beacon mods to avoid legacy ID collisions across mods.
• Keep beacon Health proportional to expected damage: 100 health for a farming beacon, 250 for a mid-tier encounter, 500 or more for a boss arena.
• Test the reward drop count in single-player with Enable_Participant_Scaling true to confirm the scaling formula produces the desired loot volume.
• Pair beacon rewards with a spawn table that includes both common loot (ammunition, food) and rare loot (weapons, attachments) to make the event worthwhile without flooding the economy.
• Document the beacon's difficulty clearly in the English.dat description field so players know what to expect before deploying.
• Position the beacon model so its interaction trigger (the InteractableBeacon collider) is accessible - not buried in terrain or clipping through a floor.
• Set Useable Barricade and Build Beacon exactly as shown in the examples; the parser rejects case variations.
• Generate a fresh GUID for every beacon item and record it in the project's GUID tracking document.

Frequently asked questions

Does the beacon need power or fuel to activate?

No. Beacons are self-contained barricade items that do not require connection to the generator power grid. The activation is purely interaction-based: the player approaches the deployed beacon and presses the interact key. No fuel or electrical infrastructure is needed.

Can the beacon be placed on any surface?

Beacon placement follows the same Placeable_On_Surfaces field set as any barricade item. By default, beacons can be placed on terrain and on the floors of player-built structures. If your beacon design requires placement on walls or ceilings, add the appropriate surface flags to the .dat file. Without explicit surface configuration, the engine applies the standard barricade surface rules.

What happens if a player places two beacons in the same area?

Each beacon is an independent horde event instance. Placing two beacons in the same area produces two simultaneous horde events, each spawning its own set of zombies. This is not recommended for standard gameplay - the combined zombie count can overwhelm a server's spawn cap and produce performance degradation. Some modded server economies use multi-beacon placement as a high-risk, high-reward farming strategy, but this is an advanced server configuration, not a standard beacon feature.

Can I make a beacon that only one player can activate?

Beacon activation is not restricted by the .dat configuration. Any player who is within interaction range of the deployed beacon can activate it. If your mod scenario requires single-player-only activation, that restriction must be enforced at the server level through a plugin that checks the active participant count before allowing the event to start. The beacon .dat file has no ownership or permission field for activation.

Does the beacon remain in the world after the event completes?

Yes. A successfully completed beacon remains in the world as a deployed barricade. The player can pick it up (using the barricade pickup mechanic) and redeploy it elsewhere if the event succeeded. If the beacon was destroyed during the event, it is gone - the item is not recoverable. This distinction means players can reclaim their beacon investment after a successful event but lose it on a failed attempt.

How does the mega zombie guarantee interact with the Wave count?

The mega zombie is the final zombie spawned by the horde event. When the remaining kill count reaches one, the spawner produces a mega zombie instead of a standard zombie. The mega zombie counts toward the Wave target - killing it reduces the remaining count to zero and triggers event completion. The mega zombie is guaranteed regardless of the Wave value; a beacon with Wave 1 spawns a single mega zombie immediately.

Can I set Wave to zero for an instant-completion beacon?

Setting Wave 0 produces a beacon that completes as soon as it is activated - no zombies need to be killed. This is a valid configuration for quest items or scripted encounters where the beacon is a narrative trigger rather than a combat challenge. No rewards are dropped unless Rewards is also configured. The mega zombie is not spawned because the wave target is already met.

What is the practical maximum for Wave?

The Wave field is a uint16, supporting values up to 65535. In practice, values above 500 produce encounters that take a very long time to complete and may exhaust the server's zombie spawn cap before reaching the target. The cohort recommendation for standard gameplay is 15-50 for farming beacons and 50-150 for challenge beacons. Values above 200 are for special event scenarios with dedicated server resources.

Can I have multiple reward tables?

A single beacon can reference only one spawn table (via Reward_ID or Reward_GUID). If you need multiple reward pools (common loot table and rare bonus table), configure the spawn table itself to contain multiple entries with different weights. The spawn table system supports weighted random selection from its entry pool, so a single table can produce varied loot outcomes.

Does participant scaling affect zombie type or zombie spawn rate?

No. Participant scaling modifies only zombie health and reward count. The zombie types spawned by the horde event are determined by the area's zombie configuration, not by the beacon asset. The spawn rate (how frequently zombies are produced) is server-defined and is not adjustable through the beacon .dat. Scaling affects the power of each zombie (more HP per participant) and the economic outcome (more rewards per participant in aggregate), but leaves the zombie composition and encounter pacing unchanged.

What happens to the beacon when the server restarts mid-event?

Beacon state is not persisted across server restarts. If the server restarts while a horde event is active, the deployed beacon reverts to its idle state. The event is effectively canceled. Players must reactivate the beacon after the server comes back online. This is a deliberate design choice to prevent state corruption from mid-event crashes.

Can I make a beacon that drops its rewards directly into player inventories?

No. The reward drop is a world-space item spawn, not a direct inventory injection. The items are dropped as loose objects on the ground near the beacon location. Players must physically collect the drops. If your mod scenario requires direct inventory delivery, that behavior must be implemented through a server plugin; the beacon asset system does not support it.

Appendix A: Beacon asset .dat field quick reference

Field	Type	Required	Default
ID	uint16	Yes	,
GUID	uint128	Yes	,
Type	enum (Beacon)	Yes	,
Useable	enum (Barricade)	Yes	,
Build	enum (Beacon)	Yes	,
Name	string	Yes	,
Rarity	enum	No	Common
Slot	enum	No	None
Size_X	uint8	Yes	,
Size_Y	uint8	Yes	,
Health	uint16	No	Barricade default
Wave	uint16	Yes	0
Rewards	byte	No	0
Reward_ID	uint16	No	0
Reward_GUID	uint128	No	not set
Enable_Participant_Scaling	bool	No	true

Appendix B: Horde event difficulty tiers

The table below provides cohort-validated balance reference values for beacon encounters across difficulty tiers.

Tier	Wave count	Health	Reward base	Participant scaling	Intended use
Farming	10-25	100-150	2-5	true	Quick loot runs, group farming
Standard	25-50	200-300	5-8	true	General-purpose PvE encounters
Challenge	50-100	300-500	8-12	true	Group events, mid-game boss fights
Boss	100-200	500-1000	12-20	false	Fixed-difficulty boss arenas
Narrative	0	100-500	0-2	false	Quest triggers, scripted encounters

Appendix C: External references

• Smartly Dressed Games official modding documentation - Beacon assets - the authoritative field reference for beacon assets.
• Unturned on Steam - the Unturned™ store page and community hub.
• Objects, Structures, and Barricades Asset Guide - covers the barricade inheritance chain and placement mechanics that beacon assets rely on.
• Item Asset Anatomy - shared item identity fields.
• Project Folder Structure and GUIDs - GUID generation and folder layout.
• Master Bundle Export - Unity bundling workflow.
• Spawn Table Asset Reference - the spawn table configuration used by Reward_GUID.

Advanced considerations

Beacon proximity and overlapping event areas

When multiple beacons are deployed within the same zombie spawn zone, the horde event spawners operate independently but compete for the same zombie pool. The engine's zombie spawn cap applies globally: if two simultaneous events each need to spawn 50 zombies, the total spawn count across both events cannot exceed the server's per-zone cap. This can produce the appearance of a stalled event - zombies stop spawning even though the wave target has not been reached - because the secondary event consumes spawn capacity.

The cohort recommendation for multi-beacon scenarios is to separate beacon placement by at least 200 meters to ensure each event operates within a distinct zombie spawn zone. Overlapping events within the same zone produce inconsistent zombie density and may frustrate players who do not understand the spawn-cap interaction.

Beacon as a quest trigger for modded NPCs

The beacon's interaction system can be repurposed as a quest trigger in modded server environments. A beacon with Wave 0 and no rewards becomes a narrative interactable that can be detected by a server plugin to advance quest state. The beacon's deployment, activation, and completion events are all detectable through the server's event hooks, making the beacon a useful building block for quest-driven mod content.

Performance considerations for high-wave beacons

A beacon with a high Wave value (500 or more) spawns a very large number of zombies over its duration. Each zombie requires AI pathfinding, animation, audio, and network synchronization resources. On a server with multiple high-wave beacons active simultaneously, the cumulative load can degrade server performance and produce visible lag for all players. The cohort recommendation is to cap beacon wave counts at 200 for servers with fewer than 16 active players and to reserve higher wave counts for dedicated event servers with performance-optimized configurations.

Appendix D: Beacon reward economy balance

Balancing the beacon reward economy requires tuning the Rewards base value and the spawn table composition together. The table below provides cohort-validated starting points for each beacon tier.

Tier	Rewards base	Spawn table entries	Typical items
Farming	3	3-5 entries	Ammunition, food, bandages, low-tier weapons
Standard	5	5-8 entries	Medical supplies, mid-tier weapons, attachments
Challenge	8	8-12 entries	High-tier weapons, rare attachments, building materials
Boss	12	10-15 entries	Legendary weapons, vehicle keys, rare crafting components

The spawn table should be weighted so that common items occupy roughly 60% of the drop weight, uncommon items 30%, and rare items 10%. This distribution ensures that players are consistently rewarded while maintaining the excitement of rare loot drops. The beacon's Rarity field should match the highest-expected loot tier - a common beacon with a legendary loot table produces a mismatch in player expectations.

Appendix E: Multi-beacon event design patterns

The phased boss fight

Deploy multiple beacons in sequence, where completing one beacon unlocks access to the next. Each beacon has its own wave count, reward profile, and difficulty level. The phased design creates a structured boss-encounter progression that a group of players can work through over an extended play session.

• Beacon 1 (Gate): Wave 20, Rewards 3, common loot, entry-level challenge
• Beacon 2 (Chamber): Wave 40, Rewards 5, uncommon loot, moderate challenge
• Beacon 3 (Boss): Wave 100, Rewards 12, rare loot, high challenge with scaling disabled

The loot cascade

Place multiple beacons in a tight cluster so that a single group activation triggers several simultaneous events. The combined zombie pressure creates a high-risk encounter, but the combined reward drops produce a substantial loot cascade. This pattern requires careful performance testing on the target server to avoid spawn-cap exhaustion.

• Three farming beacons in a 50-meter radius, each Wave 15, Rewards 3
• Combined target: 45 zombies, 9 reward drops spread across three drop locations
• Recommended for groups of 4-8 players with adequate combat gear

The narrative handoff

A single beacon with Wave 0 and no rewards serves as a narrative trigger. The server plugin detects beacon activation and advances a quest stage, spawns an NPC, or opens a previously locked area. The beacon provides a visual, interactable anchor for scripted encounters without engaging the horde event system at all.

Authoring checklist

Before publishing a beacon item to the Steam Workshop, confirm the following:

• [ ] GUID is unique - generated fresh, not copied from another asset
• [ ] ID is in the 50000+ range
• [ ] Type Beacon, Useable Barricade, Build Beacon are all present and correctly spelled
• [ ] Wave is set to a positive value (unless intentional instant-completion design)
• [ ] Reward_ID or Reward_GUID references a valid spawn table (if rewards are desired)
• [ ] Enable_Participant_Scaling is explicitly set according to the intended encounter design
• [ ] Health is set to a value proportional to the intended difficulty
• [ ] Prefab has InteractableBeacon script attached to root
• [ ] Prefab collider covers the model volume correctly
• [ ] Master bundle is built and copied to the mod's Bundles/ folder
• [ ] English.dat is authored with descriptive Name and Description fields
• [ ] Tested in single-player: beacon placed, activated, event runs, rewards drop
• [ ] Tested with group play to verify participant scaling behavior
• [ ] Workshop description documents the beacon's difficulty tier and expected reward types

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Full beacon asset .dat field reference, horde event mechanics, participant scaling, worked examples, FAQ, appendices.

Cross-references

• Placeable Asset Reference - the previous article; covers shared placeable item conventions.
• Farm Asset Reference - the next article; covers the farm asset type, which also inherits from BarricadeAsset.
• Objects, Structures, and Barricades Asset Guide - covers the barricade inheritance chain.
• Item Asset Anatomy - shared item identity fields.
• Project Folder Structure and GUIDs - GUID authoring workflow.
• Master Bundle Export - Unity bundling pipeline.
• Smartly Dressed Games modding documentation - official field reference.
• Unturned on Steam - game page and community.