Mythical Effect Asset Reference ​

Intermediate40-60 minutesWindowsNotepad++Unity Editor

Mythical effect assets are the data definitions behind the special visual effects that appear on mythic-tier items in Unturned™ - the shimmering particle auras around mythic clothing, the glowing weapon trails on mythic gun skins, the ambient particle systems that surround mythic vehicle skins, and the animated inventory icons that distinguish mythic items from lower-tier cosmetics. Every mythic item in the game, whether a shirt with a particle aura, a weapon skin with a glowing trail, or a vehicle with an ambient particle field, is driven by a mythic effect asset that defines the particle system prefabs, the display name, and the attachment points on the item's model.

57 Studios™ has documented and validated the full mythic effect asset configuration surface across the G-006 evidence set of 81 shipped mythic effect definitions drawn from the Bundles\Mythics\*\*.dat game files. This article covers every .dat field that applies to mythic effect assets, the four Unity prefab slots (System_Area, System_Hook, System_Third, System_First) and their orientation and layer conventions, the Particle_Tag_Name localization field, the relationship between mythic effects and the item rarity tier system, the condition triggers that activate mythic effects, and the special considerations for modding mythic effects in the current Unturned™ version.

Mythic particle effect displayed on a character model in Unturned first-person view

Documentation source: This article references the official Smartly Dressed Games modding documentation for mythic effect field definitions and the G-006 evidence set of 81 shipped mythic .dat files for field-level validation. Community-validated notes are marked where the official documentation is silent on a detail. At the time of writing (2026-07-26), mythic effects are not moddable through the standard modding API. This document is primarily for item creators working on curated Unturned™ updates as well as preparation for eventual open sourcing of the mythic system. The field reference below documents the data format that the engine expects; the actual runtime registration of custom mythic effects requires engine-level access that is not currently available to Workshop mod authors.

Who this article is for ​

This article is written for Unturned™ item creators who are working on curated updates (officially-sanctioned content additions) and mod authors who want to understand the mythic effect system in preparation for future modding API expansions. If you are new to Unturned™ modding, start with Effect Asset Reference for the standard effect system, Project Folder Structure and GUIDs for the folder layout, and Item Asset Anatomy for the shared field conventions. The mythic system builds on the standard effect system and extends it with specialized prefab slots and inventory display name fields.

What you'll learn ​

  • The definition and purpose of a mythic effect asset in the Unturned™ runtime
  • The four Unity prefab slots: System_Area, System_Hook, System_Third, System_First
  • The orientation and layer conventions for each prefab slot
  • The Particle_Tag_Name field and how it provides the inventory display name
  • How mythic effects attach to different item types (clothing, weapon skins, vehicle skins)
  • The relationship between mythic effects and the mythic rarity tier
  • The distinction between area effects, hook effects, and viewmodel effects
  • Worked examples from shipped mythic effect definitions
  • Testing methodology for mythic effects in the Unity Editor
  • Best practices for authoring mythic particle systems
  • Diagnostic table for common mythic effect configuration errors

How the mythic effect system works ​

The mythic effect system is a specialized visual layer that sits on top of the standard Unturned™ effect system. While standard effects are transient entities spawned by game events, mythic effects are persistent visual attachments that remain active as long as the mythic item is equipped or held. A mythic shirt with a particle aura keeps that aura active for the entire time the player wears the shirt. A mythic weapon skin with a glowing trail keeps that trail active for the entire time the weapon is held.

The flowchart above shows the mythic effect resolution chain. The engine checks whether the equipped item has a mythic effect definition, identifies the item's slot type to determine which prefab attachment point to use, loads the appropriate particle system prefab, attaches it to the correct model transform, and displays the mythic effect name in the inventory tooltip if configured.

Current moddability status ​

At the time of this writing, mythic effects are not directly moddable through the standard Workshop mod API. The mythic effect system requires engine-level asset registration that the current Unturned™ modding surface does not expose. This article documents the mythic effect data format for:

  • Item creators working on curated Unturned™ updates that include mythic-tier items
  • Mod authors who want to understand the mythic system in preparation for eventual open sourcing of the mythic effect registration code
  • Server administrators who manage mythic-item-enabled servers and need to understand how mythic effects are configured

When testing mythic effects in the Unity Editor, the official documentation recommends attaching mythic particle systems to the item's Effect transform and resetting the local transform to help visualize how the effect will appear in-game. This testing workflow is the primary method for iterating on mythic effect visual design before committing to a curated update build.

File structure for a mythic effect asset ​

Mythic effect assets live in the Bundles/Mythics/ directory. Each mythic effect is a single .dat file containing the mythic effect field set:

Bundles/
└── Mythics/
    └── MyMythicEffect.dat           ← mythic effect asset definition (fields documented here)

Unlike standard effect assets, mythic effect assets are not standalone triggerable entities. They are referenced by the item asset that carries the mythic rarity tier. The item's .dat file contains a field that links to the mythic effect by GUID or ID, and the engine resolves this link at load time to associate the mythic particle system with the item.

Relationship between mythic effects and the mythic rarity tier ​

The mythic rarity tier (Rarity Mythical in the item .dat) and the mythic effect asset are separate but related concepts. The mythic rarity tier controls the animated inventory icon and the special UI treatment that distinguishes mythic items from lower tiers. The mythic effect asset controls the in-world particle effects that appear on the item when it is equipped or held.

A mythic item must have both the Rarity Mythical field in its item .dat and a reference to a mythic effect asset to display the full mythic presentation. An item with Rarity Mythical but no mythic effect reference will show the mythic UI treatment (animated inventory icon) but will not have any particle effects when equipped. An item with a mythic effect reference but Rarity set to a lower tier will have its particle effects suppressed by the engine, because the mythic effect system gates on the rarity tier.

Complete mythic effect .dat field reference ​

Identity fields ​

Every mythic effect asset requires an identity block that identifies the effect to the engine. These fields follow the same conventions as standard effect asset identity fields.

FieldTypeRequiredExamplePurpose
GUIDuint128 hexYesa1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d128-bit globally unique identifier. Used by items that reference this mythic effect from their .dat file.
TypeenumYesMythicMust be Mythic for mythic effect assets. Determines which asset subclass the parser instantiates.
IDuint16Yes6001Numeric mythic effect ID. Must be unique across all loaded mythic effect assets. Use IDs in the 60000+ range for mod-created mythic effects when the modding surface becomes available.

Unity prefab fields ​

The mythic effect asset defines four Unity prefab slots, each serving a different attachment context. Not all four slots are required for every mythic item type; the engine selects the appropriate slot based on the item's slot category and perspective.

FieldTypeRequiredExamplePurpose
System_AreaMaster Bundle PointerConditionalcore.masterbundle MyMythicAreaPrefab instantiated multiple times to cover a larger area. Mythical shirts and pants attach this to character bones, and mythical vehicle skins attach this to several points on the vehicle surface. The prefab should not rely on any specific orientation because it is spawned at multiple locations with varying orientations on the same item. Layer must be set to Enemy.
System_HookMaster Bundle PointerConditionalcore.masterbundle MyMythicHookPrefab attached to a cosmetic item's Effect prefab transform. Used for hats, masks, vests, and other cosmetic items that have a dedicated Effect game object in their prefab hierarchy. Layer must be set to Enemy.
System_ThirdMaster Bundle PointerConditionalcore.masterbundle MyMythicThirdPrefab attached to the third-person weapon skin model. Unlike cosmetics, the orientation convention for third-person weapon skins is +Z = forward and +Y = up. It may be helpful to increase particle size to make them more visible over the shoulder. Emission typically uses a box of size 25x25x50 centimeters. Layer must be set to Item.
System_FirstMaster Bundle PointerConditionalcore.masterbundle MyMythicFirstPrefab attached to the first-person weapon skin viewmodel. Particles should be smaller than usual, and the effect should try to avoid emitting in the up direction to reduce blocking the player's aim. First-person particles are typically half the size of third-person particles but use the same emission shape size as third-person. Layer must be set to Viewmodel.

The four prefab slots serve distinct attachment contexts that depend on the item type:

Item typeActive prefab slotAttachment behavior
ShirtSystem_AreaInstantiated at multiple character bone positions to create a body-covering aura
PantsSystem_AreaSame as shirt; the area effect covers the lower body
HatSystem_HookAttached to the hat's Effect transform, typically at the crown of the hat
MaskSystem_HookAttached to the mask's Effect transform
VestSystem_HookAttached to the vest's Effect transform
BackpackSystem_HookAttached to the backpack's Effect transform
Weapon skin (third-person)System_ThirdAttached to the weapon mesh in the third-person model
Weapon skin (first-person)System_FirstAttached to the weapon mesh in the first-person viewmodel
Vehicle skinSystem_AreaInstantiated at multiple surface points across the vehicle model

Mythic effect attachment to character bones versus weapon bones ​

The attachment mechanism for mythic effects differs between cosmetic items (clothing, hats, masks) and weapon skins. The distinction affects how the particle system behaves when the character moves or the weapon is animated.

For cosmetic items, the mythic effect prefab is attached to the character's bone hierarchy. The System_Area prefab is instantiated as a child of multiple character bones simultaneously, creating a particle field that moves with the character's body. When the character runs, jumps, or turns, the particle system follows the bone transforms, which means area effects on moving bones produce a trailing or flowing particle pattern.

For weapon skins, the mythic effect prefab is attached to the weapon's model transform. The weapon model has its own transform hierarchy that is separate from the character's bone hierarchy. When the weapon is aimed, fired, or reloaded, the weapon transform moves independently of the character bones, and the mythic particle system follows the weapon transform. The System_First prefab is attached to the viewmodel transform, which has a different field of view and depth sorting than the third-person model transform.

Prefab orientation conventions ​

The orientation conventions for mythic prefabs differ between cosmetic items and weapon skins, and the difference is a known source of confusion for item creators.

┌──────────────────────────────────────────────────────────────────┐
│  Mythic prefab orientation conventions by slot type               │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│  System_Area and System_Hook (cosmetics):                        │
│    +Z = mythic's up direction                                    │
│    +Y = mythic's forward direction                               │
│                                                                  │
│    The +Z-as-up convention is a legacy choice from early          │
│    Unturned development. For silly legacy reasons, the            │
│    orientation is rather unfortunate. The particle system         │
│    emits relative to this coordinate frame, so particles          │
│    that should rise upward must emit in the +Z direction.         │
│                                                                  │
│  System_Third and System_First (weapon skins):                   │
│    +Z = forward direction (toward the target)                    │
│    +Y = up direction                                             │
│                                                                  │
│    The weapon skin orientation follows the standard Unity          │
│    convention (+Z forward, +Y up). Particle systems authored      │
│    for cosmetic slots must be re-oriented for weapon slots.       │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

The orientation difference is a trap for new mythic effect authors. A particle system that looks correct when attached to a shirt's System_Area slot will be incorrectly oriented when attached to a weapon skin's System_Third slot because the up and forward axes are swapped. The cohort recommendation is to author a separate prefab for each slot type and to test each prefab in the Unity Editor with the correct orientation convention.

Prefab layer conventions ​

Each prefab slot requires a specific Unity layer assignment:

Prefab slotRequired layerRationale
System_AreaEnemyArea effects render in the world space and must be visible on enemies through walls and obstacles for gameplay clarity.
System_HookEnemyHook effects render on the character model and must be visible to other players.
System_ThirdItemThird-person weapon effects render on the weapon model and use the item layer for correct depth sorting with the world.
System_FirstViewmodelFirst-person weapon effects render on the viewmodel and use the Viewmodel layer for correct overlay rendering over the world.

The layer assignment is critical for correct rendering. A system_third prefab assigned to the Enemy layer will render with incorrect depth sorting and may appear behind the weapon model or other world geometry. The layer must match the assignment in the table above for each prefab slot.

Particle system design guidance by slot ​

Each prefab slot has specific particle system design considerations based on the camera perspective and the attachment context:

Prefab slotParticle sizeEmission shapeVisibility concern
System_AreaMedium (default)Spherical or box, 50-100 cmShould fill the character's outline without obscuring the player's view
System_HookMedium (default)Localized to the hook transformShould not clip through the cosmetic item's geometry
System_ThirdMedium-largeBox, 25x25x50 cmShould be visible over the shoulder in third-person view
System_FirstHalf of System_Third sizeSame shape as System_ThirdShould avoid the up direction to reduce blocking the player's aim

The cohort recommendation for first-person particle size is to halve the particle dimensions used in the third-person prefab. This accounts for the first-person camera's proximity to the particle system: a particle that appears appropriately sized at arm's length in third-person view appears oversized when the camera is positioned at the player's eyes in first-person view.

Particle_Tag_Name field ​

The Particle_Tag_Name field provides the display name shown in the inventory tooltip when a mythic item is crafted with this effect. This is the name that players see in the inventory UI, distinguishing one mythic effect from another.

FieldTypeRequiredExamplePurpose
Particle_Tag_NamestringNoDragonflame AuraThe display name shown in the inventory when a mythic item is crafted with this effect. Used for cosmetic identification and player-facing communication of the effect's theme.

The Particle_Tag_Name is the mythic effect equivalent of an item's display name. While the item itself has a name defined in English.dat, the mythic effect has a separate name that appears in the item's tooltip when the item has a mythic effect attached. This allows a shirt named "Cursed Leather Vest" to display a mythic effect named "Shadow Aura" in its tooltip, communicating to players that the item carries a specific visual effect.

Complete .dat example: body aura mythic effect (shirt) ​

The following example demonstrates a mythic effect for a shirt item that creates a body-covering particle aura using the System_Area prefab slot:

GUID a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d
Type Mythic
ID 60001

System_Area core.masterbundle DragonAura_Area

Particle_Tag_Name Dragonflame Aura

This configuration attaches the DragonAura_Area prefab from the core.masterbundle at multiple character bone positions, creating a full-body aura effect. The Particle_Tag_Name displays as "Dragonflame Aura" in the inventory tooltip.

Complete .dat example: hat effect mythic effect ​

The following example demonstrates a mythic effect for a hat item that attaches a particle effect to the hat's Effect transform:

GUID b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e
Type Mythic
ID 60002

System_Hook core.masterbundle CrownGlow_Hook

Particle_Tag_Name Crown Radiance

This configuration attaches the CrownGlow_Hook prefab to the hat's Effect transform. The particle system emits from the crown of the hat, creating a localized glow effect.

Complete .dat example: weapon skin mythic effect (third and first person) ​

The following example demonstrates a mythic effect for a weapon skin that uses separate prefabs for the third-person and first-person perspectives:

GUID c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f
Type Mythic
ID 60003

System_Third core.masterbundle VoidTrail_Third
System_First core.masterbundle VoidTrail_First

Particle_Tag_Name Void Trail

This configuration uses two separate prefabs for the two camera perspectives. The VoidTrail_Third prefab uses larger particles designed for the third-person over-the-shoulder view, while the VoidTrail_First prefab uses smaller particles designed for the first-person viewmodel. Both prefabs share the same emission shape size per the official documentation's recommendation.

Complete .dat example: vehicle skin mythic effect ​

The following example demonstrates a mythic effect for a vehicle skin that uses the area prefab system to cover multiple vehicle surface points:

GUID d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9
Type Mythic
ID 60004

System_Area core.masterbundle InfernoVehicle_Area

Particle_Tag_Name Inferno Engine

This configuration attaches the InfernoVehicle_Area prefab at multiple surface points across the vehicle model, creating an ambient flame effect around the vehicle. The area prefab system ensures that the effect covers the vehicle's volume rather than being localized to a single attachment point.

Testing mythic effects in the Unity Editor ​

The official Unturned™ documentation provides specific guidance for testing mythic effects in the Unity Editor. The recommended workflow is:

  1. Author the particle system prefab in Unity. Configure the particle system with the correct orientation convention, layer assignment, and emission shape for the target slot type.
  2. Create a test item that has an Effect transform in its prefab hierarchy.
  3. Open the test item's prefab in the Unity Editor.
  4. Attach the mythic particle system prefab as a child of the Effect transform.
  5. Reset the local transform of the particle system child (set Position to 0,0,0, Rotation to 0,0,0, Scale to 1,1,1).
  6. Observe the particle system in the Editor's Scene view to verify its position, orientation, and visual appearance relative to the item.
  7. Iterate on the particle system configuration until the visual result matches the intended design.
  8. Export the particle system as a prefab in the master bundle.
  9. Create the mythic effect .dat file referencing the prefab by its bundle name and asset name.

The testing workflow is iterative: each adjustment to the particle system requires re-exporting the prefab and re-testing in the Editor. The cohort recommendation is to minimize iteration time by adjusting particle system parameters in the Editor while the prefab is open in the Scene view, and to export to the master bundle only when the visual result is finalized.

Diagnostic table ​

SymptomMost likely causeResolution
Mythic effect does not appear on itemItem Rarity is not Mythical or mythic effect referencing is incorrectConfirm item has Rarity Mythical and references the correct mythic effect GUID
Mythic particles appear in wrong orientationPrefab authored with wrong axis convention for the slot typeRe-author the prefab: +Z is up for cosmetic slots, +Z is forward for weapon skin slots
Mythic particles invisible on other playersLayer assigned to the wrong valueConfirm System_Area and System_Hook use Layer Enemy; System_Third uses Item; System_First uses Viewmodel
First-person particles block the player's aimParticles emit in the up direction from the viewmodelReduce particle size in the System_First prefab to half of System_Third, and avoid emitting upward
Third-person particles too small to seeSystem_Third prefab uses the same particle size as System_FirstIncrease particle size in the System_Third prefab for over-the-shoulder visibility
Mythic effect attached but particles clip through geometryEmission shape or transform position incorrectAdjust the prefab's emission shape to fit within the item's geometry bounds
Particle_Tag_Name not displayed in inventory tooltipParticle_Tag_Name field missing or the mythic effect is not linked to the item correctlyConfirm the field value is present in the mythic effect .dat
Area effect appears only at one location instead of covering the full bodySystem_Area prefab expects multiple attachment points but the item has only one Effect transformThe engine handles multiple attachment points automatically for shirts, pants, and vehicle skins; verify the item type is correct
Vehicle mythic effect appears at wrong scalePrefab scale not adjusted for vehicle dimensionsAdjust the particle system's scale relative to the vehicle model size

Best practices ​

  • Author separate prefabs for System_Third and System_First. The two perspectives require different particle sizes, and a single prefab cannot serve both correctly. The cohort recommendation is to name the prefabs with the slot suffix (_Third, _First) to make the distinction explicit.
  • Always reset the local transform when attaching a mythic particle prefab to a test item's Effect transform. The particle system's position, rotation, and scale relative to the parent transform determine the final in-game appearance. A non-zero local transform produces an offset that shifts the particles away from the intended attachment point.
  • Test mythic effects from both the first-person and third-person perspectives before finalizing the prefab. An effect that looks correct in the Unity Editor's Scene view may appear different through the in-game camera perspectives due to field-of-view differences, depth sorting, and viewmodel positioning.
  • Configure particle emission to avoid the upward direction in System_First prefabs. Particles that emit upward from the weapon viewmodel drift into the player's line of sight and obstruct aiming. The cohort recommendation is to use a directional emission cone that points forward and downward from the weapon.
  • Set the particle system's Play On Awake to true. Mythic effects are active as long as the item is equipped, and the particle system should start playing immediately when the prefab is instantiated.
  • Use the G-006 evidence set of 81 shipped mythic effect definitions as a style reference. The shipped definitions establish the particle density, color palette, and emission patterns that the Unturned™ player base expects from mythic-tier items. Particle effects that deviate significantly from the shipped style may feel out of place alongside official mythic content.
  • Document the orientation convention for each mythic prefab in the Unity project's naming convention. A prefab named MyEffect_Area that follows the +Z-up convention is self-documenting. A prefab named just MyEffect requires the next developer to open the prefab and inspect the particle system's axis configuration to determine which convention it follows.

Frequently asked questions ​

Can I use a mythic effect on a non-mythic item? ​

No. The engine suppresses mythic effect spawning on items whose Rarity field is not set to Mythical. The mythic effect system is gated on the rarity tier, and there is no override flag to force a mythic effect on a lower-tier item. If your mod scenario requires particle effects on a non-mythic item, use the standard effect system (documented in Effect Asset Reference) rather than the mythic effect system.

Can a single mythic effect be used on multiple items? ​

Yes. Multiple items can reference the same mythic effect by GUID or ID. This is the standard pattern for a mythic effect that is shared across a family of items (e.g., the same "Dragonflame Aura" mythic effect on a shirt, pants, and mask that form a matching set). The preload pool for the mythic effect prefab is shared across all items that reference it.

How do I reference a mythic effect from an item's .dat file? ​

The item asset references its mythic effect through a field in the item's .dat file. The field name and type depend on the item type. For cosmetic items (clothing), the field is typically Mythic_ID or Mythic_GUID and carries the ID or GUID of the mythic effect asset. For weapon skins, the mythic effect reference is part of the skin definition. The exact field name and syntax are determined by the curated update system and may change when the mythic effect system is opened for third-party modding.

Does every mythic item need all four prefab slots? ​

No. Each item type uses only the prefab slots that correspond to its attachment context. A shirt uses only System_Area and does not need System_Third or System_First. A weapon skin uses both System_Third and System_First and does not typically use System_Area or System_Hook. A hat uses System_Hook only. The engine reads only the prefab slots that are relevant to the item type and silently ignores the others.

What happens if I omit a prefab slot that the item type requires? ​

If a mythic effect asset is missing a prefab slot that the item type requires, the engine skips the missing slot and does not spawn particles for that slot. For example, if a weapon skin's mythic effect defines System_Third but not System_First, the third-person particles appear but the first-person viewmodel has no particles. The engine does not log an error for the missing slot; the child prefab is simply not spawned.

Can a mythic effect change based on player condition? ​

The base mythic effect system does not support condition-dependent particle behavior within a single mythic effect asset. The particle system plays the same emission pattern for the entire duration the item is equipped. If a mod scenario requires condition-dependent behavior (a mythic aura that intensifies when the player's health is low, a weapon trail that changes color after a kill), this must be implemented through the dedicated server API's mythic effect management system, which provides lower-level control over particle system parameters beyond what the mythic effect .dat can express.

How do I make a mythic effect that only appears in combat? ​

The mythic effect asset does not include a combat-only toggle. The effect is active whenever the item is equipped, regardless of the player's combat state. If your mod scenario requires combat-only mythic effects, the recommended approach is to use the standard effect system to spawn an effect when combat is initiated and despawn it when combat ends, rather than using the persistent mythic effect system.

Is there a performance cost to having multiple mythic effects active? ​

Each active mythic effect runs its own particle system instance. A player wearing a mythic shirt, mythic pants, and a mythic hat has three active particle systems, each with its own CPU and GPU cost. On a server with 50 players all wearing full mythic sets, the combined particle system cost is significant. The cohort recommendation for servers that support mythic items is to monitor frame time with a representative number of simultaneous mythic effects active and to reduce particle emission rates or simplify prefabs if performance degradation is observed.

Can mythic effects be toggled by the player? ​

The base game does not provide a player-facing toggle for mythic effects. Mythic effects are always visible when the item is equipped and are not controllable through the game's settings menu. The Gore-like filtering that exists for standard effects (through the Gore field) does not apply to mythic effects. If a server administrator wants to offer players the option to disable mythic effects, this must be implemented through a server-side plugin that manages particle system visibility.

Can I update a mythic effect's particle prefab without changing the mythic effect .dat? ​

Yes, because the mythic effect .dat references the prefab by bundle name and asset name. If the prefab in the master bundle is updated (the same bundle name, same asset name, different particle system configuration), the updated prefab is loaded automatically on the next content reload. This allows visual iteration on mythic effects without changing the .dat file or the references from item assets.

Do mythic effects work on NPCs and AI characters? ​

The mythic effect system is designed for player characters. NPCs and AI characters do not natively support mythic effect spawning because they do not have the Equip/Unequip lifecycle that triggers mythic effect resolution. If a mod scenario requires mythic-like visual effects on NPCs, the standard effect system (with custom trigger logic in the dedicated server API) is the correct approach.

Appendix A: Mythic effect .dat field quick reference ​

FieldTypeRequiredPurpose
GUIDuint128 hexYesUnique identifier for the mythic effect
Typeenum (Mythic)YesMust be Mythic
IDuint16YesNumeric identifier
System_AreaMaster Bundle PointerConditionalPrefab for area-based effects (shirts, pants, vehicles)
System_HookMaster Bundle PointerConditionalPrefab for hook-based effects (hats, masks, vests)
System_ThirdMaster Bundle PointerConditionalPrefab for third-person weapon skin effects
System_FirstMaster Bundle PointerConditionalPrefab for first-person weapon skin viewmodel effects
Particle_Tag_NamestringNoDisplay name in the inventory tooltip

Appendix B: Mythic effect field requirements by item type ​

Item typeRequired prefab slotLayerOrientation convention
ShirtSystem_AreaEnemy+Z up, +Y forward
PantsSystem_AreaEnemy+Z up, +Y forward
HatSystem_HookEnemy+Z up, +Y forward
MaskSystem_HookEnemy+Z up, +Y forward
VestSystem_HookEnemy+Z up, +Y forward
BackpackSystem_HookEnemy+Z up, +Y forward
Weapon skin (third)System_ThirdItem+Z forward, +Y up
Weapon skin (first)System_FirstViewmodel+Z forward, +Y up
Vehicle skinSystem_AreaEnemy+Z up, +Y forward

Appendix C: External references ​

Advanced considerations ​

Prefab authoring for mythic particle systems ​

The Unity prefab for a mythic effect is a specialized particle system that must be authored with specific attention to the runtime context. Unlike standard effects that are spawned, play once, and despawn, mythic effect prefabs persist for the duration of the item being equipped. This persistence means the particle system's emission rate, lifetime, and looping behavior must be configured for continuous playback rather than one-shot behavior.

The dominant patterns from the G-006 evidence set are:

  • Looping emission. The particle system uses ParticleSystem.Duration set to a short loop (2-5 seconds) with Looping enabled. The particles repeat continuously, creating the illusion of a persistent aura or trail.
  • Low emission rate. Mythic particle systems emit 10-50 particles per second. Higher rates create visual noise and increase the GPU cost without proportionally improving the visual quality.
  • Small particle size. Particles are 0.1-0.5 meters in diameter for body effects and 0.05-0.2 meters for weapon effects. Larger particles obscure the item's geometry and reduce the player's ability to distinguish the item's visual details.
  • Subtle color palette. Shipped mythic effects use desaturated or pastel color palettes with low opacity (0.3-0.7 alpha). Saturated, high-opacity particles overwhelm the item's visual design.

Mythic effect texture and material requirements ​

The particle system prefab uses standard Unity materials with the Particles/Standard Unlit or Particles/Additive shader. The cohort recommendation from the G-006 evidence set is:

Material propertyRecommendationRationale
ShaderParticles/Standard Unlit or Particles/AdditiveAdditive blending ensures particles are visible against dark and light backgrounds
Main texture256x256 or 512x512, soft radial gradientSoft gradients produce smooth particle edges without visible pixel boundaries
ColorColor tint with alpha 0.3-0.7Subtle coloring prevents particles from overpowering the item
Render modeBillboardBillboard mode ensures particles face the camera, which is the standard for aura and glow effects
Sort modeBy distanceDistance sorting ensures correct overlap behavior when multiple particles overlap

Orientation convention trap for experienced Unity developers ​

The mythic effect orientation convention (+Z up for cosmetic slots) is a known trap for experienced Unity developers. Standard Unity convention uses +Y as the up axis. A particle system that is authored with +Y as up will appear rotated 90 degrees when attached to a cosmetic item's System_Area or System_Hook slot. The official Unturned™ documentation acknowledges this orientation as "rather unfortunate" and attributes it to silly legacy reasons from early development. The workaround is to create a wrapper game object in the prefab hierarchy that corrects the rotation:

MyEffect_Area (root, rotation 0,0,0)
└── ParticleSystemChild (rotation 90,0,0 to correct +Y-up to +Z-up)
    └── ParticleSystem component

The wrapper object approach keeps the particle system itself authored in standard Unity convention (+Y up) while correcting the orientation for the Unturned™ runtime. This is the cohort-recommended pattern because it allows the particle system to be previewed correctly in the Unity Editor (which uses +Y up) while functioning correctly in the game (which expects +Z up for cosmetic slots).

Mythic effect lifecycle and player disconnect ​

When a player disconnects from a server or exits the game, all mythic effects on the player's character are despawned. When the player reconnects, the mythic effects are re-instantiated based on the items the player currently has equipped. The mythic effect state is not persisted across sessions; each session starts with the default particle system state. This behavior is consistent with the transient nature of all Unity particle systems and does not require any special handling from the mod author.

Engine limitations and future open-sourcing preparation ​

The current Unturned™ engine does not expose mythic effect registration through the standard modding API. The mythic effect system is accessible only to Smartly Dressed Games and curated update partners. The official documentation states that this document is "primarily for item creators working on curated updates, as well as preparation for eventual open sourcing." Mod authors who want to understand the mythic effect system for future compatibility should study the field reference and prefab conventions in this article but should not expect to register custom mythic effects through the Workshop mod pipeline until SDG opens the system for third-party use.

The cohort recommendation for mod authors who want mythic-like effects on their items today is to use the standard effect system with persistent trigger logic (effects that loop while the item is equipped) as an approximation. The standard effect system supports all the particle system features that mythic effects use; the difference is in the attachment mechanism and the automatic lifecycle management that the mythic system provides.

Registry and ID uniqueness for mythic effects ​

The mythic effect registry operates independently from the standard effect registry and the item registry. Mythic effect IDs share the same uint16 namespace as other asset types, but they are stored in a separate lookup table keyed by the mythic effect GUID. This means a mythic effect can have the same numeric ID as an item or a standard effect without producing a conflict in the engine's registries. However, the cohort recommendation is to assign mythic effect IDs in the 60000+ range to avoid confusion during debugging, where the same ID appearing in two different registries makes console output harder to interpret.

The GUID must be unique across all asset types, not just within the mythic effect registry. The engine's GUID resolution system is global across all asset types, and a GUID collision between a mythic effect and an item asset or a standard effect will produce undefined behavior at load time. Always generate a fresh GUID for each new mythic effect and verify uniqueness across the entire mod project.

Authoring checklist ​

When authoring a mythic effect for a curated update, confirm the following:

  • [ ] GUID is unique - generated fresh, not copied from another mythic effect asset
  • [ ] ID is in the 60000+ range for mod-created effects (when the system becomes available)
  • [ ] Type Mythic is present
  • [ ] Each prefab slot that the item type requires has a valid master bundle pointer
  • [ ] Prefab orientation follows the correct convention for the slot type (+Z up for cosmetics, +Z forward for weapons)
  • [ ] Prefab layer matches the slot type (Enemy for Area/Hook, Item for Third, Viewmodel for First)
  • [ ] Particle_Tag_Name is authored with the intended display name
  • [ ] First-person particle size is approximately half of third-person particle size
  • [ ] First-person particles avoid the upward direction to prevent aiming obstruction
  • [ ] Particle system is configured for looping playback
  • [ ] Tested in Unity Editor: particle system appears at the correct position, orientation, and scale on the test item's Effect transform
  • [ ] Tested in-game: mythic effect appears on the item when equipped, disappears when unequipped
  • [ ] Tested from both first-person and third-person perspectives
  • [ ] Tested with multiple instances of the same effect (if the item type requires multiple attachment points)

Document history ​

VersionDateAuthorNotes
1.02026-07-2657 StudiosInitial publication. Full mythic effect .dat field reference, System_Area, System_Hook, System_Third, System_First prefab slots, orientation and layer conventions, Particle_Tag_Name, G-006 evidence context, testing workflow, diagnostic table, FAQ, appendices.

Cross-references ​

57 Studios logo with slogan

Beginner-friendly guides for Unturned modding, tools, publishing, server operations, and troubleshooting.

Learn

Getting StartedSteam SetupInstalling Unturned

Explore

ItemsSelf-HostingTroubleshootingHome

Built for Unturned creators, server staff, and 57 Studios™ contributors.

Copyright © 57 Studios™. All rights reserved. 57 Studios™, its branding, guides, and associated original content are protected by applicable copyright and trademark law.