Conditions Reference

Intermediate40-60 minutesWindowsUnturned ServerNotepad++

Conditions are the gatekeeping mechanism that controls when an NPC offers a dialogue response, when an interactable object triggers, and when an item blueprint becomes available for crafting. Every condition evaluates a piece of game state -- a flag value, a player statistic, the time of day, the current weather, the number of zombies a player has killed -- against a target value using a comparison operator. When all conditions in a conditions list evaluate to true, the associated action fires. When any condition in the list evaluates to false, the action is blocked.

This article is the 57 Studios™ canonical reference for the Unturned™ conditions system. It covers every condition type across all three condition categories (flag, player, and world), the common fields shared by every condition, the logic operators, the conditions list syntax, and the specific fields unique to each of the twenty-seven condition types documented in the Smartly Dressed Games modding documentation. The article also covers how conditions interact with dialogue branching and quest progression, and includes worked examples for every condition category.

The conditions system is one of the three core building blocks of dynamic server content -- alongside the rewards system and the dialogue system -- and every mod developer who authors NPC quests, interactive objects, or conditional crafting recipes needs a working understanding of every condition type documented here.

Documentation source: This article references the official Smartly Dressed Games modding documentation for condition field definitions and game behavior. The condition types and parameters documented here correspond to Unturned™ Release 3.x.

Prerequisites

• Completion of Custom NPCs, Dialogues, and Quests or equivalent working knowledge of the NPC, dialogue, and quest asset formats.
• Familiarity with the Unturned flag system and how flags persist in player save data.
• A text editor capable of editing .dat files. See How to Install Notepad++.
• An understanding of GUIDs and the mod folder structure. See Project Folder Structure and GUIDs.
• Approximately one to two hours for a first conditions-authoring pass across a quest chain.

What you'll learn

• The three categories of condition type (flag, player, and world) and when to use each.
• The common fields shared by every condition: Type, Reset, Logic, and UI_Requirements.
• The specific parameters unique to each of the twenty-seven condition types.
• How conditions lists are composed and how multiple conditions interact within a single list.
• How conditions gate dialogue responses, quest progression, blueprint availability, and object interaction.
• How the Logic comparison operators map to real gameplay constraints.
• How to debug a condition that evaluates incorrectly.
• How to use UI_Requirements to selectively display conditions based on other conditions' completion state.

Conditions system architecture

The conditions system sits at the intersection of the NPC system, the interactable object system, and the blueprint crafting system. Every condition list is a set of individual conditions that must all be satisfied simultaneously for the container -- the dialogue response, the object interaction, or the blueprint -- to be available.

All conditions in a conditions list must evaluate to true for the list to pass. There is no OR operator at the conditions-list level. If a mod developer needs an OR gate -- for example, a dialogue response that should be available if the player has either a specific flag OR a specific item -- the developer structures this by creating two separate dialogue responses, each with its own conditions list. The NPC dialogue system evaluates each response independently, so responses with different condition lists function as an OR gate across the dialogue tree.

Conditions list syntax

A conditions list is a block of indexed properties in a .dat file. It starts with a Conditions byte field declaring the total number of conditions, followed by indexed condition properties. Each condition entry uses a prefix that depends on the context in which the conditions list appears.

Context	Prefix pattern	Example
NPC dialogue response	Condition_#_	Condition_0_Type Flag_Bool
Blueprint	Blueprint_#_Conditions_#_	Blueprint_0_Conditions_0_Type Item
Interactable object	Condition_#_	Condition_0_Type Quest
Rewards List Volume	Condition_#_	Condition_0_Type Time_Of_Day

The index starts at 0 and increments sequentially with no gaps. The Conditions byte must exactly match the number of Condition_#_Type entries. A mismatch between the declared count and the actual entries is a silent failure: the parser allocates the declared number of slots, and any missing entries produce default-zero conditions that may or may not pass depending on the condition type and logic operator.

Common condition fields

Every condition type shares four common fields. These fields appear in every condition entry regardless of type and control how the condition is evaluated and displayed.

Field	Type	Required	Default	Purpose
Condition_#_Type	enum	Yes	,	Specifies the condition type. Must be one of the twenty-seven documented type values.
Condition_#_Reset	flag	No	not set	If present, the condition's tracked value resets to its zero-equivalent when the condition completes.
Condition_#_Logic	enum	No	Equal	The comparison operator that determines how the current state is evaluated against the target state.
Condition_#_UI_Requirements	string	No	unset	Comma-separated condition indices. When set, this condition is only displayed in the UI when all referenced condition indices are satisfied. For example, UI_Requirements "1, 2" means the condition is hidden until conditions 1 and 2 have been met.

Logic comparison operators

The Logic field controls how the condition's current state is compared to its target value. The six operators cover every common gameplay constraint.

Operator	Meaning	Example use case
Less_Than	Current state is strictly less than target	Player has fewer than 10 kills
Less_Than_Or_Equal_To	Current state is less than or equal to target	Player has at most 5000 experience
Equal	Current state equals target	Quest is in Ready status
Not_Equal	Current state does not equal target	Player does not have flag 1001 set to true
Greater_Than_Or_Equal_To	Current state is greater than or equal to target	Player has at least 100 reputation
Greater_Than	Current state is strictly greater than target	Player has more than 50 food

The default operator is Equal, which is the most common operator for flag-based conditions (flag equals true, flag equals a specific value) and quest-status conditions (quest status equals Active). The inequality operators are essential for numeric player-state conditions (experience, reputation, health, food, water) and for kill-count progression conditions.

Flag conditions

Flag conditions evaluate the state of a player's flag values. Flags are the persistent numeric state attached to every player save file; they carry values of type boolean, int16, or they can represent a date-counter timestamp. Flag conditions are the primary mechanism for tracking quest progress and gating dialogue branches after key story events.

Flag_Bool

Boolean flag condition. Evaluates whether a specific flag matches a target boolean value. This is the most commonly used condition type in NPC dialogue gating.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Flag_Bool.
Condition_#_ID	uint16	Yes	ID of the flag to check.
Condition_#_Value	bool	Yes	Target value. The condition passes when the flag's current value matches this boolean.
Condition_#_Allow_Unset	flag	No	If present, the condition passes when the player does not have the flag at all. Useful for introductory dialogue that should fire the first time a player speaks to an NPC.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	Reset the flag to its zero-equivalent when the condition completes.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices for UI visibility.

Worked example: A quest NPC shows a congratulatory dialogue message only after the player has completed a prerequisite quest, tracked by flag 100 being set to true.

Conditions 1
Condition_0_Type Flag_Bool
Condition_0_ID 100
Condition_0_Value True
Condition_0_Logic Equal

Worked example with Allow_Unset: A quest-giver NPC shows an introductory message the first time the player speaks to them. The flag 200 is set to true after the first conversation, so on subsequent conversations the condition no longer passes and a different dialogue response is shown.

Conditions 1
Condition_0_Type Flag_Bool
Condition_0_ID 200
Condition_0_Value True
Condition_0_Allow_Unset

Flag_Short

Short flag condition. Evaluates whether a specific 16-bit signed integer flag matches a target value according to the specified logic operator. Flag_Short is the primary mechanism for tracking numeric quest progress -- kill counts, item collection counts, and visit counters.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Flag_Short.
Condition_#_ID	uint16	Yes	ID of the flag to check.
Condition_#_Value	int16	Yes	Target value. The condition passes when the flag's current value satisfies the Logic comparison against this target.
Condition_#_Allow_Unset	flag	No	If present, the condition passes when the player does not have the flag.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	Reset the flag to zero when the condition completes.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A quest requires the player to kill 10 zombies. Flag 301 tracks the kill count. The quest completion condition checks whether flag 301 has reached at least 10.

Conditions 1
Condition_0_Type Flag_Short
Condition_0_ID 301
Condition_0_Value 10
Condition_0_Logic Greater_Than_Or_Equal_To

Worked example with Reset: The same quest condition, but the kill counter resets to zero when the quest is handed in so the player can repeat the quest.

Conditions 1
Condition_0_Type Flag_Short
Condition_0_ID 301
Condition_0_Value 10
Condition_0_Logic Greater_Than_Or_Equal_To
Condition_0_Reset

Compare_Flags

Compare-flags condition. Evaluates two flag values -- a left-hand flag A and a right-hand flag B -- against each other using the specified Logic operator. Compare_Flags is used when one flag's value must be evaluated relative to another flag's value rather than against a static target.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Compare_Flags.
Condition_#_A_ID	uint16	Yes	Left-hand flag ID -- the subject of the comparison.
Condition_#_Allow_A_Unset	bool	No	If true, the condition passes when the player does not have flag A.
Condition_#_B_ID	uint16	Yes	Right-hand flag ID -- the target of the comparison.
Condition_#_Allow_B_Unset	bool	No	If true, the condition passes when the player does not have flag B.
Condition_#_Logic	enum	No	Comparison operator applied between flag A and flag B. Defaults to Equal.
Condition_#_Reset	flag	No	Reset flag A to its zero-equivalent when the condition completes.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A quest requires the player's raider-kill count (flag 400) to exceed their survivor-kill count (flag 401). This gates a faction-reputation dialogue choice.

Conditions 1
Condition_0_Type Compare_Flags
Condition_0_A_ID 400
Condition_0_B_ID 401
Condition_0_Logic Greater_Than

Date_Counter

Date-counter condition. Every in-game morning, Unturned™'s world date counter increments. This condition takes the remainder of the date counter divided by a Divisor and compares it to a Value according to the specified Logic. Date_Counter enables periodic events that fire on specific day cycles.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Date_Counter.
Condition_#_Value	int64	Yes	The target remainder to compare against.
Condition_#_Divisor	int64	Yes	The number to divide the world date counter by before computing the remainder.
Condition_#_Logic	enum	No	Comparison operator applied between the remainder and the target Value. Defaults to Equal.
Condition_#_Reset	flag	No	No operational effect on a world-level counter.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: An NPC merchant restocks a rare item on every fourth and fifth day. The divisor is 5, the target value is 3, and the logic is Greater_Than_Or_Equal_To. The remainder cycles through 0, 1, 2, 3, 4 as the date counter increases; remainders 3 and 4 satisfy the condition, so the merchant shows rare stock on days where remainder >= 3.

Conditions 1
Condition_0_Type Date_Counter
Condition_0_Divisor 5
Condition_0_Value 3
Condition_0_Logic Greater_Than_Or_Equal_To

Worked example with exact day: A seasonal event fires on exactly day 7 of the world. The divisor is 7, the target is 0 (remainder 0 = exactly divisible by 7), and the logic is Equal.

Conditions 1
Condition_0_Type Date_Counter
Condition_0_Divisor 7
Condition_0_Value 0
Condition_0_Logic Equal

The date counter starts at zero in a fresh save and increments by one each in-game morning. The remainder cycles from 0 to (Divisor - 1) and then wraps back to 0. This means that a Date_Counter condition with Divisor 1 and Value 0 passes every day (remainder is always 0 when dividing by 1), and a Divisor equal to the desired cycle length produces one-pass-per-cycle behavior.

Player conditions

Player conditions evaluate properties of the player character: inventory contents, life statistics, skill choices, quest status, and tracked kill counts. These conditions are the mechanism by which NPCs, objects, and blueprints respond to the player's current state.

Currency

Evaluates the player's current balance of a specific currency asset. Uses the GUID of a currency asset to identify which currency to check.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Currency.
Condition_#_GUID	string	Yes	GUID of the currency asset to check.
Condition_#_Value	int	Yes	Target value in terms of currency units.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	No operational effect on currency.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A vendor purchasing dialogue response only appears when the player has at least 500 units of the custom currency with GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d.

Conditions 1
Condition_0_Type Currency
Condition_0_GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d
Condition_0_Value 500
Condition_0_Logic Greater_Than_Or_Equal_To

Experience

Evaluates the player's current experience total against a target value.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Experience.
Condition_#_Value	int	Yes	Target experience value.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	No operational effect on experience.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A training NPC only offers advanced lessons when the player has accumulated at least 10000 experience.

Conditions 1
Condition_0_Type Experience
Condition_0_Value 10000
Condition_0_Logic Greater_Than_Or_Equal_To

Item

Evaluates whether the player's inventory contains a specific item in a specific quantity. This is the standard condition for fetch quests and item-collection objectives.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Item.
Condition_#_ID	uint16	Yes	ID of the item to search the player's inventory for.
Condition_#_Amount	int	Yes	Quantity of the item required.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	No operational effect on inventory contents.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A quest requires the player to collect 5 Eaglefire rifles (item ID 50001).

Conditions 1
Condition_0_Type Item
Condition_0_ID 50001
Condition_0_Amount 5
Condition_0_Logic Greater_Than_Or_Equal_To

Kills_Animal

Evaluates the number of animal kills against a target value, using a short flag to track the kill count. Optionally filters by animal type.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Kills_Animal.
Condition_#_ID	uint16	Yes	ID of a short flag used to track the kill count.
Condition_#_Value	int	Yes	Target value, in terms of animal kills.
Condition_#_Animal	uint16	No	ID of the specific animal required. If omitted, all animal types count.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	Reset the tracking flag to zero when the condition completes.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A hunting quest requires the player to kill 3 deer (animal ID 5). Flag 501 tracks the kill count.

Conditions 1
Condition_0_Type Kills_Animal
Condition_0_ID 501
Condition_0_Value 3
Condition_0_Animal 5
Condition_0_Logic Greater_Than_Or_Equal_To

Kills_Horde

Evaluates the number of horde beacons completed. Optionally scoped to a specific navmesh.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Kills_Horde.
Condition_#_ID	uint16	Yes	ID of a short flag to track the beacon completion count.
Condition_#_Value	int	Yes	Target value, in terms of beacons completed.
Condition_#_Nav	byte	No	Index of the navmesh in which beacons must be completed. Visible in the level editor. Omit to count all navmeshes.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	Reset the tracking flag when the condition completes.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A military faction quest requires the player to complete 2 horde beacons on navmesh index 3.

Conditions 1
Condition_0_Type Kills_Horde
Condition_0_ID 601
Condition_0_Value 2
Condition_0_Nav 3
Condition_0_Logic Greater_Than_Or_Equal_To

Kills_Object

Evaluates the number of objects destroyed. Optionally scoped to a specific object type by GUID and a specific navmesh.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Kills_Object.
Condition_#_ID	uint16	Yes	ID of a short flag to track the destruction count.
Condition_#_Value	int	Yes	Target value, in terms of object destructions.
Condition_#_Object	string	No	GUID of the object required. Omit to count all object types.
Condition_#_Nav	byte	No	Index of the navmesh in which objects must be destroyed. Omit to count all navmeshes.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	Reset the tracking flag when the condition completes.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Kills_Player

Evaluates the number of player kills tracked by a short flag.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Kills_Player.
Condition_#_ID	uint16	Yes	ID of a short flag to track the player-kill count.
Condition_#_Value	int	Yes	Target value, in terms of player kills.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	Reset the tracking flag when the condition completes.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A bounty-hunter NPC only accepts contracts from players who have accumulated at least 5 player kills, tracked on flag 701.

Conditions 1
Condition_0_Type Kills_Player
Condition_0_ID 701
Condition_0_Value 5
Condition_0_Logic Greater_Than_Or_Equal_To

Kills_Tree

Evaluates the number of resource nodes destroyed. Optionally filtered by resource GUID.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Kills_Tree.
Condition_#_ID	uint16	Yes	ID of a short flag to track the destruction count.
Condition_#_Value	int	Yes	Target value, in terms of resource destructions.
Condition_#_Tree	string	No	GUID of the resource required. Omit to count all resource types.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	Reset the tracking flag when the condition completes.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A lumberjack NPC requires the player to fell 20 trees, tracked on flag 801.

Conditions 1
Condition_0_Type Kills_Tree
Condition_0_ID 801
Condition_0_Value 20
Condition_0_Logic Greater_Than_Or_Equal_To

Kills_Zombie

Evaluates the number of zombies killed. Supports filtering by zombie type, navmesh, radius around the player, minimum radius, forced spawn behavior, and level-table override. This is the most parameter-rich player condition.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Kills_Zombie.
Condition_#_ID	uint16	Yes	ID of a short flag to track the zombie-kill count.
Condition_#_Value	int	Yes	Target value, in terms of zombies killed.
Condition_#_Zombie	enum	No	Zombie type filter. Values: Acid, Boss_All, Boss_Electric, Boss_Elver_Stomper, Boss_Fire, Boss_Magma, Boss_Nuclear, Boss_Spirit, Boss_Wind, Burner, Crawler, DL_Blue_Volatile, DL_Red_Volatile, Flanker_Friendly, Flanker_Stalk, Mega, None, Normal, Spirit, Sprinter. Defaults to None, which matches all types.
Condition_#_Spawn_Quantity	int	No	Number of zombies to spawn in the area. Defaults to 1.
Condition_#_Nav	byte	No	Index of the navmesh in which zombies must be killed.
Condition_#_Radius	float	No	Radius around the player within which zombies must be killed, in meters. When both Nav and Radius are unset, defaults to 512 meters.
Condition_#_MinRadius	float	No	Zombies must be killed at least this many meters away from the player.
Condition_#_Spawn	flag	No	If present, the specified zombie type is forcibly spawned upon entering the area and deleted upon leaving.
Condition_#_LevelTableOverride	int	No	Unique ID of a zombie type shown in the level editor. If set, the spawned zombie uses that type. Defaults to -1.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	Reset the tracking flag when the condition completes.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A military NPC requires the player to kill 15 normal zombies within 100 meters of the NPC position, tracked on flag 901.

Conditions 1
Condition_0_Type Kills_Zombie
Condition_0_ID 901
Condition_0_Value 15
Condition_0_Zombie Normal
Condition_0_Radius 100
Condition_0_Logic Greater_Than_Or_Equal_To

Worked example with Spawn: A boss-fight encounter forces the Boss_Fire zombie type to spawn when the player enters the area, then requires the player to kill it. The Spawn flag ensures the boss is always present when the player enters.

Conditions 1
Condition_0_Type Kills_Zombie
Condition_0_ID 902
Condition_0_Value 1
Condition_0_Zombie Boss_Fire
Condition_0_Spawn
Condition_0_Logic Greater_Than_Or_Equal_To

Player life conditions

Five condition types evaluate the player's current survival statistics. Each follows the same pattern: a Type field selecting the stat, a Value field setting the target, and the standard Logic operator.

Condition type	Stat tracked	Value type	Purpose
Player_Life_Food	Current food level	int	Evaluates whether the player's food stat meets a threshold.
Player_Life_Health	Current health	int	Evaluates whether the player's health meets a threshold.
Player_Life_Stamina	Current stamina/energy	int	Evaluates whether the player's stamina meets a threshold.
Player_Life_Virus	Current immunity level	int	Evaluates whether the player's immunity meets a threshold.
Player_Life_Water	Current water level	int	Evaluates whether the player's water stat meets a threshold.

Each of these five condition types takes exactly the same fields: Condition_#_Type (the enum value listed above), Condition_#_Value (an integer target), and the optional shared fields (Logic, Reset, UI_Requirements).

Worked example: A medic NPC only treats players whose health is below 50. The condition uses Less_Than logic to check for a health deficit.

Conditions 1
Condition_0_Type Player_Life_Health
Condition_0_Value 50
Condition_0_Logic Less_Than

Worked example: A survival instructor NPC offers a lesson when the player's food is above 80 (the player has demonstrated resourcefulness).

Conditions 1
Condition_0_Type Player_Life_Food
Condition_0_Value 80
Condition_0_Logic Greater_Than_Or_Equal_To

Quest

Evaluates whether a specific quest is in a target state. Quest condition is the backbone of quest-chain progression gating: a quest's availability is often controlled by the completion status of a prerequisite quest.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Quest.
Condition_#_ID	uint16	Yes	ID of the quest to check.
Condition_#_Status	enum	Yes	The current state the quest must be in. Values: None, Active, Ready, Completed.
Condition_#_Ignore_NPC	flag	No	If present, the player does not need to be within 20 meters of the quest-giver NPC for the quest to be completable and turned in.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	No operational effect on quest state.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: Quest B (quest ID 1002) is only available after Quest A (quest ID 1001) has been completed. The condition gates the quest-offer dialogue response.

Conditions 1
Condition_0_Type Quest
Condition_0_ID 1001
Condition_0_Status Completed
Condition_0_Logic Equal

Worked example with Ignore_NPC: A server-wide bulletin board system allows players to turn in quests from any location. The Ignore_NPC flag removes the proximity requirement.

Conditions 1
Condition_0_Type Quest
Condition_0_ID 2001
Condition_0_Status Active
Condition_0_Ignore_NPC

Reputation

Evaluates the player's current reputation value against a target.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Reputation.
Condition_#_Value	int	Yes	Target reputation value.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	No operational effect on reputation.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A faction-membership NPC only offers enrollment to players with at least 200 reputation.

Conditions 1
Condition_0_Type Reputation
Condition_0_Value 200
Condition_0_Logic Greater_Than_Or_Equal_To

Skillset

Evaluates the player's chosen skillset. The skillset condition enables roleplay servers to offer unique questlines, dialogue branches, or blueprints based on the player's character class.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Skillset.
Condition_#_Value	enum	Yes	Target skillset. Values: Army, Camp, Chef, Farm, Fire, Fish, Medic, None, Police, Thief, Work.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	No operational effect on skillset.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A police-station NPC only offers bounty-hunter quests to players who chose the Police skillset during character creation.

Conditions 1
Condition_0_Type Skillset
Condition_0_Value Police
Condition_0_Logic Equal

Worked example: A chef NPC offers unique cooking blueprints to players with the Chef skillset but a different set of basic recipes to anyone else. The Not_Equal operator gates the non-Chef dialogue branch.

Conditions 1
Condition_0_Type Skillset
Condition_0_Value Chef
Condition_0_Logic Not_Equal

World conditions

World conditions evaluate properties of the game world that are shared across all players: the time of day, the current weather, holiday events, and spatial overlap with level-editor volumes. World conditions are the mechanism for time-gated content, weather-dependent NPC behavior, and location-triggered events.

Holiday

Evaluates whether the current holiday event matches a target holiday enum.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Holiday.
Condition_#_Value	enum	Yes	Target holiday value, as defined in the ENPCHoliday enumeration.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	No operational effect on holiday state.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A seasonal-event NPC appears only during a specific in-game holiday. The condition gates the NPC's visibility; when the holiday is not active, the condition fails and the NPC dialogue is unavailable.

Conditions 1
Condition_0_Type Holiday
Condition_0_Value Halloween
Condition_0_Logic Equal

Is_Full_Moon

Evaluates whether the game world is currently under a full moon. The condition passes when the full-moon state matches the target boolean.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Is_Full_Moon.
Condition_#_Value	bool	Yes	If True, the condition passes when the full moon is active. If False, the condition passes when the full moon is not active.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	No operational effect on moon state.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A werewolf-themed NPC appears only during nights with a full moon.

Conditions 1
Condition_0_Type Is_Full_Moon
Condition_0_Value True

Time_Of_Day

Evaluates whether the current in-game time matches a target second-of-day value. This condition respects the map's configured Bias values and the day/night cycle length, making it the standard mechanism for time-gated NPC availability and event scheduling.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Time_Of_Day.
Condition_#_Second	int	Yes	The target second of a 24-hour clock (military time) to compare against. 0 is midnight (start of day), 43200 is noon, 86400 is midnight (end of day).
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	No operational effect on time.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A night-shift NPC is only available between 8 PM (72000 seconds) and 6 AM (21600 seconds). Two conditions combined: one for the evening threshold and one for the morning threshold. Since both conditions must pass, the NPC is available during night hours.

Conditions 2
Condition_0_Type Time_Of_Day
Condition_0_Second 72000
Condition_0_Logic Greater_Than_Or_Equal_To
Condition_1_Type Time_Of_Day
Condition_1_Second 21600
Condition_1_Logic Less_Than_Or_Equal_To

The second-of-day values for common clock times are:

Clock time	Second value
Midnight (12:00 AM)	0 or 86400
6:00 AM	21600
Noon (12:00 PM)	43200
6:00 PM	64800
8:00 PM	72000

Volume_Overlap

Evaluates whether a target number of players are inside level-editor volumes with a specific ID. Volumes with identical IDs are grouped together. This condition enables location-triggered events and area-based NPC availability.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Volume_Overlap.
Condition_#_VolumeID	string	Yes	ID of the volume or volumes placed in the level editor to test.
Condition_#_PlayerCount	int	Yes	Target number of players in matching volumes to compare against.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	No operational effect.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: A door-interaction object only activates when at least 2 players are inside a pressure-plate volume.

Conditions 1
Condition_0_Type Volume_Overlap
Condition_0_VolumeID PressurePlateRoom
Condition_0_PlayerCount 2
Condition_0_Logic Greater_Than_Or_Equal_To

Weather_Blend_Alpha

Evaluates whether the current intensity (blend alpha) of a specific weather asset meets a target threshold. This condition updates every time the weather intensity changes by 1% (0.01), making it more expensive for visibility than the Weather_Status condition. Use Weather_Blend_Alpha when the NPC or object behavior should scale with weather intensity rather than weather state.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Weather_Blend_Alpha.
Condition_#_GUID	string	Yes	GUID of the weather asset to evaluate.
Condition_#_Value	float	Yes	Target value in the range [0, 1], representing the weather intensity blend. 0.0 is fully absent; 1.0 is fully present.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	No operational effect.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: An umbrella-selling NPC only offers inventory when rain intensity exceeds 50% blend.

Conditions 1
Condition_0_Type Weather_Blend_Alpha
Condition_0_GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d
Condition_0_Value 0.5
Condition_0_Logic Greater_Than_Or_Equal_To

Weather_Status

Evaluates the state of the global weather for a specific weather asset. Weather_Status is the less expensive alternative to Weather_Blend_Alpha for visibility calculations because it only triggers an update on state transitions, not on every 1% intensity change.

Field	Type	Required	Purpose
Condition_#_Type	enum	Yes	Must be Weather_Status.
Condition_#_GUID	string	Yes	GUID of the weather asset to evaluate.
Condition_#_Value	enum	Yes	Target weather status. Values: Active, Fully_Transitioned_In, Fully_Transitioned_Out, Transitioning, Transitioning_In, Transitioning_Out.
Condition_#_Logic	enum	No	Comparison operator. Defaults to Equal.
Condition_#_Reset	flag	No	No operational effect.
Condition_#_UI_Requirements	string	No	Comma-separated list of prerequisite condition indices.

Worked example: An NPC seeks shelter dialogue is available only when rain is fully transitioned in (the rain has finished its fade-in and is at full intensity).

Conditions 1
Condition_0_Type Weather_Status
Condition_0_GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d
Condition_0_Value Fully_Transitioned_In
Condition_0_Logic Equal

Compound conditions and nesting

A single conditions list can contain multiple conditions of different types. All conditions in the list must pass simultaneously for the container action to fire. This allows complex gating that crosses condition categories.

Worked example of compound conditions: A quest offer requires the player to have completed a prerequisite quest (quest condition), have at least 100 reputation (reputation condition), and be speaking to the NPC during daytime hours (time-of-day condition). All three conditions must pass.

Conditions 3
Condition_0_Type Quest
Condition_0_ID 1001
Condition_0_Status Completed
Condition_1_Type Reputation
Condition_1_Value 100
Condition_1_Logic Greater_Than_Or_Equal_To
Condition_2_Type Time_Of_Day
Condition_2_Second 21600
Condition_2_Logic Greater_Than_Or_Equal_To

There is no practical limit on the number of conditions in a single list beyond the constraints of the .dat file format and the parser. Cohort-validated servers in 57 Studios™ production environments have successfully deployed conditions lists with ten or more individual condition entries gating high-value quest rewards.

Conditions in dialogue and quest progression

Conditions connect to the broader NPC system through three integration points: dialogue responses, quest objectives, and interactable objects.

Dialogue response gating

A Dialogue asset contains multiple responses, each of which can have its own conditions list. When the player speaks to an NPC, the NPC system evaluates every response in the dialogue. Responses whose conditions pass are shown to the player. Responses whose conditions fail are hidden. This is the mechanism by which dialogue trees branch based on quest state, flag values, skillset, and every other condition type.

A dialogue response with no conditions is always shown. A dialogue response with conditions is only shown when every condition passes. A dialogue asset containing multiple responses, each with different condition lists, functions as a switch statement -- each response represents a different branch of the conversation, and the branches are mutually invisible when their conditions are not met.

Quest objective gating

The Quest asset's conditions list defines the objectives the player must complete to finish the quest. These conditions are typically player-state conditions (kill counts, item collections) but can also include world conditions (time-of-day constraints). When all quest conditions pass, the quest status advances to Ready, and the player can turn in the quest at the quest-giver NPC.

Interactable object gating

Objects placed in the level editor with an interactability component can carry conditions lists. The interaction prompt only appears when all conditions pass. This enables locked doors, vaults, and event triggers that respond to quest state.

Condition evaluation order and timing

Conditions are evaluated by the engine at the moment the conditions list is checked. For dialogue responses, this occurs when the player initiates conversation with the NPC. For quest objectives, this occurs continuously as the quest is active -- the engine tracks the condition's tracked stat (kill count, inventory content, flag value) and re-evaluates each time the stat changes. For interactable objects, evaluation occurs when the player enters interaction range.

Condition evaluation is instant

There is no polling delay or evaluation cooldown on conditions. When a stat changes -- a flag is incremented, a zombie is killed, an item is picked up -- the condition re-evaluates on the next game tick. The player perceives instant feedback: as soon as the tenth zombie is killed, the quest objective completes and the HUD updates.

The Reset flag behavior

When a condition's Reset flag is set, the tracked value resets to its zero-equivalent at the moment the condition completes. For a Flag_Short condition tracking kill counts, Reset zeroes the flag. For a Flag_Bool condition, Reset sets the flag to false. The Reset flag is essential for repeatable quests -- without it, a quest that requires 10 zombie kills would automatically complete on every subsequent evaluation after the player has killed 10 zombies total in their lifetime, rather than 10 zombies since the quest was accepted.

The cohort recommendation is to set Reset on every quest-objective condition where the quest is intended to be repeatable. For one-time story quests where the objective only needs to be completed once per character lifetime, omit Reset.

Condition authoring checklist

Before testing a conditions list in-game, confirm every entry:

• [ ] Conditions byte matches the exact count of Condition_#_Type entries.
• [ ] Condition indices start at 0 and increment sequentially with no gaps.
• [ ] Every condition has a Condition_#_Type that is one of the twenty-seven valid enum values.
• [ ] Every condition's type-specific fields are spelled correctly and use the correct data type.
• [ ] Condition_#_Logic is appropriate for the type of comparison (checking for a threshold uses Greater_Than_Or_Equal_To, not Equal).
• [ ] Condition_#_Reset is set on repeatable-quest objectives and omitted on one-time story flags.
• [ ] Condition_#_UI_Requirements indices reference condition indices that actually exist in the list.
• [ ] Flag IDs used in conditions are documented in the mod's flag-usage register to avoid collisions.
• [ ] Quest-status condition references use the correct quest ID.

Condition debugging

Conditions that evaluate incorrectly are one of the most common sources of bugs in NPC quest systems. The following diagnostic table covers the most frequent failure modes.

Symptom	Most likely cause	Resolution
Dialogue response never appears	Conditions list logic is impossible (e.g., time window between 72000 and 21600 with And logic always fails)	Verify that compound conditions can all simultaneously pass. For a time window that spans midnight (e.g., 8 PM to 6 AM), use two conditions with Greater_Than_Or_Equal_To on the start time and Less_Than_Or_Equal_To on the end time.
Dialogue response always appears	All conditions pass because flag defaults to the target value	Add a flag-set step earlier in the dialogue chain or change the condition to check for a different value.
Quest objective immediately completes	Flag is already at or above the target from a previous session	Set Reset on the condition so the flag zeroes when the quest is accepted.
Quest objective never completes	Kill-count flag is not being incremented because the zombie type filter is too restrictive or the navmesh is wrong	Remove the zombie type filter temporarily; if kills count then, the filter was excluding kills.
Weather condition never passes	Weather asset GUID is incorrect	Verify the weather asset GUID against the level's weather configuration.
Time-of-day condition passes at wrong time	Day/night cycle length on the server is modified from default	Calculate target second values based on the server's actual cycle length, not the default 86400-second day.
Volume_Overlap condition never passes	Volume ID in the condition does not match level-editor volume IDs	Open the level in the level editor and confirm the volume's ID string matches exactly.
Condition index values are off by one	Misunderstanding that indexing starts at 0	Confirm the first condition is Condition_0_Type, not Condition_1_Type.

Best practices

• Document every flag ID used in conditions in a separate flag-register file that tracks which flag is used for which purpose, by which quest, and whether it resets on completion.
• Use Reset on kill-tracker conditions for repeatable quests and omit it for one-time story flags.
• Use Greater_Than_Or_Equal_To rather than Equal for numeric-progression conditions; a player who overshoots a kill target due to zombie spawn density should still get credit.
• Structure OR-gate logic by creating separate dialogue responses with separate conditions lists, rather than trying to cram OR logic into a single list.
• Use UI_Requirements to hide conditions that would spoil a quest structure -- for example, hide a boss-kill condition until the regular-kill condition is satisfied.
• Test time-of-day conditions at multiple boundary times (exactly at the threshold, one second before, one second after) to confirm the behavior at the edges.
• Assign flag-ID ranges to specific quest chains to prevent collision between unrelated quest flags.
• Avoid using Condition_#_Logic Equal with numeric values unless exact equality is the intended behavior -- Greater_Than_Or_Equal_To is almost always more forgiving for numeric thresholds.
• When using Kills_Zombie with Spawn, confirm that the navmesh area has sufficient spawn-node capacity for the spawned zombies.

Frequently asked questions

What is the difference between Flag_Bool and Flag_Short?

Flag_Bool operates on a boolean (true or false) and is used for binary state tracking: quest completed, NPC met, door unlocked. Flag_Short operates on a 16-bit signed integer and is used for numeric tracking: kill counts, item collection counts, visit counters. Use Flag_Bool for binary gates and Flag_Short for quantity gates.

How do I make a condition that passes only when a flag does NOT equal a value?

Use Condition_#_Logic Not_Equal. For a Flag_Bool condition checking that a flag is not true, set Condition_#_Value False and Condition_#_Logic Equal (which is equivalent to the flag not being true), or use Condition_#_Value True with Condition_#_Logic Not_Equal.

Can conditions reference flags that another mod created?

Conditions reference flags by ID. Any flag ID that exists on the player's save data at the time of evaluation is valid, regardless of which mod created it. The engine does not track the origin of a flag. This means conditions in one mod can gate on flags set by another mod, but this creates a hard dependency between mods that must be documented in the Workshop description.

What happens if a condition references a flag that does not exist?

If the flag does not exist on the player's save data, the condition evaluates against the default value for that flag type: False for a boolean flag, 0 for a short flag. The Allow_Unset flag on Flag_Bool and Flag_Short conditions provides an explicit mechanism for handling missing flags: when Allow_Unset is present, the condition passes when the flag is absent.

Do conditions evaluate on the client or the server?

Conditions evaluate on the server (authority) in multiplayer. The client receives the result of the evaluation -- which dialogue responses to show, which quests are available -- through the regular network replication of NPC and quest state. The player never evaluates conditions client-side; all condition logic runs on the server.

Can I use conditions on blueprints that are not quest-related?

Yes. Blueprint conditions use the same condition types and the same evaluation logic as NPC and object conditions. A blueprint condition that checks Skillset Chef means the blueprint is only craftable by players who selected the Chef skillset. Blueprint conditions use the Blueprint_#_Conditions_ prefix pattern.

What is the maximum value for a Flag_Short?

Flag_Short uses a 16-bit signed integer, so the maximum positive value is 32767 and the minimum negative value is -32768. When tracking kill counts that might exceed 32767 over the lifetime of a server, use multiple flags, rotate the flag ID when the first one caps, or reset the flag periodically.

How do I make a condition that requires the player to have both item A and item B?

Create two separate Item conditions in the same conditions list: one for item A and one for item B. Both must pass, which means the player must have both items in the specified quantities.

Can one dialogue response have no conditions while another response in the same dialogue has conditions?

Yes. This is the standard pattern for a fallback dialogue response: the conditional responses appear first (if their conditions pass), and the unconditional response appears as a catch-all when no conditional response matches. The player sees whichever responses pass their conditions.

How do conditions interact with the quest abandonment system?

When a player abandons a quest, the quest's status changes but the tracking flags are not automatically reset. If the quest's conditions did not use Reset, the flags retain their values from the abandoned quest. If the player re-accepts the quest later, the old flag values are still present and may cause the objectives to immediately complete. For quests that are intended to be abandonable and re-acceptable, use Reset on every objective condition.

Can I combine Kills_Zombie with a specific location and a specific zombie type simultaneously?

Yes. The Kills_Zombie condition supports simultaneous filtering by zombie type (Condition_#_Zombie), navmesh (Condition_#_Nav), and radius (Condition_#_Radius). All three filters are ANDed together: the kill only counts if the zombie type matches, the navmesh matches, and the kill occurs within the specified radius.

How do I test a conditions list without deploying to a live server?

Use the in-game single-player environment with the mod's content loaded. Spawn the NPC or object that carries the conditions list. Use console commands (@give for items, @flag or server admin commands for flag manipulation) to set the player state to what the conditions expect. Test each condition independently, then test them in combination.

Condition evaluation chain diagram

The following Mermaid sequence diagram shows the end-to-end condition evaluation flow when a player interacts with an NPC.

Diagnostic table: condition scope and visibility

Condition type	Scope	Tracks per-player?	Persists after session restart?	Visible in quest HUD?
Flag_Bool	Player	Yes	Yes	By default
Flag_Short	Player	Yes	Yes	By default
Compare_Flags	Player	Yes	Yes	By default
Date_Counter	World	No (shared)	Yes (world state)	By default
Currency	Player	Yes	Yes	By default
Experience	Player	Yes	Yes	By default
Item	Player	Yes (inventory)	Yes (inventory persists)	By default
Kills_Animal	Player	Yes	Yes	By default
Kills_Horde	Player	Yes	Yes	By default
Kills_Object	Player	Yes	Yes	By default
Kills_Player	Player	Yes	Yes	By default
Kills_Tree	Player	Yes	Yes	By default
Kills_Zombie	Player	Yes	Yes	By default
Player_Life_Food	Player	Yes	Yes	By default
Player_Life_Health	Player	Yes	Yes	By default
Player_Life_Stamina	Player	Yes	Yes	By default
Player_Life_Virus	Player	Yes	Yes	By default
Player_Life_Water	Player	Yes	Yes	By default
Quest	Player	Yes	Yes	By default
Reputation	Player	Yes	Yes	By default
Skillset	Player	Yes (read-only)	Yes	By default
Holiday	World	No (shared)	No (event-driven)	By default
Is_Full_Moon	World	No (shared)	No (time-driven)	By default
Time_Of_Day	World	No (shared)	No (time-driven)	By default
Volume_Overlap	World	No (shared)	No (spatial)	By default
Weather_Blend_Alpha	World	No (shared)	No (weather-driven)	By default
Weather_Status	World	No (shared)	No (weather-driven)	By default

Appendix A: Conditions field quick reference

The table below is a condensed reference of every condition type with its unique fields, suitable for quick lookup during authoring.

Condition type	Category	Unique fields	Value type
Compare_Flags	Flag	A_ID, B_ID, Allow_A_Unset, Allow_B_Unset	Comparison between flags
Date_Counter	Flag	Value, Divisor	Remainder vs. value
Flag_Bool	Flag	ID, Value, Allow_Unset	Boolean
Flag_Short	Flag	ID, Value, Allow_Unset	int16
Currency	Player	GUID, Value	int
Experience	Player	Value	int
Item	Player	ID, Amount	int (quantity)
Kills_Animal	Player	ID, Value, Animal	int
Kills_Horde	Player	ID, Value, Nav	int
Kills_Object	Player	ID, Value, Object, Nav	int
Kills_Player	Player	ID, Value	int
Kills_Tree	Player	ID, Value, Tree	int
Kills_Zombie	Player	ID, Value, Zombie, Spawn_Quantity, Nav, Radius, MinRadius, Spawn, LevelTableOverride	int
Player_Life_Food	Player	Value	int
Player_Life_Health	Player	Value	int
Player_Life_Stamina	Player	Value	int
Player_Life_Virus	Player	Value	int
Player_Life_Water	Player	Value	int
Quest	Player	ID, Status, Ignore_NPC	enum
Reputation	Player	Value	int
Skillset	Player	Value	enum
Holiday	World	Value	enum
Is_Full_Moon	World	Value	bool
Time_Of_Day	World	Second	int
Volume_Overlap	World	VolumeID, PlayerCount	int (count)
Weather_Blend_Alpha	World	GUID, Value	float [0,1]
Weather_Status	World	GUID, Value	enum

Appendix B: Time values for common day-cycle thresholds

Clock time (12-hour)	Clock time (24-hour)	Second value	Notes
12:00 AM	00:00	0	Midnight, start of day
1:00 AM	01:00	3600	,
3:00 AM	03:00	10800	,
6:00 AM	06:00	21600	Typical sunrise
9:00 AM	09:00	32400	,
12:00 PM	12:00	43200	Noon
3:00 PM	15:00	54000	,
6:00 PM	18:00	64800	Typical sunset
8:00 PM	20:00	72000	,
9:00 PM	21:00	75600	,
11:00 PM	23:00	82800	,
12:00 AM	24:00	86400	Midnight, end of day

Appendix C: Dialogue response branching with conditions

The following diagram shows how three dialogue responses -- each with a different conditions list -- create a branching conversation tree.

The player sees one or more of the responses whose conditions pass. If Response 0 passes (first-time greeting) and Response 2 passes (fallback), the player sees both and can choose either. If Response 1 also passes, the player sees all three.

Appendix D: External references

• Smartly Dressed Games modding documentation -- official condition field definitions and behavior notes.
• Unturned on Steam -- game page and update changelog.
• Custom NPCs, Dialogues, and Quests -- the end-to-end NPC authoring article; covers the Dialogue, Quest, and Vendor asset formats that consume conditions.
• Rewards Reference -- the next article in this section; covers the reward types that are granted when conditions pass.
• Rewards List Asset Reference -- the grouped-rewards container that references both conditions and individual rewards.
• Currency Asset Reference -- the previous article; documents the currency assets referenced by the Currency condition type.
• Project Folder Structure and GUIDs -- GUID generation and folder layout.

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Complete reference for all 27 condition types across flag, player, and world categories. Includes worked examples, compound-condition guidance, diagnostic table, and time-value reference.

Cross-references

• Currency Asset Reference -- the previous article in this section.
• Rewards Reference -- the next article; covers the rewards that fire when conditions pass.
• Rewards List Asset Reference -- the grouped rewards container; references conditions to gate reward granting.
• Custom NPCs, Dialogues, and Quests -- the NPC system article; conditions are used extensively within dialogue responses and quest objectives.
• Server Config Files: Commands.dat, Players.dat, Config.json -- server configuration that may affect condition-relevant game state (day/night cycle length, weather configuration).
• Smartly Dressed Games modding documentation -- official field reference.
• Unturned on Steam -- game page.