Crafting Blacklist Asset Reference

Intermediate40-60 minutesWindowsNotepad++Unity Editor

The crafting blacklist asset is the mechanism by which Unturned™ prevents specific items or blueprints from being used in the crafting system. When a crafting blacklist asset is loaded by the engine, it instructs the crafting parser to exclude designated input items, output items, or entire blueprints from the crafting menu. Items that are blacklisted from crafting do not appear in the item quick-actions menu and are not shown in any recipe listing. The blueprint itself remains in the game's data but is invisible and unexecutable from the player's perspective.

57 Studios™ has documented and validated the full crafting blacklist asset configuration surface across the G-008 evidence set of shipped .asset files. This article covers every field that applies to crafting blacklist assets, the evaluation order the engine uses when checking whether a blueprint is blacklisted, the relationship between Input_Items and Output_Items arrays, the Blueprints array that targets individual recipes by name, and the Allow_Core_Blueprints toggle that controls whether vanilla blueprints are subject to the blacklist.

Why blacklists exist in the modding ecosystem

The crafting blacklist asset type was introduced to solve a specific class of server-management and mod-design problems that emerged organically in the Unturned™ modding community. In the early Unturned™ ecosystem, any item that had a blueprint defined could be crafted or salvaged through the crafting menu, and mod authors had no mechanism to selectively disable specific recipes without removing the blueprint definitions themselves. Removing a blueprint definition was a destructive operation: restoring it later required re-authoring the entire blueprint. The blacklist asset provides a non-destructive overlay that temporarily or permanently suppresses blueprints without modifying the underlying blueprint data.

The practical scenarios that motivated the blacklist system include event items that should not be craftable after the event window closes, economy-sensitive salvage blueprints that create resource-positive loops, curated server configurations that restrict which blueprints are available to which player population, and temporary restrictions deployed during server events or competitions. Each of these scenarios shares a common requirement: the ability to suppress a blueprint without deleting its definition and without requiring a full mod rebuild or Workshop update cycle.

G-008 evidence set context

The G-008 evidence set comprises shipped crafting blacklist .asset files from the vanilla Unturned™ asset corpus. These files establish the field conventions and syntax patterns that the 57 Studios™ cohort has validated for mod authoring. The evidence set demonstrates that the crafting blacklist asset uses a flat key-value format with three primary array structures (Input_Items, Output_Items, Blueprints) and one boolean toggle (Allow_Core_Blueprints). The field values in the G-008 files are the authoritative source for correct GUID resolution, array formatting, and the type string that identifies the asset to the engine.

Documentation source: This article references the official Smartly Dressed Games modding documentation for the crafting blacklist asset type definition and the G-008 evidence set of shipped .asset files for field-level validation. Community-validated notes are marked where the official documentation is silent on a detail.

Who this article is for

This article is written for Unturned™ mod authors who have already completed the Blueprint Asset Reference and Crafting Asset Reference articles and are familiar with the blueprint system's recipe structure. If you are new to Unturned™ modding, start with Project Folder Structure and GUIDs and Item Asset Anatomy before returning here. The crafting blacklist is an advanced configuration tool that operates on top of the blueprint system; it is not a starting point for new mod authors.

What you'll learn

• The definition and purpose of a crafting blacklist asset
• How Input_Items prevents items from being consumed as blueprint inputs
• How Output_Items prevents items from being produced as blueprint outputs
• How the Blueprints array prevents specific named blueprints by GUID and name
• How Allow_Core_Blueprints controls whether vanilla blueprints are affected
• The engine evaluation order when checking a blueprint against the blacklist
• How the blacklist interacts with the quick-actions menu
• Complete field reference with type, required/optional status, valid values, and purpose
• Worked .dat examples from shipped G-008 blacklist assets
• Diagnostic table for common blacklist misconfiguration symptoms
• Best practices for deploying blacklist assets on curated servers

How the crafting blacklist system works

The crafting blacklist is evaluated during crafting operations, not at load time. When a player opens the crafting menu and selects a blueprint, the engine performs a three-step check against every loaded crafting blacklist asset before allowing the blueprint to execute:

The evaluation order in the flowchart above is the order the engine processes. If any single blacklist asset blocks the blueprint at any of the three checks, the blueprint is blocked regardless of what other blacklist assets might allow. The blacklist is a veto system, not a whitelist system: one blacklist blocking a blueprint overrides all other considerations. This means multiple blacklist assets loaded simultaneously can each contribute their own restrictions, and a blueprint is executable only if it passes every check in every loaded blacklist asset.

How the blacklist interacts with the quick-actions menu

When a blueprint's input item or output item is blacklisted, the affected item is removed from the quick-actions radial menu that appears when the player right-clicks the item in inventory. This prevents the player from accidentally attempting a blacklisted craft through the quick-action workflow. The item is also hidden from the recipe listing in the full crafting menu, with no visual indicator that a recipe was removed (the recipe simply does not appear). This silent removal is intentional: the blacklist is designed to prevent crafting, not to announce to players that crafting was prevented. A player who does not know a recipe exists cannot attempt to circumvent the blacklist by exploiting a known recipe name.

File structure for a crafting blacklist asset

A crafting blacklist asset follows the same file structure as any Unturned™ asset. The blacklist is a standalone asset file that lives in the mod's Bundles/ directory and is registered by the engine at load time:

Workshop/Content/304930/<modID>/
└── Bundles/
    └── CraftingBlacklist/
        └── CraftingBlacklist.asset      ← blacklist asset definition (fields documented here)

Unlike item assets, crafting blacklist assets do not require a companion English.dat file, a Unity prefab, or a master bundle. The blacklist is a pure data file that the engine's crafting system reads directly. The .asset extension is the convention used by Smartly Dressed Games in the shipped G-008 evidence set, though the parser reads the file regardless of its extension as long as it contains the correct field set.

The blacklist asset file can be named arbitrarily. The naming convention from the shipped G-008 blacklist files is to use a descriptive name that indicates what the blacklist restricts (e.g., DisallowSalvageChefHat.asset, HideOrangeHoodieFromCrafting.asset). Multiple blacklist asset files can coexist in the same Bundles/ folder, and the engine evaluates all of them against every blueprint.

Complete crafting blacklist .asset field reference

Identity and type fields

Every crafting blacklist asset requires an identity block that identifies the asset to the engine. These fields follow the same conventions as item asset identity fields but use the CraftingBlacklist type string.

Field	Type	Required	Example	Purpose
GUID	uint128 hex	Yes	67c76cdf16024bf68b6e5d14d4c617ab	128-bit globally unique identifier. The GUID is the stable cross-reference used by the engine's crafting system to register and reconcile blacklist assets.
Type	enum	Yes	CraftingBlacklist	Must be the exact string SDG.Unturned.CraftingBlacklistAsset or the shorthand accepted by the parser. The type string signals to the engine which asset subclass to instantiate.

Blacklist evaluation context and lifecycle

The crafting blacklist is evaluated in the context of the full asset registry, not in isolation. When the engine starts or reloads Workshop content, it scans all Bundles/ directories across all loaded mods, identifies files whose Type field matches the crafting blacklist type string, and registers each blacklist asset in a dedicated blacklist registry separate from the main item asset registry. The blacklist registry is consulted during every crafting operation but is not consulted during item loading, inventory management, or item dropping. This scope limitation means a blacklisted item can exist in a player's inventory, be dropped, be traded, and be equipped without restriction - the blacklist applies only when the player attempts to use that item in a crafting operation.

The lifecycle of a blacklist entry is tied to the asset load cycle. When a mod is added or removed from a server, the blacklist registry is rebuilt during the next content reload. Players who are currently in the crafting menu when the blacklist changes will see the updated restrictions when they close and reopen the menu. There is no real-time update mechanism; the crafting menu reflects the blacklist state that was current when the menu was opened.

Input_Items array

The Input_Items array is one of three restriction mechanisms the crafting blacklist supports. It lists items that, when used as a blueprint input, cause any blueprint consuming them to be blocked. The field accepts an array of item references using GUID-based pointers.

Sub-field	Type	Required	Example	Purpose
Input_Items	array	No	See below	Array of item GUID pointers. Any blueprint that consumes at least one of these items as an ingredient is blocked from crafting.

The array syntax for Input_Items follows the Unturned™ array convention. Each entry is an item GUID. The array is enclosed in square brackets, with individual items listed as GUID strings or as GUID values inside optional curly braces:

Input_Items
[
    // Orange Hoodie
    "GUID" "67c76cdf16024bf68b6e5d14d4c617ab"

    // Individual items can also be enclosed in brackets { }
    {
        // Eaglefire
        GUID b03d581a5c1a490f995f8deba57b0f17
    }

    // Jeans
    dab78cc4d66645bfb8169be7c15cf876
    55c69817a31448b685c7f788ec7d2d0c
    bdae9d26ca704d729b2b0f34812d2a36
    67a6ec52e4b24ffd89f75ceee0eb5179
]

The array syntax supports three equivalent formats for each entry:

Input format	Example	Notes
Bare GUID string	dab78cc4d66645bfb8169be7c15cf876	The GUID value alone, without a key prefix. The parser reads it as an item pointer.
Quoted GUID with "GUID" key	"GUID" "67c76cdf16024bf68b6e5d14d4c617ab"	A key-value pair with GUID as the key. The quotes around both key and value are optional in most parser versions but are used in shipped G-008 files for consistency.
Bracketed block with GUID field	{ GUID b03d581a5c1a490f995f8deba57b0f17 }	A full block with the GUID as a named field. This format is equivalent to the other two and is used when additional metadata fields may be added in future parser versions.

All three formats parse to the same runtime representation: an item GUID reference. The cohort recommendation from the shipped G-008 files is to use the bracketed block format for readability and forward compatibility.

Understanding array capacity and entry limits

The Input_Items and Output_Items arrays do not have a documented hard limit on the number of entries the parser can process. The shipped G-008 evidence set includes arrays with up to six entries in a single array, and the engine's parser uses a general-purpose array reader that processes entries until the closing bracket. In practice, arrays with hundreds of entries are not expected to cause parse failures, but the cohort recommendation is to keep each array to a manageable number of entries (fewer than fifty per blacklist asset) and to split restrictions across multiple blacklist asset files when the number of entries grows beyond that threshold. The rationale is not parser capacity but maintainability: a blacklist with hundreds of GUID entries is difficult to audit, and a single erroneous GUID is difficult to locate.

The array syntax distinguishes between the opening bracket, the individual entries, and the closing bracket. The opening bracket must appear on the line immediately after the array field name (Input_Items or Output_Items), with no space between the field name and the bracket line. The closing bracket must be on its own line. Entries within the array can use any of the three supported formats (bare GUID, quoted key, or bracketed block) and can be mixed within the same array. The parser processes entries sequentially from top to bottom, and duplicates within the same array are silently accepted without error (the duplicate GUID is registered once, and the second occurrence has no effect).

Output_Items array

The Output_Items array lists items that, when produced as a blueprint output, cause any blueprint generating them to be blocked. This is the inverse of Input_Items: instead of preventing an item from being consumed as an ingredient, it prevents the item from being created by any recipe.

Sub-field	Type	Required	Example	Purpose
Output_Items	array	No	See below	Array of item GUID pointers. Any blueprint that produces at least one of these items as output is blocked from crafting.

The array syntax for Output_Items is identical to Input_Items in structure:

Output_Items
[
    "GUID" "a6099002318e4d58b8e59d431bcf1b8a"
]

The evaluation distinction between Input_Items and Output_Items is subtle but important for understanding which blueprints are blocked. An item placed in Input_Items blocks every blueprint that consumes that item as an ingredient, regardless of what the blueprint produces. An item placed in Output_Items blocks every blueprint that produces that item, regardless of what ingredients the blueprint consumes. Both arrays can target the same item for different purposes: blocking the item's use as input blocks all recipes that consume it; blocking its production as output blocks all recipes that create it.

Blueprints array

The Blueprints array is the most specific restriction mechanism. Instead of blocking all blueprints that use a particular input or output item, it targets individual named blueprints on specific items. Each entry in the array identifies one item and one blueprint on that item, preventing that blueprint from being executed while leaving other blueprints on the same item unaffected.

Sub-field	Type	Required	Example	Purpose
Blueprints	array	No	See below	Array of blueprint restriction objects. Each entry specifies an item GUID and either a BlueprintName string or a Blueprint index.

Each entry in the Blueprints array is a bracketed block with two sub-fields:

Blueprints
[
    {
        Item a6099002318e4d58b8e59d431bcf1b8a
        BlueprintName Salvage
    }
]

The Item sub-field is the GUID of the item that owns the blueprint. The BlueprintName sub-field is the name assigned to that blueprint in the item's blueprint configuration. The Blueprint sub-field (alone, without Name) is the numeric index of the blueprint in the item's blueprints list. The official documentation strongly recommends using BlueprintName instead of Blueprint index, because indices shift when the item's blueprint list is reorganized, while names remain stable across reorganization.

Sub-field	Type	Required	Example	Purpose
Item	uint128 GUID	Yes	a6099002318e4d58b8e59d431bcf1b8a	The GUID of the item whose blueprint is being blacklisted.
BlueprintName	string	Use one	Salvage	The name of the blueprint to blacklist. Must match the Name field defined in the item's blueprint configuration.
Blueprint	int	Use one	0	The zero-based index of the blueprint in the item's blueprints list. Fragile; use BlueprintName instead.

The shipped G-008 evidence set includes an example that prevents the Chef Hat from being salvaged. The Chef Hat item has a Salvage blueprint that converts it back into its base materials. Blacklisting that specific blueprint by name prevents salvage while leaving other Chef Hat blueprints (if any exist) unaffected.

Blueprint targeting strategies

The Blueprints array supports two targeting strategies: by name and by index. Each strategy has distinct use cases, advantages, and risks that the mod author should understand before choosing one over the other.

Name targeting uses the BlueprintName sub-field and matches against the Name field defined in the target item's blueprint configuration. A blueprint's name is assigned when the blueprint is authored, typically in the item's blueprint .dat file. The name is a human-readable string that describes the blueprint's purpose, such as Salvage, Craft, Upgrade, or Repair. When the item's blueprint list is reorganized - blueprints are added, removed, or reordered - the name-based reference remains valid as long as the blueprint's Name field is not changed. The official documentation explicitly recommends name targeting over index targeting for this stability reason.

Index targeting uses the Blueprint sub-field with a zero-based integer that identifies the blueprint's position in the item's blueprints list. The first blueprint in the list has index 0, the second has index 1, and so on. Index targeting is fragile because any change to the blueprint list order shifts the indices of every blueprint after the insertion or deletion point. A blueprint that was at index 0 before a new blueprint was prepended moves to index 1, and any blacklist entry still targeting index 0 now blocks the wrong blueprint.

Targeting strategy	Sub-field	Stability	Use case
By name	BlueprintName	High - stable across blueprint list reorganization	Preferred strategy for all new blacklist assets
By index	Blueprint	Low - changes when blueprint list is reorganized	Legacy blacklists or when blueprint has no Name field

Allow_Core_Blueprints field

Field	Type	Required	Default	Purpose
Allow_Core_Blueprints	bool	No	true	Controls whether the blacklist applies to blueprints from the vanilla/built-in item set. When set to false, the blacklist restrictions also apply to blueprints defined by vanilla Unturned™ items.

The Allow_Core_Blueprints field is the top-level gate for whether the blacklist extends to core (vanilla) items. The default value of true means the blacklist does not affect vanilla blueprints by default, only mod-defined blueprints. Setting Allow_Core_Blueprints false extends the blacklist restrictions to vanilla blueprints, allowing mod authors to prevent players from salvaging or crafting vanilla items through the crafting menu.

The cohort recommendation is to leave Allow_Core_Blueprints at its default (true) unless the mod explicitly needs to restrict vanilla crafting. Restricting vanilla blueprints is a significant gameplay intervention that affects every player on the server, and it should be documented clearly in the mod's Workshop description.

Blacklist field interaction with other asset types

The crafting blacklist asset interacts with several other asset types in the Unturned™ modding ecosystem. Understanding these interactions is important for mod authors who deploy blacklists alongside other configuration assets.

Blueprint asset interaction. The blacklist's Blueprints array directly references the Name field on blueprint entries defined in item asset files. If an item's blueprint configuration does not include a Name field, the blueprint can be blacklisted only by index. The cohort recommendation is to add a Name field to every blueprint, even if the blueprint is not expected to be blacklisted, because the name field enables future blacklist targeting without requiring a blueprint re-authoring cycle.

Item asset interaction. The Input_Items and Output_Items arrays reference items by their GUID, which is defined in the item's .dat file. If an item's GUID changes (which should never happen after the item is published, but may occur during development), the blacklist entry referencing the old GUID becomes a dead entry that has no effect. The engine does not warn about unresolved GUIDs in the blacklist arrays; they are silently skipped during load.

Crafting asset interaction. The broader crafting system defines the recipes, ingredients, and outputs that the blacklist constrains. The crafting system is documented in the Crafting Asset Reference article, which is the prerequisite reading for understanding which specific blueprints a blacklist should target.

Spawn table interaction. The crafting blacklist does not affect spawn tables. An item that is blacklisted from crafting input can still appear in loot spawns, vehicle storage, and player inventories. The blacklist is a crafting-only restriction; it does not remove items from the world or prevent players from finding them through exploration.

Complete .asset example: prevent salvaging specific items

The following example demonstrates a crafting blacklist that prevents the salvage operation on a specific item (Chef Hat) using the Blueprints array. This is the pattern used in the shipped G-008 evidence set:

GUID a6099002318e4d58b8e59d431bcf1b8a
Type SDG.Unturned.CraftingBlacklistAsset

Blueprints
[
    {
        Item a6099002318e4d58b8e59d431bcf1b8a
        BlueprintName Salvage
    }
]

Complete .asset example: hide multiple items from crafting input

The following example demonstrates a crafting blacklist that prevents multiple items from appearing as crafting inputs, effectively hiding them from the quick-actions menu and blueprint recipe listings:

GUID 67c76cdf16024bf68b6e5d14d4c617ab
Type SDG.Unturned.CraftingBlacklistAsset

Input_Items
[
    "GUID" "67c76cdf16024bf68b6e5d14d4c617ab"

    {
        GUID b03d581a5c1a490f995f8deba57b0f17
    }

    dab78cc4d66645bfb8169be7c15cf876
    55c69817a31448b685c7f788ec7d2d0c
    bdae9d26ca704d729b2b0f34812d2a36
    67a6ec52e4b24ffd89f75ceee0eb5179
]

This example blacklists six items from being used as crafting inputs. The first item uses the quoted GUID key format. The second uses the bracketed block format. The remaining four items use the bare GUID string format. All three formats are equally valid and produce the same runtime behavior. The engine processes the Input_Items array at load time and registers each GUID as a blocked input item.

Complete .asset example: combination blacklist

The following example combines all three restriction mechanisms in a single blacklist asset. This is the pattern used for comprehensive blacklists that restrict items from input, production, and specific blueprints simultaneously:

GUID 7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d
Type SDG.Unturned.CraftingBlacklistAsset

Allow_Core_Blueprints false

Input_Items
[
    {
        GUID 67c76cdf16024bf68b6e5d14d4c617ab
    }
    b03d581a5c1a490f995f8deba57b0f17
]

Output_Items
[
    "GUID" "a6099002318e4d58b8e59d431bcf1b8a"
]

Blueprints
[
    {
        Item a6099002318e4d58b8e59d431bcf1b8a
        BlueprintName Salvage
    }
    {
        Item 67c76cdf16024bf68b6e5d14d4c617ab
        Blueprint Index 0
    }
]

This combination blacklist:

• Sets Allow_Core_Blueprints false, extending restrictions to vanilla items
• Blocks two items from being used as crafting inputs
• Blocks one item from being produced by any blueprint
• Blocks the Salvage blueprint on one item by name
• Blocks the first blueprint index on another item

Example: combining all three restriction types in a production blacklist

The following production-grade blacklist combines the Input_Items, Output_Items, and Blueprints arrays with explicit Allow_Core_Blueprints configuration. This blacklist is designed for a curated survival server where certain items are restricted from the crafting economy:

GUID f1e2d3c4b5a6978807162534a1b2c3d4
Type SDG.Unturned.CraftingBlacklistAsset

Allow_Core_Blueprints false

Input_Items
[
    {
        GUID 67c76cdf16024bf68b6e5d14d4c617ab
    }
    b03d581a5c1a490f995f8deba57b0f17
    dab78cc4d66645bfb8169be7c15cf876
]

Output_Items
[
    "GUID" "a6099002318e4d58b8e59d431bcf1b8a"
]

Blueprints
[
    {
        Item a6099002318e4d58b8e59d431bcf1b8a
        BlueprintName Salvage
    }
    {
        Item 67c76cdf16024bf68b6e5d14d4c617ab
        BlueprintName Craft
    }
]

This blacklist blocks three items from being used as blueprint inputs, blocks one item from being produced as blueprint output, and specifically disables the Salvage blueprint on one item and the Craft blueprint on another. The Allow_Core_Blueprints toggle is set to false, extending all restrictions to vanilla blueprints. The blacklist is self-contained in a single file and can be deployed or removed by adding or removing the file from the mod's Bundles/ directory.

Input_Items, Output_Items, and Blueprints evaluation priority

When the engine evaluates a blueprint against the blacklist, the three restriction mechanisms are evaluated independently and the result is combined with a logical OR: any single restriction blocks the blueprint. The evaluation priority is:

1. Input_Items check - fastest lookup. The engine checks each of the blueprint's input items against the flat set of blacklisted input GUIDs. If any input item matches a blacklisted GUID, the blueprint is blocked immediately without checking the remaining two mechanisms.
2. Output_Items check - the engine checks the blueprint's output items against the flat set of blacklisted output GUIDs. If any output item matches, the blueprint is blocked.
3. Blueprints array check - the most expensive check. The engine iterates the Blueprints array and compares each entry's item GUID and blueprint name or index against the blueprint being executed. If a match is found, the blueprint is blocked.

The Input_Items check is the fastest because it is a simple GUID set lookup. The Blueprints array check is the most expensive because it requires iterating the array and performing a two-field comparison for each entry. For mods with many blacklisted blueprints, the cohort recommendation is to use Input_Items or Output_Items where possible and to reserve the Blueprints array for cases that require the precision of targeting a specific named blueprint on a specific item.

Deploying crafting blacklists in production server environments

The deployment context of a crafting blacklist asset affects how players experience the restrictions and how server administrators manage the configuration. Three deployment patterns are documented in the cohort's operational experience: single-file blacklist, multi-file categorized blacklist, and event-timed blacklist.

Single-file blacklist deployment

A single-file blacklist contains all restrictions in one .asset file. This is the simplest deployment pattern and is appropriate for small to medium restriction sets (fewer than twenty entries across all arrays). The single file is easy to audit, easy to version-track in source control, and easy to deploy or remove. The disadvantage is that the file becomes difficult to maintain as restrictions grow: finding a specific entry requires scanning the entire file, and removing one category of restrictions requires editing the file rather than removing the file.

Multi-file categorized blacklist deployment

A multi-file categorized blacklist splits restrictions across multiple .asset files, each named for the category it represents. Example categorization:

File name	Content	Purpose
DisallowSalvage.asset	Blueprints array targeting Salvage blueprints	Prevents salvage operations
DisallowEventItemCrafting.asset	Input_Items targeting event item GUIDs	Restricts event items from crafting during off-season
DisallowExplosiveOutput.asset	Output_Items targeting explosive item GUIDs	Prevents crafting of explosive items
DisallowCoreModFood.asset	Input_Items targeting core mod food items	Restricts food crafting to curated recipes

The multi-file pattern makes individual restriction categories independently deployable and removable. The server administrator can remove DisallowEventItemCrafting.asset when the event window opens without affecting the persistent salvage restrictions. The disadvantage is that each file adds a small load-time parsing cost, though this cost is negligible for any realistic number of files.

Event-timed blacklist deployment

Event-timed blacklists are deployed for a specific duration and then removed. This pattern uses a separate blacklist asset file for each event, named with the event name and date. The file is added to the server's mod directory before the event and removed after the event ends. The event-timed pattern avoids permanent changes to the server's restriction configuration and allows the event blacklist to be tested independently of the server's persistent blacklist set.

Testing a blacklist in single-player versus multiplayer

The testing methodology for a crafting blacklist differs between single-player and multiplayer environments due to the way the engine processes blacklist files in each context.

In single-player mode, the blacklist file must be placed in the local Unturned™ installation's Bundles/ directory or in the local Workshop content directory if the mod is subscribed. The blacklist is loaded at startup, and the crafting menu reflects the restrictions immediately. The testing workflow is to add the blacklist file, launch the game, open the crafting menu, and visually confirm that the targeted blueprints are absent.

In multiplayer mode, the blacklist is loaded by the server, not by the clients. The client's crafting menu displays only the blueprints that the server allows, so a client-side blacklist modification has no effect on the server-enforced restrictions. The testing workflow for a server environment is to add the blacklist file to the server's content directory, trigger a content reload (or restart the server), and verify the restrictions from a client connected to the server.

The most important testing distinction is that single-player testing verifies the blacklist file syntax and the GUID resolution, while multiplayer testing verifies the server-side enforcement. A blacklist that passes single-player testing may still fail in multiplayer if the file is not deployed to the correct server directory or if the server's content reload does not pick up the new file.

Blacklist deployment verification checklist

Before deploying a blacklist to a production server, verify each of the following items:

• [ ] Each GUID in the blacklist resolves to an item that exists in the current mod loadout
• [ ] The blacklist file is in the correct Bundles/ directory for the mod or server
• [ ] The Type field value matches exactly what the engine expects for a crafting blacklist asset
• [ ] The blacklist has been tested in single-player with the exact mod loadout that the server uses
• [ ] Each Blueprints array entry has been confirmed to block the correct blueprint on the correct item
• [ ] Allow_Core_Blueprints is set to the intended value (true or false) and is not accidentally omitted
• [ ] The server administrator has been notified of the blacklist changes and the expected player impact
• [ ] A rollback plan exists: the original blacklist file (or the absence of the file) can be restored within one content reload

Worked example: tracing a blacklisted craft through the system

Consider a mod server that has deployed a crafting blacklist with the following configuration:

GUID 1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d
Type SDG.Unturned.CraftingBlacklistAsset

Input_Items
[
    {
        GUID 67c76cdf16024bf68b6e5d14d4c617ab
    }
]

The item with GUID 67c76cdf16024bf68b6e5d14d4c617ab is the Orange Hoodie (a vanilla clothing item). A player on the server opens the crafting menu and selects a blueprint that consumes the Orange Hoodie as an input ingredient - for example, a mod-defined salvage blueprint that converts the Orange Hoodie into cloth scraps.

The engine evaluation proceeds as follows:

1. The player selects the salvage blueprint and triggers the craft action.
2. The engine enters the crafting execution path and consults the loaded blacklist assets.
3. The engine reads the Input_Items array from the blacklist and builds a set of blacklisted input GUIDs.
4. The engine examines the blueprint's input items. One input is the Orange Hoodie with GUID 67c76cdf16024bf68b6e5d14d4c617ab.
5. The engine checks whether that GUID is in the blacklisted input set. It is.
6. The engine blocks the blueprint. The salvage operation does not execute.
7. The player sees no error message. The blueprint is simply removed from the available options in the crafting menu. The Orange Hoodie no longer appears in the quick-actions radial menu when right-clicked.

The same evaluation applies if the blacklist had used Output_Items instead, with the player attempting to craft the Orange Hoodie as an output. The engine would check the blueprint's output items against the blacklisted output set and block the craft.

Diagnostic table

Symptom	Most likely cause	Resolution
Blueprint still executable despite being in Input_Items	GUID in blacklist does not match item GUID exactly	Confirm the GUID in the blacklist matches the item's GUID character for character
Blueprint hidden from menu unintentionally	GUID collision between mod and vanilla item	Assign a custom GUID to the mod item and verify no other blacklist targets the same GUID
Blacklist has no effect on vanilla blueprints	Allow_Core_Blueprints defaults to true	Add Allow_Core_Blueprints false to extend the blacklist to core items
Blacklist applies to too many blueprints	Input_Items or Output_Items broad by design	Narrow the restriction by using Blueprints array targeting specific blueprint names
Blueprint name blacklist does not work	BlueprintName in blacklist does not match Name in item's blueprint config	Open the item's blueprint configuration and confirm the exact BlueprintName string
Blueprint index blacklist broken after mod update	Blueprint indices shifted due to blueprint list reorganization	Switch from numeric index to BlueprintName

Best practices

• Use the bracketed block format for all array entries. It is more readable than bare GUID strings and more forward-compatible with potential parser enhancements. The shipped G-008 evidence set uses all three formats interchangeably, but the cohort recommendation is block format for new blacklist assets.
• Prefer BlueprintName over Blueprint index. The index is fragile and changes when the item's blueprint list is reorganized. The name is stable as long as the blueprint's Name field is not changed, and the official documentation explicitly recommends this approach.
• Set Allow_Core_Blueprints false only when you need to restrict vanilla crafting. Leaving it at the default (true) means the blacklist affects only mod-defined blueprints, which is the least surprising behavior for players.
• Document every blacklist entry in the mod's Workshop description. Players who encounter an invisible blueprint with no error message will search the Workshop description for information about what was removed and why.
• Test each blacklist entry individually in single-player before deploying to a multiplayer server. A blacklist that accidentally blocks the wrong blueprint is silent - there is no error message, no console log entry, and no visual indicator. The blueprint simply does not appear, and the modder must recognize its absence through testing.
• Use separate blacklist asset files for logically distinct restriction categories. A file named DisallowSalvageChefHat.asset is self-documenting; a single file named AllRestrictions.asset that mixes input, output, and blueprint restrictions across unrelated items is harder to maintain.
• Never assume that a blacklist applies to all servers that load the mod. The blacklist is a per-asset configuration; if the blacklist asset file is not present in the mod's Bundles/ folder, the restrictions do not apply. Verify file deployment as part of the mod's publishing checklist.

Frequently asked questions

Can a mod have multiple crafting blacklist assets?

Yes. Multiple blacklist assets can coexist in the same mod's Bundles/ folder. The engine evaluates all loaded blacklist assets against every blueprint. A blueprint is blocked if any single blacklist asset in any loaded mod blocks it. This means a server with multiple mods that each contribute blacklist restrictions must ensure the blacklists do not conflict unintentionally - one mod blacklisting an item that another mod expects to be craftable produces a silent restriction that the second mod's author may not have anticipated.

What happens if I blacklist an item that does not exist in any blueprint?

The blacklist entry is accepted silently by the engine. The item GUID is added to the blacklist registry but has no effect because no blueprint references it. This is a harmless configuration: the engine pays the memory cost of storing the GUID in the blacklist set, but no runtime evaluation cost beyond a single failed set lookup per crafting operation. The cohort recommendation is to avoid orphaned blacklist entries for clarity, though they do not produce errors.

Does the blacklist affect the crafting output spawn?

No. The blacklist prevents the blueprint from executing at all. It does not modify the blueprint's output. If a blueprint would normally produce three planks and the player has all the required ingredients, a non-blacklisted blueprint executes normally and produces all three planks. A blacklisted blueprint does not execute and produces nothing. The output item count, type, and quality are entirely unaffected by the blacklist mechanism.

Can I blacklist a blueprint that has no Name field?

Yes, using the numeric Blueprint index. However, the official documentation strongly recommends adding a Name field to every blueprint and using BlueprintName for blacklist targeting. A blueprint without a Name field can still be blacklisted by index, but the index may change when the item's blueprint list is reorganized. If you must blacklist a blueprint that lacks a name, the cohort recommendation is to add the name to the blueprint's configuration as a preventative measure.

How do I verify that a blacklist is working in single-player?

Spawn the blacklisted item with @give <itemID> and right-click it in the inventory. The quick-actions menu should not show any crafting or salvage option if the item is blacklisted as an input. Open the full crafting menu and search for the recipe that consumes or produces the blacklisted item. The recipe should not appear. If both checks pass - the quick-actions menu shows crafting options and the recipe appears in the full menu - the blacklist is not being loaded or the GUID in the blacklist does not match the item's GUID.

Does the blacklist affect all players or can I target specific players?

The blacklist is a global asset. It applies to every player on the server. There is no per-player or per-permission-group blacklist mechanism in the base Unturned™ crafting system. If your mod scenario requires per-player blacklist restrictions, the enforcement must be implemented server-side through the Unturned Dedicated Server API, not through the crafting blacklist asset.

Can I blacklist a blueprint that belongs to another mod's item?

Yes, if the other mod's item is loaded on the same server and its GUID is known. The blacklist references items by GUID, and the engine resolves GUIDs across all loaded mods. If Mod A's blacklist references a GUID from Mod B's item, and both mods are loaded on the same server, the blacklist entry is resolved correctly. However, if Mod B is removed from the server, the blacklist reference becomes a dead entry that the engine silently skips. This cross-mod blacklisting capability is useful for curated server configurations where the server administrator maintains a separate blacklist mod that references items from multiple content mods.

How does the blacklist interact with the // comment convention?

The // convention used by modders to add comments to .dat files is accepted by the parser for crafting blacklist assets as well. Lines starting with // are parsed as field names (specifically, as a field named //) whose value is silently ignored because the parser does not recognize // as a valid field name. This means comments do not cause parse errors, but they also do not carry any semantic meaning. The convention is purely for human readability. The G-008 evidence set uses // comments within array entries to label GUID entries, as shown in the Input_Items example earlier in this article.

What is the format difference between the .asset and .dat file extension?

The crafting blacklist asset uses the .asset extension in the shipped G-008 evidence set, while most item assets use .dat. The extension does not affect the parser - the engine reads the file content and checks the Type field, ignoring the extension. The .asset convention distinguishes blacklist files from item configuration files at a glance. The cohort recommendation is to follow the shipped convention and use the .asset extension for crafting blacklist files.

Can a blacklist target a blueprint that exists on a mod item but not on the current server?

Yes, but the blacklist entry is silently ignored for that blueprint because the blueprint's item does not exist in the current asset registry. The engine attempts to resolve the item GUID at load time; if the GUID does not match any loaded item, the blacklist entry for that item's blueprints is skipped without error. This means a blacklist intended for a mod that is not installed on the server has no effect - it neither blocks nor errors, which can be confusing for server administrators who expect the blacklist to produce some visible indication.

Is there a performance cost to having many blacklist entries?

The performance cost is negligible for any realistic number of blacklist entries. The Input_Items and Output_Items checks use a hash-set lookup, which is O(1) per check. The Blueprints array check is O(n) in the number of array entries, but a single crafting operation involves at most a few dozen array entry comparisons even for a comprehensive blacklist. The cohort recommendation is not to optimize for blacklist size; prioritize clarity and maintainability over theoretical performance concerns.

Can a blacklist target items by category rather than by individual GUID?

No. The crafting blacklist's restriction mechanism is based exclusively on GUID-based item pointers. There is no category, tag, or type-based filtering mechanism in the crafting blacklist asset. Each item that should be restricted must be listed individually by its GUID. This design ensures that restrictions are explicit and auditable: a server administrator can see exactly which items are blacklisted by scanning the GUIDs in the blacklist file. Category-based restrictions would introduce ambiguity about which items fall into which category and would make the blacklist behavior dependent on the categorization scheme that the mod author chose.

Can a blacklist be applied to specific maps or only globally?

The crafting blacklist is evaluated globally across all maps. There is no map-specific blacklist mechanism in the base Unturned™ asset system. If a mod scenario requires different blacklist rules on different maps, the enforcement must be implemented server-side through the Unturned Dedicated Server API, which can check the current map name before allowing or blocking a craft operation. The asset-level blacklist applies uniformly regardless of which map the server is running.

How do I test a blacklist without affecting other players on a server?

A blacklist can be tested in single-player mode before deployment to a multiplayer server. The single-player environment loads all mod assets that are present in the local Workshop content directory, including any crafting blacklist files. The authoring workflow is to add the blacklist file to the local mod directory, launch Unturned™ in single-player, spawn the relevant items, and verify that the blacklisted blueprints are hidden from the crafting menu. Once the single-player test passes, the blacklist file can be added to the server's mod directory for production deployment.

What is the difference between blacklisting an item from crafting input and removing the blueprint entirely?

Blacklisting an item from crafting input is a non-destructive operation: the blueprint definition remains in the game's data, and removing the blacklist file restores the blueprint to full functionality. Removing the blueprint entirely from the item's configuration is a destructive operation that requires re-authoring the blueprint to restore it. The blacklist approach is preferred for temporary restrictions, curated server configurations, and event-timed restrictions. The blueprint-removal approach is appropriate only when the blueprint should never be available under any configuration.

Is there a log entry when a blacklist blocks a craft operation?

The engine does not log a specific entry when a blacklist blocks a craft operation. The blueprint is silently hidden from the crafting menu and the quick-actions radial menu, and no console output or log file entry records the block event. This silent behavior is intentional from a design perspective: the blacklist is meant to prevent crafting, not to inform players that crafting was prevented. However, the lack of logging makes debugging blacklist misconfigurations more difficult, and the cohort recommendation is to rely on single-player visual verification rather than log analysis for blacklist testing.

What happens if two blacklists define conflicting restrictions for the same blueprint?

If one blacklist blocks a blueprint and another does not, the blueprint is blocked. The blacklist system uses a veto model: a single blocking entry across any loaded blacklist asset is sufficient to block the blueprint. There is no conflict resolution because the system does not support a "this blacklist overrides that blacklist" priority mechanism. All loaded blacklists have equal authority, and the most restrictive combination of their entries is the effective policy.

Blacklist versioning and backward compatibility

When a crafting blacklist is published as part of a Workshop mod and subsequently updated, the backward compatibility considerations are different from item asset compatibility because the blacklist does not have a GUID or a stable identifier that persists across versions. The engine reloads the blacklist from the file on each content reload, so an updated blacklist file replaces the previous version entirely. The key compatibility concern is that a blacklist update that removes entries may inadvertently restore blueprints that players had learned to expect were unavailable.

The cohort recommendation for blacklist versioning is to maintain a changelog within the blacklist file using // comment lines (which the parser silently skips) and to communicate blacklist changes in the Workshop item's changelog. A blacklist that is versioned alongside the mod can be tracked through source control, and the // comment convention provides an in-file audit trail that survives file-level deployments.

Blacklist distribution across mod update boundaries

When a mod is updated on the Steam Workshop, the blacklist file is distributed as part of the mod's content bundle. Players who subscribe to the mod receive the updated blacklist automatically when they launch Unturned™ and the content synchronization completes. The blacklist update is applied on the next content reload, which may occur immediately (if the game is launched after the update) or on the next server content reload (if the mod is deployed on a dedicated server). There is no mechanism to notify players that the blacklist has changed, which is consistent with the blacklist's design philosophy of operating silently in the background.

Appendix A: Crafting blacklist .asset field quick reference

Field	Type	Required	Default
GUID	uint128 hex	Yes	,
Type	string	Yes	Must be CraftingBlacklist or SDG.Unturned.CraftingBlacklistAsset
Input_Items	array of GUID pointers	No	Empty
Output_Items	array of GUID pointers	No	Empty
Blueprints	array of	No	Empty
Allow_Core_Blueprints	bool	No	true

Appendix B: crafting blacklist item pointer format comparison

Format	Example	Readability	Forward compatibility
Bare GUID string	dab78cc4d66645bfb8169be7c15cf876	Low - no key identifies the value	Low - parser may not distinguish GUID from other uint128 values
Quoted GUID with key	"GUID" "67c76cdf16024bf68b6e5d14d4c617ab"	Medium - key identifies the value	Medium - keys improve parser robustness
Bracketed block	{ GUID b03d581a5c1a490f995f8deba57b0f17 }	High - explicit structure	High - parser can add fields without breaking existing entries

Appendix C: Crafting blacklist syntax validation reference

The table below documents the exact syntax the engine's parser expects for each crafting blacklist field. Use this reference as a syntax-validation checklist when authoring a new blacklist asset file.

Field	Syntax pattern	Common syntax error	Corrected form
GUID	GUID <32 hex chars>	Missing or extra characters	Confirm exactly 32 hexadecimal digits, no hyphens
Type	Type <type string>	Wrong case	Must match SDG.Unturned.CraftingBlacklistAsset exactly
Input_Items	Input_Items then newline then [ then entries then ]	Missing newline between field name and bracket	Ensure array opening bracket is on its own line
Output_Items	Output_Items then newline then [ then entries then ]	Same as Input_Items	Same as Input_Items
Blueprints	Blueprints then newline then [ then blocks then ]	Missing Item GUID inside block	Each block must have an Item field with a valid GUID
BlueprintName	BlueprintName <string>	BlueprintName misspells the actual blueprint name	Open the item's blueprint config and verify the exact Name string
Blueprint (index)	Blueprint <int>	Index out of range	Blueprint indices start at 0
Allow_Core_Blueprints	Allow_Core_Blueprints <true/false>	Value cased incorrectly	Use lowercase true or false as accepted by the parser

The quick reference table above consolidates the six fields that a crafting blacklist asset can contain. Mod authors should use this table as a field-completeness checklist when authoring a new blacklist asset file. Every required field must be present with a valid value, and every optional field must be explicitly set when the default value would produce unintended behavior.

Appendix D: external references

• Smartly Dressed Games modding documentation - Blueprint and crafting asset types - the official field reference for the crafting blacklist asset type.
• Unturned on Steam - the Unturned™ store page and community hub.
• Blueprint Asset Reference - the companion article defining blueprint structure; understanding blueprints is prerequisite to understanding blacklisting them.
• Crafting Asset Reference - the previous article in this section; covers the broader crafting system that the blacklist constrains.
• Effect Asset Reference - the next article in this section; covers visual and sound effect assets.
• Item Asset Anatomy - the shared field reference; documents GUID generation and the item identity block that blacklist entries reference.

Blacklist misconfiguration scenarios and recovery

The following scenarios describe common misconfiguration patterns that occur when deploying crafting blacklists in production environments. Each scenario includes the symptom, the root cause, and the recovery path.

Scenario 1: the accidental economy freeze

A server administrator deploys a comprehensive blacklist that targets Input_Items across a broad set of vanilla items with Allow_Core_Blueprints false. After the content reload, players report that they cannot craft any item that consumes vanilla materials, even though the server's crafting economy depends on converting raw materials into processed goods. The root cause is that the Input_Items array was populated with a general item category rather than specific items, and the broad restriction caught more blueprints than intended. Recovery: remove or narrow the Input_Items entries to target only the specific items that should be restricted, and reload the content. The blacklist is non-destructive, so the blueprints become available again immediately after the corrected blacklist is loaded.

Scenario 2: the invisible restriction

A mod author adds a blacklist to their Workshop mod and publishes an update. After the update, server administrators report that players cannot craft a specific item, but the mod's changelog does not mention any blacklist changes. The root cause is that the blacklist file was added to the mod without documentation in the Workshop description or the server administrator notification. Recovery: update the Workshop description to document the new blacklist entries, and consider splitting the blacklist into a separate optional file that server administrators can choose to deploy or omit.

Scenario 3: the stale blacklist entry

A mod author blacklists an item by GUID in an early version of the mod. In a later update, the item's GUID is changed (a practice that should be avoided but occasionally occurs during major refactoring). The blacklist entry becomes a stale reference that the engine silently skips. The root cause is that the blacklist was not updated when the item GUID changed. Recovery: audit the blacklist GUIDs after each mod update that touches item identity fields, and update any blacklist entries whose target GUIDs have changed.

Scenario 4: the cross-mod blacklist conflict

Two mods deployed on the same server each contain a crafting blacklist. Mod A blacklists an item as an input to prevent its use in a specific recipe. Mod B adds a new blueprint that consumes the same item as an ingredient. The Mod B blueprint is silently blocked by Mod A's blacklist, and neither mod's documentation accounts for the interaction. The root cause is that the server administrator did not audit the combined blacklist set across all installed mods. Recovery: identify the conflicting blacklist entry, document the cross-mod restriction in the server rules, and either remove the conflicting entry from Mod A's blacklist or accept the interaction as a curated restriction.

Advanced considerations

Large-scale blacklist management with many entries

Servers that curate a large item set may accumulate hundreds of blacklist entries across multiple blacklist asset files. Managing this scale requires organizational discipline beyond what the per-file conventions provide. The cohort recommendation for large-scale blacklist management is to maintain a single source-of-truth spreadsheet or document that maps each restricted item GUID to its restriction type (input, output, or blueprint), the reason for the restriction, and the date the restriction was added or removed. This source-of-truth document is the reference for auditing the blacklist files and for planning restriction changes. The blacklist files themselves are generated from the source-of-truth document rather than authored directly, which prevents the files from diverging from the documented restriction set.

The generated blacklist files should each be named with a category prefix that matches the source-of-truth categorization, such as Economy_Restrictions.asset, Event_Restrictions.asset, and Temporary_Restrictions.asset. The category prefix ensures that files are sorted logically in directory listings and that the purpose of each file is immediately clear to anyone auditing the mod's Bundles directory.

Crafting blacklist and economy balance

On servers with a player-driven economy (such as the 57 Studios™ roleplay servers), the crafting blacklist is a balance tool that prevents players from converting high-value items into base materials through salvage operations. A salvaged item that returns more resources than its components cost disrupts the economy by introducing a resource-positive loop. The blacklist breaks this loop by removing the salvage blueprint from the crafting menu. Economy balance blacklists should target specific BlueprintName Salvage entries across multiple items rather than using Input_Items broadly, because the precision prevents accidentally blocking legitimate salvage operations on unrelated items.

Server-wide blacklist deployment via mod configuration

When deploying a crafting blacklist to a server network, the blacklist asset file must be present in every server's mod directory. A blacklist deployed as part of a Workshop mod is automatically distributed to clients when they subscribe to the mod, but the blacklist is evaluated server-side, not client-side. The client does not enforce the blacklist; the server does. This means a client with a modified or removed blacklist file cannot bypass the restriction because the server performs the blacklist check before allowing the craft operation to proceed.

Multiple mods with overlapping blacklists

In a server environment with multiple Workshop mods installed, each mod may contribute its own blacklist assets. The combined effect is the union of all restrictions. A common oversight is that Mod A blacklists an item from being used as input to a salvage blueprint, while Mod B adds a new blueprint that consumes the same item. The blacklist from Mod A blocks Mod B's blueprint, and neither mod's documentation accounts for the interaction. The cohort recommendation for server administrators is to audit the combined blacklist set across all installed mods and to document any cross-mod restrictions in the server's rules documentation.

Relationship between blacklist and item rarity in crafting economy

The crafting blacklist and the item rarity system serve complementary but distinct roles in the mod economy. Rarity controls the visual tier of an item and influences spawn table weights. The crafting blacklist controls whether a blueprint that consumes or produces an item is executable. A rare or legendary item can be blacklisted from crafting input to prevent players from using high-tier items as generic material sources, regardless of the item's rarity tier. Conversely, a common item can be blacklisted from crafting output to prevent mass-production of an item that the mod author wants to remain scarce.

The practical interaction between rarity and blacklisting is most acute in curated survival servers where the server administrator wants certain items to be non-craftable but still discoverable through exploration. The item is set to an appropriate rarity tier for its value in the loot economy, and the crafting blacklist prevents its production through the crafting menu. Players must find the item in the world rather than craft it, which extends the item's gameplay lifetime and gives exploration-oriented players a reason to search.

Blacklist for temporary event items

Event items that should not be craftable or salvageable after the event ends can be managed through a crafting blacklist. The event item's GUID is added to an Input_Items array in a blacklist asset that is deployed only during the event period. After the event, removing the blacklist asset from the mod's Bundles/ folder restores the item's craftability without requiring a change to the item itself. This approach avoids editing the item's blueprint configuration for temporary restrictions.

Appendix E: Glossary of crafting blacklist terminology

Term	Definition
Blacklist asset	A data file that instructs the crafting parser to exclude designated items or blueprints from the crafting menu
Blueprint	A recipe definition attached to an item that specifies inputs and outputs for a crafting operation
Blueprint index	The zero-based position of a blueprint within an item's blueprints list
Blueprint name	A human-readable string assigned to a blueprint for stable cross-referencing
Core blueprint	A blueprint defined by a vanilla Unturned™ item rather than a mod item
Content reload	The engine process of re-scanning all mod directories and reloading assets, triggered at startup or by Workshop content synchronization
Crafting blacklist	The asset type SDG.Unturned.CraftingBlacklistAsset that implements the blacklist mechanism
Crafting menu	The in-game UI that displays available blueprints to the player
GUID	A 128-bit globally unique identifier used to reference items and assets across the Unturned™ asset system
Input blacklist	Restriction that prevents an item from being used as a blueprint ingredient
Item pointer	A reference to an item asset by its GUID, used within blacklist arrays
Non-destructive restriction	A blacklist entry that suppresses a blueprint without modifying the underlying blueprint data
Output blacklist	Restriction that prevents an item from being produced as a blueprint result
Quick-actions menu	The radial menu that appears when a player right-clicks an item in inventory, showing available actions including crafting
Silent restriction	A blacklist entry that prevents crafting without any error message, log entry, or visual indicator
Veto model	The evaluation model where a single blocking entry across any loaded blacklist asset is sufficient to block a blueprint
Zero-based indexing	The convention of numbering blueprint positions starting from 0 rather than 1

Authoring checklist

Before deploying a crafting blacklist asset to a mod or server, confirm the following:

• [ ] Each GUID in the blacklist matches the exact GUID of the target item - verify by opening the item's .dat and confirming character-for-character match
• [ ] Input_Items entries use the correct item GUID direction - the GUID of the item to block as input, not the blueprint's output GUID
• [ ] Output_Items entries use the correct item GUID direction - the GUID of the item to block as output, not the blueprint's input GUID
• [ ] Blueprints array entries include both the Item GUID and the BlueprintName (preferred) or Blueprint index
• [ ] Allow_Core_Blueprints is explicitly set to true or false - never omitted when the default would produce unintended behavior
• [ ] The blacklist asset file is placed in the correct Bundles/ folder and is packaged in the Workshop build
• [ ] Each blacklisted blueprint name is confirmed to exist on the target item with an exact string match
• [ ] Tested in single-player: the blacklisted blueprint does not appear in the crafting menu and does not execute if triggered by console command
• [ ] Workshop description documents which blueprints are restricted and why
• [ ] Server administrators have been notified of the blacklist deployment if the mod is already in active use

The glossary above covers the sixteen most important terms that recur across crafting blacklist documentation. Mod authors who encounter an unfamiliar term in any section of this article should search the glossary for a concise definition before proceeding to the advanced content.

The definitions in the glossary are specific to the Unturned™ asset system and may not generalize to other game modding contexts. For example, the term "blueprint" in Unturned™ refers to a recipe definition attached to an item asset, while in other games a blueprint may refer to a schematic that the player learns permanently. The glossary definitions are scoped to the Unturned™ modding domain and reflect the terminology used in the shipped G-008 evidence set. Mod authors who are new to the crafting blacklist system should refer back to the glossary when encountering unfamiliar terminology in the field reference sections.

The crafting blacklist asset is a specialized tool that should be used with precision. A well-configured blacklist achieves its restriction goal silently and durably, while a poorly-configured blacklist can produce invisible restrictions that are difficult to diagnose and frustrating for players. The field reference, worked examples, diagnostic table, and deployment patterns in this article provide the cohort-validated foundation for authoring blacklist assets that behave predictably across single-player and multiplayer environments.

The pattern that distinguishes well-configured blacklists from poorly-configured ones is the specificity of the restriction. A narrowly-scoped blacklist that blocks one specific blueprint on one specific item produces a predictable outcome that can be verified in minutes. A broadly-scoped blacklist that blocks an entire item category through Input_Items produces a complex web of restrictions that may take hours to audit and correct. The time invested in specificity during authoring is returned many times over during maintenance and debugging. A blacklist that targets a specific BlueprintName on a specific item GUID produces a predictable, auditable restriction that can be verified in a single-player test. A blacklist that uses broad Input_Items entries with Allow_Core_Blueprints false can produce cascading restrictions that affect blueprints the mod author did not intend to block. The cohort recommendation is to start with the most specific restriction possible and to broaden only when the specific restriction is confirmed to produce the correct behavior.

Document history

Version	Date	Author	Notes
1.0	2026-07-26	57 Studios	Initial publication. Full crafting blacklist .asset field reference, Input_Items, Output_Items, Blueprints array, Allow_Core_Blueprints, shipped G-008 examples, diagnostic table, FAQ, appendices.
1.1	2026-07-26	57 Studios	Expanded deployment patterns section, added multi-file categorized blacklist guidance, added misconfiguration scenarios, added glossary appendix, added testing methodology section.

Cross-references

• Crafting Asset Reference - the previous article; covers the broader crafting system that the blacklist constrains.
• Effect Asset Reference - the next article in this section; covers visual and sound effect assets.
• Blueprint Asset Reference - the blueprint system that the blacklist restricts; prerequisite reading for understanding the Blueprints array field.
• Item Asset Anatomy - shared item field reference; GUID generation and the identity block used in blacklist entries.
• Project Folder Structure and GUIDs - folder layout and GUID workflow; the prerequisite for any mod authoring task.
• Asset Validation Rules - the validation rules that apply to all asset types, including blacklist assets.
• Smartly Dressed Games modding documentation - official field reference for the crafting blacklist asset type.
• Unturned on Steam - game page and community.