Vendor Asset Reference

Intermediate40-60 minutesWindowsUnturned ServerNotepad++

The vendor asset is the data definition for every buy-and-sell interface in Unturned™. A vendor asset defines what items an NPC trader will buy from the player, what items the NPC will sell to the player, the cost of each transaction in the configured currency, and the conditions under which each buying or selling slot is available. Vendors are the economic layer of the NPC system: they convert quest rewards and scavenged loot into a meaningful progression loop by giving players destinations where accumulated items and currency can be exchanged for gear, vehicles, and consumables.

This article is the 57 Studios™ canonical reference for the vendor asset type. It covers every .dat field specific to the vendor asset, the buy-list and sell-list configuration patterns, currency linkage, vehicle sales with spawn-point and paint-color overrides, and attachment preconfiguration on sold weapons. The NPC and Dialogue layers that connect to the vendor through the dialogue response system are documented in the Introduction to NPCs and Custom NPCs, Dialogues, and Quests articles. This article focuses on the vendor asset in isolation.

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™ server operators and mod authors who have already authored at least one NPC with a working dialogue tree and are ready to add vendor functionality. If you are new to the NPC system, start with Introduction to NPCs and work through a basic NPC encounter before adding vendor configuration. If you are comfortable with .dat authoring, GUID management, and the dialogue-to-vendor reference chain, this article provides the complete vendor field reference and the configuration patterns that the 57 Studios™ cohort uses on the Horizon Life RP server.

What you'll learn

• The complete vendor .dat field set: identity fields, buying-list fields, selling-list fields, and miscellaneous properties
• How to configure vendor buy lists with per-item costs and per-item conditions
• How to configure vendor sell lists with item and vehicle sale types
• How vendors sell vehicles: spawn-point assignment, paint-color overrides, and attachment preconfiguration
• How currency linking works and how to assign custom currency to a vendor
• The Disable_Sorting flag and its effect on vendor menu presentation
• The vendor face-override system for custom vendor-interface portraits
• How vendor description text overrides item descriptions in the buy and sell interface

Vendor asset identity and structure

A vendor asset is a Type Vendor .dat file that defines a single vendor interface. The vendor asset is referenced by a Dialogue asset's Response_N_Vendor field: when the player selects a dialogue response that carries a vendor ID, the engine opens the vendor interface for that vendor asset. Multiple dialogue responses across different NPCs can reference the same vendor asset, a central marketplace kiosk, for example, could be accessible from any NPC whose dialogue includes a "Browse the marketplace" response pointing to that vendor's ID.

Folder structure

Workshop/Content/304930/<ModID>/
└── NPCs/
    └── ExampleVendor/
        ├── ExampleVendor.dat      ← vendor asset definition
        └── English.dat            ← localization (vendor name, description, per-item descriptions)

The vendor asset's GUID must be unique across all loaded mods. Generate a new GUID for each vendor. See Project Folder Structure and GUIDs for the GUID generation workflow.

Identity fields

Field	Type	Required	Example	Purpose
GUID	uint128 hex	Yes	f7a8b9c0d1e24f35a6b7c8d9e0f1a2b3	128-bit globally unique identifier.
Type	enum	Yes	Vendor	Must be Vendor for vendor assets.
ID	uint16	Yes	50200	Unique numeric ID. Use IDs in the 50000+ range.

Vendor buying configuration

The buying properties define what items the vendor is willing to purchase from the player. Each buying slot defines one item the vendor buys, the cost the vendor pays (in the configured currency), and optional conditions that must be met before the buying slot is available.

Buying list fields

Field	Type	Required	Purpose
Buying	byte	Yes	Total number of items being bought by the vendor. Must match the count of Buying_N_* field groups defined.
Buying_N_ID	GUID or uint16	Yes (per slot)	ID or GUID of the item the vendor is willing to buy from the player.
Buying_N_Cost	uint32	Yes (per slot)	Amount of currency the vendor pays the player for each unit of this item.
Buying_N_Conditions	byte	No (per slot)	Number of conditions that must be met for this buying slot to be available.
Buying_N_Description	Rich Text	No (per slot)	If set, overrides the item's default description text shown in the vendor buy menu.

The Buying field is the counter that tells the engine how many Buying_N groups to parse. If Buying 3 is set, the engine expects Buying_0_*, Buying_1_*, and Buying_2_* field groups. A mismatch between the Buying counter and the actual number of field groups defined causes the vendor to parse an incorrect number of slots, either ignoring defined slots (if Buying is lower than the number of groups) or attempting to parse undefined slots (if Buying is higher).

The Buying_N_Cost field represents the amount the vendor pays the player. In the default configuration (no custom currency), the cost is denominated in experience points. When a custom Currency asset is linked, the cost is denominated in that currency instead. See the Currency Asset Reference for currency configuration and the effect on vendor pricing display.

Buying slot conditions

Buying slots can be gated by conditions just as dialogue messages and responses can. Setting Buying_0_Conditions 1 and defining a condition group (Buying_0_Condition_0_Type, Buying_0_Condition_0_ID, etc.) makes that buying slot appear only when the condition is met. The most common use of buying-slot conditions is quest-gated buying: a vendor that will only buy wolf pelts from the player after the player has accepted the hunting quest. Conditions on buying slots use the same condition types and field naming conventions as dialogue and quest conditions. See the Conditions Reference for the complete conditions system.

The Buying_N_Description field overrides the default item description that appears in the vendor buy interface. The override text is rich text and supports the same <color>, <name_npc>, <name_char>, <br>, and <pause> tags as NPC dialogue. This allows the vendor to describe the item in the vendor's own voice rather than displaying the item's standard inventory description, for example, a vendor buying scrap metal might display a description like "I can melt this down and reuse it. Bring me more." instead of the item's default flavor text.

Vendor selling configuration

The selling properties define what items and vehicles the vendor is willing to sell to the player. Each selling slot defines one item or vehicle the vendor sells, the cost the vendor charges (in the configured currency), and optional conditions and attachment overrides.

Selling list fields

Field	Type	Required	Purpose
Selling	byte	Yes	Total number of items and vehicles being sold by the vendor.
Selling_N_Type	enum	Yes (per slot)	Type of asset being sold. Values: Item or Vehicle.
Selling_N_ID	GUID or uint16	Yes (per slot)	ID or GUID of the item or vehicle to sell to the player.
Selling_N_Cost	uint32	Yes (per slot)	Amount of currency the player must pay the vendor.
Selling_N_Conditions	byte	No (per slot)	Number of conditions that must be met for this selling slot to be available.
Selling_N_Description	Rich Text	No (per slot)	If set, overrides the item description shown in the vendor sell menu.

The Selling_N_Type field distinguishes between item sales (Item) and vehicle sales (Vehicle). Item sales place the purchased item into the player's inventory (if space is available). Vehicle sales spawn a vehicle in the game world at a designated spawn point. The remaining selling-list fields behave identically for both types, but vehicle sales have additional vehicle-specific override fields described in the vehicle sales section below.

Vehicle sale fields

When Selling_N_Type is Vehicle, additional vehicle-specific override fields become available. These fields control where the vehicle spawns, what color it appears in, what ammunition it carries preloaded, and what attachments it has preinstalled.

Field	Type	Required	Purpose
Selling_N_Spawnpoint	string	No	Location to spawn the purchased vehicle, using the ID of a spawnpoint node as set in the level editor. If not provided, the vehicle spawns above the NPC.
Selling_N_PaintColor	color	No	If set, overrides the color of the purchased vehicle. Bypasses both the vehicle redirector asset's SpawnPaintColor and the vehicle asset's DefaultPaintColors.
Selling_N_Ammo	byte	No	Override for the amount of ammunition loaded in the item or vehicle sold. For vehicle-mounted weapons, this controls the starting ammunition in the mounted gun.
Selling_N_Barrel	uint16	No	Override for the barrel attachment that should be attached to the sold item.
Selling_N_Grip	uint16	No	Override for the grip attachment that should be attached to the sold item.
Selling_N_Magazine	uint16	No	Override for the magazine attachment that should be loaded in the sold item.
Selling_N_Sight	uint16	No	Override for the sight attachment that should be attached to the sold item.
Selling_N_Tactical	uint16	No	Override for the tactical attachment that should be attached to the sold item.

The attachment override fields (Selling_N_Barrel, Selling_N_Grip, Selling_N_Magazine, Selling_N_Sight, Selling_N_Tactical) reference attachment items by their numeric ID. When an attachment override is set, the sold item or vehicle spawns with that attachment preinstalled, regardless of the item's default attachment configuration. This allows a vendor to sell a gun with a specific sight, grip, and magazine already attached, a "prebuilt loadout" that the player purchases as a single transaction rather than buying the gun and each attachment separately.

The Selling_N_Spawnpoint field is critical for vehicle sales. It specifies the ID of a spawnpoint node placed in the level editor. The vehicle spawns at that node's location rather than materializing above the NPC. For vehicle vendors that sell large vehicles (helicopters, planes, trucks), placing spawnpoint nodes on open, flat terrain away from the NPC is essential, spawning a helicopter directly above the NPC vendor produces a visually jarring result and can cause the vehicle to collide with nearby structures.

Vehicle spawnpoint is a hard placement requirement

If a vehicle sale is configured without a Selling_N_Spawnpoint and the NPC is indoors or under a low ceiling, the vehicle will spawn above the NPC and collide with the ceiling geometry, causing immediate damage or destruction. Always define a spawnpoint node for vehicle vendors and place the node in an open area with sufficient clearance for the largest vehicle the vendor sells. Test every vehicle sale with each vehicle type the vendor offers before publishing.

The Selling_N_PaintColor field overrides the vehicle's color at the point of sale. When set, it bypasses both the vehicle asset's default paint color and any spawn-paint-color defined in a vehicle redirector asset. This allows the vendor to sell vehicles in a specific color scheme that matches the vendor's faction or brand, a military vendor selling olive-drab vehicles, a civilian vendor selling vehicles in a range of consumer colors.

Other vendor properties

Field	Type	Default	Purpose
Disable_Sorting	flag	not set	Presence of this flag disables the vendor menu's automatic item sorting.
Currency	GUID	not set	GUID of the Currency asset to use as the vendor's currency. If not set, transactions use experience points.
FaceOverride	byte	not set	Optional index of a face image to display when this vendor is opened. The face resets to the NPC character's default face when unspecified or when a new message is shown.

Disable_Sorting

When Disable_Sorting is not present, the vendor menu automatically sorts items in the buy and sell lists, typically alphabetically by item name. When the flag is present, items appear in the order they are defined in the .dat file (Buying_0, Buying_1, Buying_2, ...). Disabling sorting is useful for vendors where the order of items is semantically meaningful: a vendor that sells progressively better gear, with the cheapest items first and the most expensive items last, benefits from the author-controlled ordering that Disable_Sorting preserves.

Currency linking

The Currency field accepts the GUID of a Currency asset. When set, the vendor's buy and sell costs are denominated in the linked currency, and the vendor menu displays item prices using the currency's ValueFormat string. When not set, costs are denominated in experience points and displayed with the default experience-point formatting. See the Currency Asset Reference for the complete currency asset configuration.

Multiple vendors can share the same Currency asset, creating a shared economy across different NPCs. A survival server might have three vendors in three different towns, all using the same BottlecapCurrency asset, so that bottlecaps earned from selling loot to one vendor can be spent at another vendor across the map.

FaceOverride

The FaceOverride field changes the face portrait displayed in the vendor interface. Vendors typically display the NPC character's face (from the NPC asset's Face field) when the vendor interface opens. Setting FaceOverride to a specific face index replaces the NPC's face with the specified face image while the vendor interface is open. This is used for vendors that want a distinct "shopkeeper" portrait that differs from the NPC's normal in-world face. The face resets to the NPC's default when the player closes the vendor interface or when a new dialogue message is displayed.

Vendor localization fields

Vendor localization is defined in the vendor asset's English.dat file, following the same convention as other asset types.

Field	Type	Purpose
Name	string	Vendor name displayed in the vendor interface header.
Description	Rich Text	Vendor description text shown in the vendor interface. Supports rich-text formatting tags.
Buying_N_Description	Rich Text	If set in English.dat, overrides the item's default description for buying slot N. This is an alternative to setting the description in the .dat file.
Selling_N_Description	Rich Text	If set in English.dat, overrides the item's default description for selling slot N.

The Name field is displayed prominently at the top of the vendor interface. The Description field appears below the name and is typically used for the vendor's greeting or shop tagline. Both fields support the same rich-text formatting tags available in dialogue text (<color>, <br>, <pause>, <name_npc>, <name_char>).

Worked vendor .dat example: item vendor

The following example defines a vendor that buys three types of loot from the player and sells four items, using experience points as the default currency.

GUID f7a8b9c0d1e24f35a6b7c8d9e0f1a2b3
Type Vendor
ID 50200

Buying 3
Buying_0_ID 507
Buying_0_Cost 50
Buying_1_ID 508
Buying_1_Cost 75
Buying_2_ID 509
Buying_2_Cost 100

Selling 4
Selling_0_Type Item
Selling_0_ID 400
Selling_0_Cost 200
Selling_1_Type Item
Selling_1_ID 401
Selling_1_Cost 350
Selling_2_Type Item
Selling_2_ID 402
Selling_2_Cost 500
Selling_3_Type Item
Selling_3_ID 403
Selling_3_Cost 750

Companion English.dat:

Name General Store
Description Welcome to the General Store. Buy what you need and sell what you don't.
Buying_0_Description I'll take those old rags off your hands.
Buying_1_Description Scrap cloth, always useful for patching things up.
Buying_2_Description Clean cloth. Pays better than the dirty stuff.

Worked vendor .dat example: vehicle vendor

The following example defines a vendor that sells two vehicles, each with a designated spawn point and a paint color override. The vendor uses a custom currency (GUID of a Currency asset).

GUID a1b2c3d4e5f6478a9b0c1d2e3f4a5b6
Type Vendor
ID 50201

Currency b6b87dfad5f342dc91bbb2de950f56ee

Selling 2
Selling_0_Type Vehicle
Selling_0_ID 91
Selling_0_Cost 5000
Selling_0_Spawnpoint Liberator_Jet
Selling_0_PaintColor 2B2B2B

Selling_1_Type Vehicle
Selling_1_ID 107
Selling_1_Cost 12000
Selling_1_Spawnpoint Helicopter_Pad
Selling_1_PaintColor 3A5C3A

Companion English.dat:

Name Military Surplus
Description Authorized personnel only. Vehicles sold as-is with standard loadout.

Worked vendor .dat example: attachment-preconfigured weapon vendor

The following example defines a vendor that sells a rifle with a preconfigured sight, grip, and magazine, plus a set amount of starting ammunition.

GUID c4d5e6f7081a4b9c2d3e4f5a6b7c8d9e
Type Vendor
ID 50202

Selling 2
Selling_0_Type Item
Selling_0_ID 50100
Selling_0_Cost 2500
Selling_0_Ammo 30
Selling_0_Sight 150
Selling_0_Grip 80
Selling_0_Magazine 50010
Selling_0_Tactical 200

Selling_1_Type Item
Selling_1_ID 50120
Selling_1_Cost 1800
Selling_1_Ammo 15
Selling_1_Sight 170
Selling_1_Magazine 50015

Companion English.dat:

Name Tactical Armory
Description Pre-configured loadouts. Walk out ready to fight.
Selling_0_Description Battle-ready rifle with red dot sight and vertical grip. 30 rounds loaded.
Selling_1_Description Compact carbine with holographic sight. Lightweight and fast-handling.

Complete vendor configuration workflow

The cohort-validated workflow for authoring a vendor asset from scratch:

1. Assign a fresh GUID. Generate a new GUID. Do not reuse a GUID from another asset.
2. Set the identity block. Type Vendor, ID in the 50000+ range.
3. Determine the currency. Leave Currency unset for experience-point-based vendors, or set it to a Currency asset GUID for custom-currency vendors.
4. Define the buy list. For each item the vendor buys, add a Buying_N_ID and Buying_N_Cost pair. Set Buying to the total count.
5. Define the sell list. For each item the vendor sells, add a Selling_N_Type, Selling_N_ID, and Selling_N_Cost triple. Set Selling to the total count.
6. Configure vehicle sales. For each Selling_N_Type Vehicle, add a Selling_N_Spawnpoint referencing a valid spawnpoint node in the level editor. Optionally set paint color and ammunition overrides.
7. Configure attachment overrides. For weapon sales, optionally set sight, grip, magazine, barrel, and tactical attachment overrides.
8. Set conditions (optional). Add Buying_N_Conditions or Selling_N_Conditions fields and their associated condition groups for any slots that should be gated by quest progress, time of day, or other conditions.
9. Author English.dat. Write the vendor's display name, description, and any per-slot description overrides.
10. Reference the vendor from a Dialogue asset. In the Dialogue asset, set Response_N_Vendor to the vendor's ID for the response that should open the vendor interface.
11. Test in-game. Interact with the NPC, open the vendor, and verify that every buy and sell slot appears with the correct item, cost, and condition gating.

Best practices

• Generate a fresh GUID for every vendor asset. Never reuse GUIDs across asset types.
• Set Currency to a Currency asset GUID for any server that uses a custom economy. Leaving it unset forces experience-point transactions, which may not match the server's intended economic model.
• Define Selling_N_Spawnpoint for every vehicle sale and place the spawnpoint node in an open area with sufficient clearance.
• Use Disable_Sorting when the order of buy and sell slots is semantically meaningful (progressively better gear, faction-themed item groups).
• Set a Buying_N_Description or Selling_N_Description override for items where the vendor's in-character voice adds flavor to the transaction.
• Test every vendor slot condition by toggling the relevant quest flags and confirming that gated slots appear and disappear correctly.
• Test every vehicle sale by purchasing each vehicle type and confirming it spawns at the correct location, in the correct color, and without collision damage.
• Keep buy and sell lists to 30 or fewer slots per list for player usability. If a vendor needs more items, split them across multiple vendor assets accessed from different dialogue responses.
• Verify that every referenced item ID or GUID resolves to a loaded item on the server before publishing.
• Set FaceOverride to an appropriate face index for vendors that benefit from a distinct shopkeeper portrait (armory NPCs, faction quartermasters, specialty merchants) rather than using the NPC's default face.
• For vehicle vendors, place spawnpoint nodes on flat, open terrain at least 20 meters from any structure to prevent collision damage on spawn.
• Test vendor transactions with both exact-amount and insufficient-funds scenarios to confirm the vendor interface displays the correct error state in each case.
• Use Buying_N_Description overrides to add in-character vendor dialogue to the buy interface, which improves immersion on roleplay servers.

Advanced vendor design patterns

The faction-locked vendor

A vendor that only appears or only offers its full inventory to players who belong to a specific faction. Implemented through conditions on individual sell slots: each selling slot carries a Selling_N_Conditions group that checks for a quest flag representing faction membership. Players without the flag see the vendor's basic items; players with the flag see the full faction inventory. This pattern allows a single vendor asset to serve multiple player tiers without duplicating the vendor configuration.

To implement a faction-locked vendor, define a boolean quest flag for each faction tier (e.g., flag 100 for "recruit", flag 101 for "veteran", flag 102 for "officer"). Each selling slot's conditions check the appropriate flag. Slots for common items (bandages, basic ammunition) have no conditions and are visible to all players. Slots for restricted items (faction weapons, specialized gear) have conditions gated behind the faction flag. A player who has not joined the faction sees only the common slots; a player who has joined sees the faction-restricted slots as well.

The progressive-tier vendor

A vendor whose inventory expands as the player progresses through a quest chain. Each tier of the quest chain sets a quest flag that unlocks a new set of selling slots. The vendor starts with basic gear and, as the player completes quests, progressively offers better equipment.

This pattern is implemented by incrementing a quest flag ID with each quest completion. The first quest sets flag 200 to 1 (unlocking tier-1 gear). The second quest sets flag 200 to 2 (unlocking tier-2 gear in addition to tier-1). The third quest sets flag 200 to 3 (unlocking tier-3 gear). Each tier's selling slots carry conditions that check whether the flag value is greater than or equal to the tier threshold. The vendor starts with only basic slots, and the inventory grows automatically as the player advances.

The rotating-stock vendor

A vendor whose inventory changes based on in-game time of day or day of the week. A daytime vendor sells standard items; the same vendor at night sells different (or additional) items. A weekend vendor sells items not available on weekdays.

This pattern is implemented through time-of-day conditions (Condition_0_Type Time_Of_Day) on selling slots. Slots with daytime conditions appear during the day and disappear at night. Slots with nighttime conditions appear only at night. The vendor's base slots (with no conditions) are always available regardless of time. This pattern is particularly effective for RP servers where different player populations are active at different times and the vendor economy should reflect that.

The multi-vendor hub

A single NPC dialogue tree that branches into multiple vendor interfaces, giving the appearance of a single NPC who deals in multiple categories of goods. The dialogue presents responses like "Show me your weapons," "Show me your armor," and "Show me your medical supplies," each of which opens a different vendor asset. Each vendor asset is configured with items from only one category.

This pattern improves player experience by reducing the number of items in a single vendor interface (each category vendor has 10-15 slots instead of one vendor with 40+ slots) and by allowing different currencies for different categories (weapons sold for ammunition-currency, medical supplies sold for cash). The NPC uses one NPC asset and one Dialogue asset but references three or more Vendor assets through different dialogue responses.

Authoring checklist

• [ ] Vendor GUID is unique, generated fresh, not copied from another asset
• [ ] Vendor ID is in the 50000+ range
• [ ] Type Vendor is present
• [ ] Buying counter matches the number of Buying_N_* slot groups defined
• [ ] Selling counter matches the number of Selling_N_* slot groups defined
• [ ] Every Buying_N_ID and Selling_N_ID references a valid, loaded item or vehicle
• [ ] Selling_N_Type is set to Item or Vehicle for each selling slot
• [ ] Every vehicle sale has a Selling_N_Spawnpoint referencing a valid spawnpoint node in the level
• [ ] Currency references a valid Currency asset GUID or is left unset for experience-point mode
• [ ] Attachment override IDs reference valid, loaded attachment items
• [ ] English.dat is authored with Name and Description fields
• [ ] Vendor is referenceable from at least one Dialogue asset's Response_N_Vendor field
• [ ] All condition-gated slots are tested with both satisfied and unsatisfied conditions

Diagnostic table

Symptom	Most likely cause	Resolution
Vendor does not open when dialogue response is selected	Response_N_Vendor in the Dialogue asset is 0 or references a non-existent vendor ID	Confirm Response_N_Vendor is set to the target vendor's ID value
Vendor opens but buy or sell lists are empty	Buying or Selling counter is 0 or mismatched with the actual number of slots defined	Confirm Buying and Selling counters match the number of _N_ field groups
Vendor buy or sell list shows wrong item	Buying_N_ID or Selling_N_ID references the wrong item	Confirm the item ID or GUID matches the intended item
Item cost displays as experience points instead of custom currency	Currency field is not set to the Currency asset's GUID	Set Currency to the GUID of the desired Currency asset
Vehicle spawns above the NPC instead of at the spawnpoint	Selling_N_Spawnpoint is not set or references a spawnpoint node that does not exist in the level	Define the spawnpoint and confirm its ID matches the Selling_N_Spawnpoint value
Vehicle spawns with incorrect color	Selling_N_PaintColor is not set or the color value is invalid	Set a valid hex color value in Selling_N_PaintColor
Sold weapon has no attachments	Attachment override fields are not set	Add Selling_N_Sight, Selling_N_Grip, etc. with the attachment item IDs
Condition-gated slot never appears	Condition type or flag ID is incorrect	Confirm the condition type, flag ID, and expected value match what the quest reward sets
Vendor interface shows wrong face	FaceOverride is set to an incorrect face index	Adjust FaceOverride to the intended face index, or omit it to use the NPC's default face
Vendor name is missing or shows placeholder text	English.dat Name field is missing or empty	Add the Name field to the vendor's English.dat
Buy list has fewer items than expected	Buying counter is lower than the number of Buying_N_* groups defined	Increase Buying to match the number of buying slot groups
Sell list has extra blank slots	Selling counter is higher than the number of Selling_N_* groups defined	Decrease Selling to match the number of selling slot groups
Attachment override does not apply to sold weapon	Attachment item ID is 0 or references a non-loaded attachment	Confirm the attachment ID references a valid, loaded attachment item
Vehicle spawns inside a building or structure	Spawnpoint node is placed too close to geometry	Move the spawnpoint node to an open area with at least 5 meters clearance in all directions

Appendix A: Vendor .dat field quick reference

Field	Type	Required	Default
GUID	uint128	Yes	,
Type	enum (Vendor)	Yes	,
ID	uint16	Yes	,
Buying	byte	No	0
Buying_N_ID	GUID or uint16	Per slot	,
Buying_N_Cost	uint32	Per slot	,
Buying_N_Conditions	byte	No	0
Buying_N_Description	Rich Text	No	Item default
Selling	byte	No	0
Selling_N_Type	enum (Item, Vehicle)	Per slot	,
Selling_N_ID	GUID or uint16	Per slot	,
Selling_N_Cost	uint32	Per slot	,
Selling_N_Conditions	byte	No	0
Selling_N_Description	Rich Text	No	Item default
Selling_N_Spawnpoint	string	No (Vehicle only)	Above NPC
Selling_N_PaintColor	color	No	Asset default
Selling_N_Ammo	byte	No	Item default
Selling_N_Barrel	uint16	No	,
Selling_N_Grip	uint16	No	,
Selling_N_Magazine	uint16	No	,
Selling_N_Sight	uint16	No	,
Selling_N_Tactical	uint16	No	,
Disable_Sorting	flag	No	not set
Currency	GUID	No	Experience points
FaceOverride	byte	No	NPC default

Frequently asked questions

What is the default currency if I do not set the Currency field?

Experience points. When the Currency field is not set, the vendor displays item costs as experience-point values and transactions debit or credit experience points from the player's experience total. This is the default behavior for vanilla Unturned™ and for mod vendors that do not need a custom currency system.

How do I link a vendor to a custom currency?

Set the vendor's Currency field to the GUID of the Currency asset you want to use. The Currency asset must be loaded on the server. Once linked, the vendor displays item costs using the currency's ValueFormat string and all transactions (buying from the player, selling to the player) use that currency. See the Currency Asset Reference for currency asset configuration.

Can multiple vendors share the same currency?

Yes. Any number of vendors can reference the same Currency asset GUID. All vendors that share the currency operate in the same economic pool, currency items the player earns from selling loot to one vendor can be spent at any other vendor that uses the same currency. This is the standard pattern for creating a server-wide economy.

What happens if a vehicle spawnpoint does not exist?

If Selling_N_Spawnpoint references a spawnpoint node ID that is not present in the level, the vehicle spawns above the NPC instead of at the spawnpoint location. This is likely not the intended behavior and can produce visual and physics glitches. Always verify that every spawnpoint referenced by a vendor exists in the target map and is placed in an open area with sufficient clearance.

Can I sell items that have conditions on them?

Yes, by setting Selling_N_Conditions and defining the associated condition group. The selling slot only appears in the vendor interface when all conditions in the group are met. The most common use case is quest-gated selling: the vendor sells a specialty item only after the player has completed a specific quest. Conditions on selling slots use the same condition types and field naming conventions as dialogue response conditions.

Do attachment overrides work for vehicles?

The attachment override fields (Selling_N_Sight, Selling_N_Grip, Selling_N_Tactical, Selling_N_Barrel, Selling_N_Magazine) are primarily designed for weapon items. For vehicles with mounted weapons, the Selling_N_Ammo override is the relevant field, it preloads the vehicle's mounted weapon with the specified ammunition count. Attachment overrides for the vehicle itself (as opposed to its mounted weapon) are not supported through the vendor system.

What is the difference between Selling_N_Cost and Buying_N_Cost?

Selling_N_Cost is the amount the player pays the vendor to purchase the item. Buying_N_Cost is the amount the vendor pays the player when the player sells the item. They are independent values, a vendor can buy an item for 10 currency and sell the same item for 50 currency, creating a profit margin that models the NPC trader's markup.

Can a vendor both buy and sell the same item?

Yes. Set a Buying_N_ID and a Selling_N_ID that reference the same item, with different cost values. The item will appear in both the buy and sell tabs of the vendor interface. This is the standard pattern for creating a "trade hub" vendor that deals in a specific type of commodity and is willing to both buy and sell it at different rates.

How many buy and sell slots can a vendor have?

The Buying and Selling fields are byte-typed, meaning each can hold a maximum value of 255. A vendor can have up to 255 buying slots and up to 255 selling slots. In practice, most vendors define between 3 and 30 slots per list, a larger number of slots makes the vendor interface difficult for players to navigate and increases the likelihood of ID and condition-authoring errors.

Does Disable_Sorting affect both buy and sell lists?

Yes. When Disable_Sorting is present, both the buy list and the sell list display items in the order they are defined in the .dat file, without automatic alphabetical sorting. There is no per-list sorting flag, Disable_Sorting applies to the entire vendor interface.

Can I change a vendor's prices after the mod is published?

Yes. Updating the vendor .dat file (changing Buying_N_Cost or Selling_N_Cost values) and republishing the mod updates prices for all players on servers that update their Workshop subscription. There is no version-migration mechanism, the new prices take effect immediately on the next server restart, and any items already purchased at the old price are not refunded or adjusted. The cohort recommendation is to announce price changes to players in advance so they can make purchasing decisions before the update takes effect.

Can a vendor sell items from a different mod?

Yes, provided the other mod is also loaded on the server. Set Selling_N_ID to the GUID of the item from the other mod. The item must resolve to a loaded asset at the time the vendor interface is opened. If the dependency mod is not loaded, the selling slot appears empty. This is commonly used for "hub" Workshop mods that aggregate items from multiple smaller mods into a single vendor interface. Document the dependency mods clearly in your Workshop description so players know which additional mods to subscribe to.

Can I set up a vendor that sells items for free?

Yes. Set Selling_N_Cost 0 for the items you want to give away for free. The vendor will display the cost as 0 currency and the player can "purchase" the item without any currency deduction. This is commonly used for starter-gear vendors that give new players basic equipment, or for quest-reward kiosks where the actual cost was paid through quest completion rather than currency. Use this pattern sparingly, free items eliminate the economic progression loop that vendors are designed to create.

Do vendor prices need to match across multiple vendors selling the same item?

No. Each vendor's Selling_N_Cost is independent of every other vendor. One vendor can sell a bandage for 10 currency while another vendor sells the same bandage for 25 currency. This price variation is intentional in multi-vendor server economies, it creates a reason for players to travel between vendors rather than buying everything from the nearest NPC, and it rewards players who comparison-shop before making a purchase.

How does the vendor determine whether a player can afford an item?

The vendor sums the Value of every currency item in the player's inventory that matches a denomination in the linked Currency asset's Entries array. If the total equals or exceeds the item's Selling_N_Cost, the purchase is allowed. The vendor does not check which denominations the player has, only the total value matters. This means a player with one $50 bill can purchase a $35 item even though they do not have exact change, and the denomination conversion is handled by the engine.

Can I set up a restocking timer so the vendor replenishes sold-out items?

The vanilla vendor system does not have a native restocking timer. Once a selling slot is configured, the item is available for purchase indefinitely, in unlimited quantity (unless gated by a condition). Restocking behavior, limited supply that replenishes over time, must be implemented through server-side plugin logic rather than through the .dat file. The closest vanilla approximation is a vendor that uses time-of-day conditions to make slots available only during certain hours, simulating a daily restock cycle where the vendor "restocks" each day at a designated hour.

How do I create a vendor that only appears during a seasonal event?

Use seasonal conditions on the NPC asset and the dialogue response that opens the vendor. The NPC asset can be configured with Has_Halloween_Outfit or Has_Christmas_Outfit flags, and the dialogue response that opens the vendor can carry time-of-day or seasonal conditions. An NPC that only appears during the Halloween event, with dialogue that only offers the vendor response during that event, effectively creates a seasonal vendor. The vendor asset itself does not have seasonal-awareness fields, the gating is handled at the NPC and Dialogue layers.

What happens if the player's inventory is full when they buy an item?

The item fails to purchase. The vendor deducts the currency but the item cannot be placed into the player's inventory because there is no available slot. The exact behavior (whether the currency is refunded) depends on the game version. The cohort recommendation is to test inventory-full scenarios on your target game version and to warn players through the vendor's description text that inventory space is required before purchasing items, particularly for large items like vehicles.

Can I configure a vendor whose buy and sell prices change dynamically based on supply and demand?

The vanilla vendor system uses static prices defined in the .dat file. Dynamic pricing (prices that increase when stock is low or decrease when the vendor has surplus) is not supported through the .dat system. Servers that want dynamic pricing must implement it through plugin frameworks. The closest vanilla approximation is a progressive-tier vendor that unlocks new selling slots with different prices as the player advances, but the prices within each slot remain static.

Can I reference a vendor asset from multiple different NPC dialogue assets?

Yes. Any Dialogue asset can reference a vendor by its ID through the Response_N_Vendor field. A single vendor asset can be opened from multiple NPCs, multiple dialogue responses, and even from different Workshop mods (provided all mods are loaded on the server and the vendor asset's mod is present). This is the standard pattern for creating a central marketplace hub that is accessible from multiple NPCs across a map. The vendor asset is the shared resource; each NPC that needs access to it references it through its own dialogue tree.

Appendix B: External references

• Smartly Dressed Games modding documentation, official field reference for the vendor asset type.
• Unturned on Steam, game page and changelog; changelog notes vendor system updates.
• Introduction to NPCs, the previous article; NPC system architecture overview.
• Currency Asset Reference, the next article; custom currency configuration for vendor pricing.
• Custom NPCs, Dialogues, and Quests, end-to-end NPC authoring tutorial with vendor examples.
• Conditions Reference, the conditions system used for vendor slot gating.
• 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 vendor .dat field reference, buy/sell list configuration, vehicle sales with spawnpoint and paint override, attachment preconfiguration, currency linking, and diagnostic reference.

Cross-references

• Introduction to NPCs, the previous article; NPC system architecture overview.
• Currency Asset Reference, the next article; custom currency configuration linked by the vendor's Currency field.
• Custom NPCs, Dialogues, and Quests, end-to-end authoring tutorial covering all four asset types including vendors.
• Conditions Reference, the conditions system that gates vendor buy and sell slots.
• Project Folder Structure and GUIDs, GUID generation workflow applicable to vendor assets.
• Item Asset Anatomy, the shared item field reference; the items that vendors buy and sell are item assets.
• Smartly Dressed Games modding documentation, official field reference.
• Unturned on Steam, game page and vendor system changelog.