Redirector Asset Reference

Intermediate40-60 minutesWindowsNotepad++Unity Editor

A redirector asset is a special asset type that the Unturned™ engine uses when resolving asset references. When an asset reference (a GUID or a legacy ID) points to a redirector, the asset system does not return the redirector itself. Instead, the asset system follows the redirector to its target and returns the target asset, transparently and with no indication to the caller that a redirect occurred. The redirector is an invisible shim-an identity layer that sits between a reference and its resolved asset, allowing mod developers to change what asset a given GUID or legacy ID resolves to without modifying every file that references that GUID or legacy ID.

This article is the 57 Studios™ canonical reference for the redirector asset type. It covers the .asset file format that redirector assets use, the AssetCategory and TargetAsset fields, the resolution chain that the engine follows when it encounters a redirector, the specific use case of vehicle color variant redirectors (which make up the bulk of the shipped vanilla redirector set), the interaction between redirectors and the legacy ID system, and the documented limitation that most features save the original asset reference rather than the resolved asset. The article assumes familiarity with GUIDs, legacy IDs, and the .asset file format. Readers new to the asset system should read GUID Type Reference and Legacy ID Availability before this article.

Documentation source: This article references Chapter 102 ("Redirector Assets") of the official Smartly Dressed Games modding documentation for field definitions and behaviour. Redirector usage patterns are validated against the shipped vanilla redirector set in the Unturned™ game files and the cohort's documented use of redirectors for collision resolution.

Who this article is for

This article is written for Unturned™ mod authors who need to resolve legacy ID collisions without changing published IDs, who are building mods that interact with the vanilla redirector system, or who are designing GUID-based asset referencing schemes that require identity indirection. Readers should already understand .dat and .asset file authoring, the GUID system, and the legacy ID system. If you are troubleshooting an ID collision, read Legacy ID Availability first, then return here for the redirector-based resolution path.

What you'll learn

• The technical definition of a redirector asset: an identity shim that redirects asset references to a target asset
• The two fields that define a redirector: AssetCategory and TargetAsset
• How the engine resolves asset references through redirectors at runtime
• The difference between a redirector asset and other asset types
• How redirectors enable legacy ID indirection through the AssetCategory field
• The specific use case of vehicle color variant redirectors
• The documented limitation: most features save the original reference, not the resolved asset
• How to author a redirector asset from scratch
• How to use redirectors to resolve ID collisions between mods
• Worked examples for item redirectors, vehicle redirectors, and collision-resolution redirectors

Background: why redirectors exist

The Unturned™ asset system underwent a fundamental migration from legacy IDs to GUIDs. Objects, vehicles, resources, and effects migrated first; items remain in a dual-identity state. During this migration, references to assets that moved from one identity system to another needed a bridging mechanism. A map that referenced a tree object by its legacy ID needed to continue working after the tree asset was migrated to a GUID-only identity model. A mod that referenced a vehicle by its old GUID needed to continue working after the vehicle's GUID was changed in a mod update. Redirector assets provide this bridging mechanism.

The SDG documentation describes redirectors as being used "when resolving asset references (GUIDs and legacy IDs)." The key phrase is "resolving asset references": the redirector operates at the reference-resolution layer of the asset system, not at the asset-loading layer. A redirector is never spawned as an in-game entity; it is never held by a player or placed in the world. It exists solely to redirect the resolution of a reference from one identity to another.

As shown in the flowchart above, the redirector intercepts the reference resolution and returns the target asset. The caller (the system that made the asset reference) receives the target asset and has no indication that a redirect occurred. The redirector itself is never visible to the caller.

How the engine resolves asset references through redirectors

The asset reference resolution chain operates as follows:

1. A system (blueprint recipe, spawn table, map file, NPC configuration, or any other asset-reference consumer) looks up an asset by GUID or legacy ID.
2. The engine queries the global asset registry for the referenced GUID or ID.
3. If the registry entry at that GUID or ID is a redirector asset, the engine does not return the redirector. Instead, it reads the redirector's TargetAsset field, which contains a GUID.
4. The engine queries the asset registry a second time, using the TargetAsset GUID.
5. If the second query finds a regular (non-redirector) asset, the engine returns that asset to the caller.
6. If the second query finds another redirector, the engine follows the chain (step 3-4) until it reaches a non-redirector asset or exhausts the chain.

The redirector chain can theoretically be any length, though in practice chains longer than one hop are unusual. Each hop adds a registry lookup; long chains would incur a small performance cost at load time but are functionally identical to a single-hop redirector.

The sequence above models the two-step lookup that occurs when a reference points to a redirector. The caller never sees the redirector; the redirector is consumed by the resolution process.

Redirector asset file format

Redirector assets use the .asset file format, not the legacy .dat format. The file is a plain-text key-value file with the same syntax as other .asset files. The redirector asset type is identified by the Type field and the presence of the TargetAsset field.

Complete field reference

Field	Type	Required	Default	Example	Purpose
Type	enum	Yes	None	RedirectorAsset	Must be RedirectorAsset for this asset type.
GUID	uint128 hex	Yes	,	a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d	The GUID that references will point to. This is the redirector's own GUID-the GUID that other assets reference and that the engine resolves through to the target.
ID	uint16	No	,	50001	Legacy ID for this redirector. If AssetCategory is set, asset references by legacy ID that match this ID will be redirected to TargetAsset.
AssetCategory	enum	No	None	Item	The asset category whose legacy IDs this redirector intercepts. If set, a legacy ID reference to this redirector's ID within the specified category is redirected to TargetAsset.
TargetAsset	GUID	Yes	,	def4567890abcdef1234567890abcdef	The GUID of the actual asset to return when an asset reference points to this redirector. This is the only field that is required for the redirector to function.

Field descriptions in detail

Type

The Type field identifies the asset as a redirector. The value must be RedirectorAsset. The engine uses this field to distinguish redirectors from regular assets during registry lookups. If the Type field is missing or set to any value other than RedirectorAsset, the engine treats the asset as a regular asset and does not perform the redirector resolution logic.

GUID

The GUID field is the redirector's own identity in the asset registry. Asset references that specify this GUID will be redirected to the TargetAsset GUID. The redirector's GUID is the "old" identity-the identity that existing references already point to. The TargetAsset GUID is the "new" identity-the asset that should actually be loaded when the old identity is referenced.

ID

The ID field is the redirector's legacy ID. It is optional and is only meaningful when AssetCategory is also set. When AssetCategory is set and a legacy ID reference matches this redirector's ID within the specified category, the legacy ID reference is redirected to the TargetAsset GUID.

AssetCategory

The AssetCategory field is an enum that specifies which asset category's legacy IDs this redirector intercepts. The possible values correspond to the Unturned™ asset type enum (EAssetType). The field's primary use case is redirecting legacy ID references:

If a redirector with AssetCategory Item is pointing to an asset with the legacy ID of 4, a /give 4 command would find the redirector and resolve it to the target asset, effectively spawning the target asset instead of the original asset at ID 4.

The AssetCategory field bridges the legacy ID system and the GUID system. A legacy ID reference (from a /give command, a legacy spawn table, or a legacy save file) resolves to the redirector's ID first, then the engine follows the redirector to the TargetAsset GUID. The AssetCategory field scopes the redirector to a specific asset category so that a redirector with ID 4 for Items does not accidentally redirect ID 4 for Vehicles.

TargetAsset

The TargetAsset field is the only field that is required for the redirector to function, per the SDG documentation. It contains the GUID of the asset that should be returned when a reference points to this redirector. The GUID must be the full 32-character hexadecimal string with no hyphens and must match the GUID field of an existing asset that is loaded by the game.

If TargetAsset points to a GUID that is not registered (no loaded asset has that GUID), the redirector resolves to nothing. The reference that pointed to the redirector produces a broken link at runtime. The SDG documentation does not specify the exact behaviour of a broken redirector chain (whether the engine returns a null reference, a default asset, or produces an error), but the practical outcome is always the same: the reference fails to resolve.

Critical warning

A redirector with a missing or invalid TargetAsset GUID produces a reference that resolves to nothing. The redirector consumes the reference (the engine does not fall through to another resolution mechanism) and returns a null or default asset. A redirector that points to a GUID that has been removed from the loaded mod set is a broken redirector, and every reference that passes through it will fail silently.

Example redirector asset files

Example 1: GUID-to-GUID redirector

The simplest redirector maps one GUID to another GUID. This is the pattern used when a mod update changes an asset's GUID and existing references (in other mods, in map files, in blueprint recipes) must continue to work with the new GUID.

Type RedirectorAsset
GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d
TargetAsset f6e5d4c3b2a10987fedcba9876543210

In this example, any asset reference that points to GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d will be transparently redirected to the asset with GUID f6e5d4c3b2a10987fedcba9876543210. The old GUID (the redirector's GUID) does not need to correspond to any actual asset; it exists purely as a redirect target.

Example 2: Legacy ID redirector with AssetCategory

A redirector with AssetCategory enabled intercepts legacy ID references in addition to GUID references:

Type RedirectorAsset
GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d
ID 4
AssetCategory Item
TargetAsset f6e5d4c3b2a10987fedcba9876543210

In this example:

• Any GUID reference to a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d resolves to the target asset.
• Any legacy ID reference to ID 4 within the Item category resolves to the target asset.
• A @give PlayerName 4 command spawns the target asset, not the original asset at ID 4.

This is the pattern used to resolve a legacy ID collision: the redirector's ID is set to the conflicting ID, AssetCategory is set to the appropriate category, and TargetAsset is set to the intended asset's GUID. The colliding mod item is not modified; the redirector intercepts references to the old ID and redirects them to the correct GUID.

Example 3: Vehicle color variant redirector

The shipped vanilla asset set includes 128 redirector assets for vehicle color variants. Each redirector maps a unique GUID to a specific color variant of a vehicle. The pattern is:

Type RedirectorAsset
GUID <variant-specific-guid>
AssetCategory Vehicle
TargetAsset <base-vehicle-guid>

Multiple redirectors point to the same base vehicle GUID, each with a different redirector GUID. A spawn table or map that references one of the variant GUIDs receives the base vehicle asset with the variant's color properties applied. The redirector GUID encodes the color variant identity; the TargetAsset GUID is the base vehicle.

This pattern allows color variants to exist as distinct identity points (for spawn tables, for map references, for /give commands that accept variant selectors) without requiring duplicate vehicle asset files. The base vehicle asset is authored once; the variants are authored as redirectors that point to the base asset and carry variant-specific metadata elsewhere in the asset system.

Vehicle redirector specifics

The 128 vehicle color variant redirectors in the shipped vanilla asset set are the most visible example of the redirector pattern in the vanilla game. They are located in the Bundles/Vehicles/Redirectors/ folder and follow a consistent naming convention: each redirector file name includes the base vehicle name and the color variant identifier.

The vehicle redirector pattern demonstrates several design principles that are useful for mod developers:

1. One base asset, many redirector identities. The base vehicle asset is authored once with all mechanical fields (speed, health, passenger count, fuel capacity). Each color variant is a redirector that points to the base asset. No mechanical fields are duplicated.

2. Redirectors carry no mechanical data. A vehicle redirector has only Type, GUID, AssetCategory, and TargetAsset. It does not carry speed, health, or any other vehicle property. The redirector's sole function is identity indirection; the mechanical data lives in the base asset.

3. Spawn tables reference redirector GUIDs. A spawn table that wants to spawn the blue variant of a police car references the blue-variant redirector's GUID, not the base police car GUID. The engine resolves the spawn table reference through the redirector and spawns the base police car with the blue variant's visual properties.

4. The /give command resolves through redirectors. A /give command that specifies the legacy ID or GUID of a vehicle redirector spawns the base vehicle with the variant's color properties. The player receives a vehicle that looks like the variant but is mechanically identical to the base vehicle.

The documented limitation: most features save the original reference

The SDG documentation includes an important limitation on redirector behaviour:

Most features do not save the resolved asset; instead they save the original asset reference. This means, for example, that redirecting some objects and re-saving a level will save the original object references, not the redirected objects.

This limitation has practical consequences for mod developers who use redirectors:

Operation	Behaviour with redirector	Consequence
Blueprint recipe	Resolves through redirector at craft time	Uses resolved asset during crafting; does not save the resolved identity
Spawn table roll	Resolves through redirector at spawn time	Spawns the resolved asset; the spawn table entry continues to reference the redirector GUID
Map save (level editor)	References the original redirector GUID, not the resolved asset GUID	If the redirector is later removed, the map reference breaks because it saved the redirector GUID, not the target GUID
Player inventory	Unknown	Cohort testing suggests the resolved asset is stored in some cases; behaviour may vary by asset category
NPC configuration	Resolves through redirector at reference time	The NPC references the original GUID; removing the redirector breaks the NPC reference
/give command	Resolves through redirector at command execution	The player receives the target asset; the redirector GUID is not visible to the player

The critical entry in the table is the map save behaviour. If a map references a redirector GUID for a placed object and the map is saved, the save file stores the redirector GUID, not the resolved object's GUID. If the redirector is later removed from the loaded mod set, the map reference breaks because the redirector GUID no longer resolves to anything. This is the most common redirector-related support issue: a map author uses a redirector to place objects, publishes the map, and players who do not have the redirector mod installed see broken or missing objects.

Common mistake

Using a redirector as a permanent identity proxy for assets that are placed in maps and saved. Because map saves store the redirector GUID rather than the resolved asset GUID, the redirector must remain available to every player who loads the map. If the redirector is part of a mod that is later unpublished or removed, every map that references the redirector breaks. Use redirectors for transitional identity changes (GUID migrations, collision resolution) rather than as permanent identity proxies.

Redirectors and the .asset file format

Redirector assets use the .asset file format, which is a plain-text key-value format with a syntax that differs from .dat files in several respects. The .asset file format is documented in full in Asset Definitions Reference; the redirector-specific notes are covered here.

A redirector .asset file has the following structure:

Type RedirectorAsset
GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d
ID 50001
AssetCategory Item
TargetAsset f6e5d4c3b2a10987fedcba9876543210

The field order is not enforced, but the convention (documented across the vanilla redirector set) is Type first, followed by GUID, then ID and AssetCategory if present, and TargetAsset last. The TargetAsset field must be the last meaningful field because it is the destination of the redirect chain.

File naming and folder location

Redirector .asset files follow the same folder-location conventions as other .asset files. The cohort convention is to place redirector files in a folder that matches the asset category they serve:

Bundles/Items/Redirectors/MyItemRedirector.asset
Bundles/Vehicles/Redirectors/MyVehicle_BlueVariant.asset

The folder name Redirectors is a cohort convention, not an engine requirement. The engine discovers .asset files by enumerating all subfolders under Bundles/; the folder name does not affect discovery. The convention is organisational: grouping redirectors in a dedicated folder makes them easy to find, audit, and remove when they are no longer needed.

Authoring a redirector asset: step-by-step workflow

The following workflow documents the cohort procedure for authoring a redirector asset from scratch.

Step 1: Identify the need for a redirector

A redirector is needed when:

• An asset's GUID must change (due to a mod update, a GUID collision, or a GUID migration), and existing references to the old GUID must continue to work.
• A legacy ID collision has been discovered after publication, and the ID cannot be changed because players already have the item in save files.
• A vehicle color variant must exist as a distinct identity point without duplicating the base vehicle asset file.
• An asset has been moved from one mod to another, and references in a third mod that depend on the original GUID must continue to work.

If none of these conditions apply, a redirector is not needed. Do not author redirectors preemptively for assets that have not yet been published; the redirector adds an unnecessary resolution hop.

Step 2: Determine the redirector's GUID

The redirector's GUID is the identity that existing references already point to. If the redirector is being created because an asset's GUID changed, the redirector's GUID is the old GUID. If the redirector is being created to resolve a legacy ID collision, the redirector's GUID should be a freshly generated GUID (the redirector needs its own GUID for registration, even though the primary resolution path is through the legacy ID).

Step 3: Determine the target GUID

The TargetAsset GUID is the GUID of the asset that should be returned when the redirector is resolved. This must be an existing asset's GUID, and the asset must be loaded by the game at the same time as the redirector. If the target asset is in a different mod, both mods must be installed for the redirector to function.

Step 4: Set AssetCategory (if applicable)

If the redirector should also intercept legacy ID references, set AssetCategory to the appropriate asset category and set ID to the legacy ID that should be redirected. The AssetCategory value must match the category of the asset that occupies the legacy ID. A redirector with AssetCategory Item will not intercept legacy ID references for Vehicles, even if the ID matches.

Step 5: Create the .asset file

Create a new .asset file in the appropriate folder under Bundles/. Author the fields in the order: Type, GUID, ID (if applicable), AssetCategory (if applicable), TargetAsset.

Step 6: Test the redirector

1. Load the game with both the redirector and the target asset installed.
2. Test GUID-based references: use a blueprint recipe, spawn table, or other GUID-based reference that points to the redirector's GUID. Confirm the target asset is returned.
3. Test legacy ID references (if AssetCategory is set): use the /give command with the redirector's ID. Confirm the target asset is spawned.
4. Test removal: temporarily remove the redirector and confirm that references to the redirector's GUID now fail (to verify that the redirector was serving as the resolution path and that no other mechanism was providing the resolution).

Redirectors and the master bundle pipeline

Redirector assets do not require a master bundle. Unlike item assets (which need a .unity3d bundle containing a prefab), redirectors are pure data assets with no visual representation. A redirector .asset file placed anywhere under the Bundles/ folder hierarchy is discovered and registered by the engine at load time, with no companion bundle required.

This has a practical implication for mod developers: a compatibility patch that consists solely of redirector assets can be packaged as a tiny mod-a few .asset files in a folder structure, with no bundle, no textures, and no models. The mod's Workshop download size is effectively zero. This is the recommended pattern for distributing redirector-based collision-resolution patches: the patch mod is lightweight, loads quickly, and can be removed cleanly when it is no longer needed.

Folder structure for a redirector-only compatibility patch

MyCompatibilityPatch/
├── Bundles/
│   └── Items/
│       └── Redirectors/
│           ├── RifleCollisionRedirector.asset
│           └── PistolCollisionRedirector.asset
└── README.md

The patch mod has no master bundle, no textures, and no prefabs. The engine discovers the .asset files during its normal folder enumeration and registers the redirectors. The patch mod should be listed as a dependency of the mod that requires it, so that Steam Workshop automatically downloads the patch when the player subscribes to the dependent mod.

Redirector resolution performance considerations

Each redirector adds one additional asset registry lookup to the reference resolution chain. A single-hop redirector (one redirector, one target) adds exactly one extra lookup. In a game that performs thousands of asset reference resolutions per frame (for physics collisions, spawn table rolls, blueprint resolution), the cumulative cost of redirector lookups could theoretically become measurable.

In practice, the cost is negligible for normal mod loadouts. The vast majority of asset references do not pass through redirectors, because only references that specifically target a redirector's GUID or ID are intercepted. A mod with 100 redirectors and 10000 total asset references per frame might see 10 or 20 references pass through redirectors per frame-a cost so small it is not detectable in profiling.

The one scenario where redirector performance could matter is a map that contains thousands of placed objects, all of which reference redirector GUIDs instead of direct asset GUIDs. On map load, each placed object's reference passes through a redirector lookup, and the cumulative time for a very large map with many redirector-mediated references could be noticeable. The cohort recommendation for map authors is to reference assets directly by their primary GUID rather than through redirectors, and to use redirectors only for transitional compatibility during GUID migrations.

Pattern: redirector-based GUID migration for a mod series

When a mod series undergoes a GUID migration (changing every asset's GUID to a new namespace or format), redirectors provide a clean migration path that does not break existing references.

Pre-migration state

Mod v1:
  Rifle: GUID 11111111111111111111111111111111
  Pistol: GUID 22222222222222222222222222222222
  Magazine: GUID 33333333333333333333333333333333

Other mods (map mods, server plugins, spawn table mods) reference these GUIDs.

Migration step 1: Change GUIDs in v2, add redirectors

Mod v2:
  Rifle: GUID AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA  (new GUID)
  Pistol: GUID BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB  (new GUID)
  Magazine: GUID CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC  (new GUID)

  Redirectors (included in v2):
    OldRifleRedirector.asset:    GUID 11111111111111111111111111111111  -> TargetAsset AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
    OldPistolRedirector.asset:   GUID 22222222222222222222222222222222  -> TargetAsset BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
    OldMagazineRedirector.asset: GUID 33333333333333333333333333333333  -> TargetAsset CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

After v2 is published, references to the old GUIDs still work (they resolve through the redirectors), and new references to the new GUIDs work directly. Map mods that were authored against v1 continue to function; map mods authored against v2 use the new GUIDs.

Migration step 2: Deprecate redirectors (optional, long-term)

After all dependent mods have been updated to reference the new GUIDs, the redirectors can be removed from a future version of the mod. This step is optional; the redirectors consume negligible filesystem space and performance overhead, and leaving them in place provides indefinite backwards compatibility for any dependent mod that was never updated.

The cohort recommendation is to leave redirectors in place indefinitely for published mods. Removing redirectors after a deprecation period requires surveying every dependent mod to confirm none still reference the old GUIDs-a survey that is impractical for popular mods with hundreds of downstream consumers.

Worked example: resolving a legacy ID collision with a redirector

A modder publishes a custom rifle mod with the rifle at legacy ID 50001 and GUID a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d. A second modder independently publishes a custom pistol at legacy ID 50001 with GUID f6e5d4c3b2a10987fedcba9876543210. A player who installs both mods discovers that only one of the two items is spawnable via @give PlayerName 50001-which one spawns depends on the mod load order.

Resolution with a redirector (no changes to published files)

Neither modder can change their published legacy ID without breaking save files for existing players. Instead, the first modder publishes a small compatibility patch containing a redirector asset:

Type RedirectorAsset
GUID c1d2e3f4a5b678901234567890abcdef
ID 50001
AssetCategory Item
TargetAsset a1b2c3d4e5f64a7b8c9d0e1f2a3b4c5d

The redirector's ID is set to the conflicting ID (50001). AssetCategory is set to Item. TargetAsset is set to the rifle's GUID. When this redirector is loaded, all legacy ID references to ID 50001 resolve through the redirector to the rifle asset. The pistol asset, which also uses ID 50001, is still registered but its legacy-ID-based references are intercepted by the redirector.

The outcome: the rifle is spawnable via @give PlayerName 50001. The pistol is reachable only by its GUID (through blueprint recipes, spawn tables, and NPC configuration that reference its GUID). This is not a perfect resolution (the pistol's /give command is broken) but it is the best resolution available without changing either published mod's IDs.

Resolution by mutual agreement (changing one ID)

If the two modders can coordinate, the better resolution is for one modder to change their legacy ID in a mod update and publish a redirector for the old ID:

1. Modder B (pistol) changes the pistol's ID from 50001 to 50002 in a mod update.
2. Modder B also publishes a redirector: ID 50001, AssetCategory Item, TargetAsset <pistol's new GUID>.
3. Players who update receive the new pistol file (ID 50002) and the redirector (which maps ID 50001 to the pistol for any player who has not yet updated their save file).
4. After a deprecation period (e.g., one year), Modder B can remove the redirector because all active players will have saved games that reference the pistol's new ID.

This resolution is cleaner because both items eventually use non-colliding IDs and the redirector is a transitional shim, not a permanent fixture.

Frequently asked questions

What is the difference between a redirector asset and a regular asset?

A regular asset (gun, melee, vehicle, resource, object) defines an in-game entity with mechanical properties: damage, speed, health, capacity, and so on. A redirector asset defines no in-game entity; it has no mechanical properties. Its sole function is to redirect asset reference resolution from one GUID or legacy ID to another GUID. A redirector is never spawned, held, placed, or visible to the player.

Can a redirector redirect to another redirector?

Yes. The engine follows redirector chains: if a redirector's TargetAsset points to another redirector, the engine resolves the second redirector and continues following the chain until it reaches a non-redirector asset. In practice, multi-hop redirector chains are unusual and are generally a sign that the asset migration plan was not fully thought through. The cohort recommendation is to keep redirector chains to a single hop.

What happens if TargetAsset points to a GUID that does not exist?

The redirector resolves to nothing. The reference that passed through the redirector produces a broken link: the caller receives a null reference, a default asset, or an error, depending on the asset category and the caller's error-handling behaviour. The exact behaviour is not documented by SDG and may vary by Unturned™ version. The cohort's testing indicates that broken redirector links typically produce a silent failure rather than a visible error message, making them hard to diagnose.

Do I need to assign a legacy ID to a redirector?

Only if the redirector is intended to intercept legacy ID references. A GUID-to-GUID redirector (one that only maps an old GUID to a new GUID) does not need a legacy ID or an AssetCategory. A redirector that resolves a legacy ID collision must have both an ID and an AssetCategory field set.

Can a redirector have its own English.dat file?

No. A redirector is never displayed to the player. It has no in-game name, no inventory icon, and no localized description. A redirector's .asset file contains only the fields documented in this article. Adding an English.dat file to a redirector's folder has no effect; the engine ignores it.

Can I use a redirector to change an item's stats without changing the item's .dat file?

No. A redirector does not modify the target asset's mechanical properties. If the redirector resolves to a gun asset, the gun's damage, range, capacity, and all other mechanical fields are exactly as defined in the gun's own .dat or .asset file. A redirector that points to the gun does not add, override, or remove any of those fields. If you want a variant of an item with different stats, author a separate item asset.

How do redirectors interact with the Export Asset IDs tool?

Redirector assets with an ID and AssetCategory field will appear in the Export Asset IDs CSV for the specified category. The CSV will show the redirector's ID as Reserved (occupied). A modder scanning the CSV for available IDs will see the redirector's ID as occupied and will avoid selecting it, which is the intended behaviour: redirectors should prevent other mods from colliding with the ID they are intercepting.

Can I delete a redirector after publishing it?

You can delete the redirector file, but doing so breaks every reference that was passing through it. Map saves, spawn tables, blueprint recipes, and /give commands that relied on the redirector for resolution will fail. The cohort recommendation is to treat published redirectors as permanent infrastructure. If a redirector must be removed, provide a deprecation period during which consumers of the redirector can update their references to point directly to the target GUID.

How many redirectors can a mod contain?

There is no documented limit on the number of redirector assets a mod can contain. The shipped vanilla asset set includes 128 vehicle color variant redirectors, which demonstrates that redirector counts in the low hundreds are normal and expected. A mod with thousands of redirectors would be unusual but is not known to be prohibited by the engine.

Do redirectors work on dedicated servers?

Yes. Redirector resolution is performed by the engine at the same level as other asset reference resolution. A redirector loaded on the server (or on the client, depending on the reference context) resolves identically to how it resolves in single-player. Server administrators can deploy redirector assets to resolve mod conflicts without requiring client-side changes, provided the conflict is server-side (e.g., a spawn table collision) rather than client-side (e.g., a Workshop mod collision).

Can a redirector point to an asset in a different mod?

Yes. The TargetAsset field contains a GUID, and the GUID is resolved against the global asset registry, which contains assets from all loaded mods. A redirector in Mod A can point to a target asset in Mod B. Both mods must be loaded for the redirector to resolve correctly. If Mod B is not loaded, the redirector's TargetAsset GUID does not exist in the registry and the redirector resolves to nothing.

How do I know if a mod is using redirectors?

Open the mod's Bundles/ folder and search for files with the .asset extension. Open each .asset file and check the Type field. If Type RedirectorAsset is present, the file is a redirector. The file will additionally contain TargetAsset (required) and optionally ID and AssetCategory. A mod that contains only .dat files does not use redirectors, because redirectors use the .asset file format exclusively.

How do redirectors interact with the Bypass_ID_Limit field?

Bypass_ID_Limit is not required on redirector assets, even if the redirector's ID field is above 2000. The Bypass_ID_Limit field applies to item assets that register in the legacy ID table with data that the engine must validate against the ID limit. Redirectors use .asset files, which do not enforce the 2000 ID limit. A redirector with ID 50001 and AssetCategory Item will register at ID 50001 without needing Bypass_ID_Limit True.

Can I use a redirector to merge two mods into one?

Not directly. If two mods share the same GUID (a GUID collision), adding a redirector that claims that GUID will intercept references aimed at both mods' assets and redirect all of them to a single target. The assets from the mod that "loses" the GUID collision become unreachable by GUID. Redirectors do not merge asset data-they redirect references. If two mods define different items with different mechanical properties, a redirector cannot combine them; it can only point references to one or the other.

What happens if I have both a redirector and a regular asset with the same GUID?

At load time, the asset registered last (in filesystem enumeration order) overwrites the earlier entry. If the redirector loads after the regular asset, the redirector replaces the regular asset in the GUID registry, and references to that GUID are redirected. If the regular asset loads after the redirector, the regular asset replaces the redirector, and the redirector has no effect. The load order is not guaranteed to be consistent, so this configuration is a race condition and should never be used intentionally.

What is the difference between a redirector asset and an editor asset redirector?

A redirector asset (this article) is a game-runtime .asset file that redirects GUID and legacy ID references at runtime. An Editor Asset Redirector is an editor-only text file (EditorAssetRedirectors.txt) that replaces objects, resources, materials, and foliage in bulk when loading a map in the level editor. The editor asset redirector operates at editor load time and its changes are saved permanently to the map file. The redirector asset operates at game runtime and its redirections are transparent and non-permanent (the original reference is saved, not the resolved target).

When not to use a redirector

Redirectors are a powerful tool but are not the correct solution for every identity problem. The following scenarios are better solved by other mechanisms:

Problem	Why not a redirector	Better solution
Two mods have the same GUID	A redirector claims the GUID, redirecting both mods' references to one target. The losing mod's asset becomes unreachable by GUID.	Coordinate with the other modder to change one GUID.
A mod item needs different stats for different contexts	Redirectors do not modify mechanical properties. A redirector points to one target asset with one set of stats.	Author separate item assets with different stats.
A map needs to replace many placed objects	Redirectors are permanent and must remain loaded. Map references that save through redirectors break if the redirector is removed.	Use an Editor Asset Redirector to permanently replace the objects in the level editor and save the map with the new references.
A mod wants to hide an asset from players but keep it functional	Redirectors are transparent to resolution but do not hide assets from the asset registry. The target asset is still discoverable by its own GUID.	Author the asset as an internal dependency with no player-facing spawn method.
A mod wants to alias one item name to another	Redirectors redirect references but do not alias display names. The player sees the target asset's display name.	Use the English.dat localization system to provide alternate names.

The critical distinction is that redirectors control identity resolution, not asset behaviour. A redirector changes which asset is returned when a given GUID or ID is referenced; it does not change the returned asset's properties, display name, or in-game behaviour.

Redirector discovery and load order

The engine discovers redirector assets during the same folder-enumeration pass that discovers all other asset types. The enumeration order is filesystem-dependent (NTFS on Windows, ext4 on Linux dedicated servers) and is not guaranteed to be consistent across installations or across game sessions on the same installation.

The load-order implications for redirectors:

1. A redirector must load before the references that depend on it are resolved. In practice, this means the redirector must be in a mod folder that is enumerated before or at the same time as the mod that contains the dependent references. Because all mods are enumerated during a single startup pass, this constraint is almost always satisfied automatically.

2. If two redirectors share the same GUID, the last one loaded wins. The second redirector overwrites the first in the GUID registry. This is the same collision behaviour as regular assets. A mod should never ship two redirectors with the same GUID.

3. A redirector and a regular asset sharing the same GUID is a load-order race condition. The outcome depends on which file the filesystem enumerates last. This configuration should never be used.

4. A redirector and a regular asset sharing the same legacy ID is a load-order race condition. Both register in the legacy ID table, and the last one loaded overwrites the earlier one. This configuration should never be used.

The cohort's defensive practice is to treat redirector GUIDs and IDs as if they are regular asset GUIDs and IDs: every redirector's GUID must be unique across all loaded mods, and every redirector's ID must be unique (or intentionally colliding with the ID it is redirecting, which is the intended use of the legacy ID redirector pattern).

Appendix A: Redirector asset quick-reference card

Property	Value
File format	.asset (not .dat)
Required field	TargetAsset (GUID of the target asset)
Primary identifying field	Type RedirectorAsset
Optional legacy ID field	ID (requires AssetCategory)
Optional category field	AssetCategory (scopes legacy ID redirection to a category)
No mechanical properties	Redirectors carry no damage, speed, health, or other mechanical fields
Invisible to players	Redirectors are never held, placed, or displayed
Resolved transparently	The caller receives the target asset; no indication of redirection
Limitation	Most features save the original reference, not the resolved asset
Vanilla example	128 vehicle color variant redirectors in Bundles/Vehicles/Redirectors/
Chain support	Redirectors can point to other redirectors (multi-hop chains)

Appendix B: Redirector diagnostic table

Symptom	Most likely cause	Resolution
Redirector does not redirect	TargetAsset GUID typo or target asset not loaded	Confirm TargetAsset GUID matches target asset's GUID field exactly; confirm target asset's mod is loaded
/give command does not resolve through redirector	AssetCategory missing or set to wrong category	Add AssetCategory with the correct value (e.g., Item)
Redirector consumes reference but produces nothing	TargetAsset points to nonexistent GUID	Verify the target GUID exists in the loaded asset set
Map objects referencing redirector break after redirector removal	Map saved the redirector GUID, not the resolved GUID	Re-add the redirector; in future, avoid using redirectors for permanent map object references
Two redirectors claim the same GUID	GUID collision between redirectors	Change one redirector's GUID
Redirector appears in Export Asset IDs CSV	Expected behaviour-a redirector with ID and AssetCategory registers in the legacy ID table	No action needed; the redirector's ID appearing as Reserved is the intended behaviour
Vehicle variant does not apply color	Redirector resolves but variant metadata is not applied	Color variant metadata may be stored in a separate configuration file; confirm the variant system is fully configured

Appendix C: External references

• Smartly Dressed Games official modding documentation - Chapter 102: Redirector Assets - the authoritative field reference for redirector assets, including the AssetCategory enum values and the TargetAsset requirement.
• Unturned on Steam - the Unturned™ store page and community hub.
• GUID Type Reference - the companion data-types article covering the 128-bit GUID identity system.
• Legacy ID Availability - the previous article in this section; covers legacy ID allocation, collision detection, and the Export Asset IDs tool.
• Editor Asset Redirector Reference - the next article; covers the editor-specific redirector system that replaces objects, resources, materials, and foliage in bulk during map loading.
• Asset Definitions Reference - the .asset file format reference; covers the syntax, field types, and metadata conventions used by redirector and other .asset files.

Document history

Version	Date	Author	Notes
1.0	2025-05-18	57 Studios	Initial publication. Complete redirector asset reference: field definitions, resolution chain, vehicle color variant redirectors, worked examples, collision resolution pattern, diagnostic table.

Cross-references

• Legacy ID Availability - the previous article; covers the legacy ID system that redirectors bridge to the GUID system.
• Editor Asset Redirector Reference - the next article; covers the editor-level redirector system for bulk object, resource, material, and foliage replacement.
• GUID Type Reference - the companion data-types article covering GUID generation and lifecycle.
• Asset Definitions Reference - the .asset file format used by redirector assets.
• Project Folder Structure and GUIDs - covers GUID generation and folder layout conventions.
• Smartly Dressed Games modding documentation - official field reference for redirector assets.
• Unturned on Steam - game page and community hub.