Skip to main content

Data Format

XDEV Appearance internally uses structured appearance data to synchronize:

  • clothing
  • props
  • overlays
  • tattoos
  • peddata
  • facial structure

This document explains the internal format philosophy and supported structures.

System Philosophy

Unlike many appearance systems, XDEV intentionally separates:

appearance
tattoos
peddata
outfits
cache data

into modular structures.

Purpose:

  • cleaner synchronization
  • compatibility support
  • rebuild reliability
  • easier conversions

Main Appearance Structure

Typical appearance structure:

{
    model = "",
    hair = {},
    headBlend = {},
    faceFeatures = {},
    headOverlays = {},
    eyeColor = 0,
    components = {},
    props = {},
    tattoos = {}
}

Model

Stores the active ped model.

Example:

model = "mp_m_freemode_01"

Used for:

  • ped rebuilding
  • compatibility validation
  • synchronization workflows

Hair Structure

Example:

hair = {
    style = 0,
    texture = 0,
    color = 0,
    highlight = 0
}

Supported values:

style
texture
color
highlight

Head Blend Structure

Example:

headBlend = {
    shapeFirst = 0,
    shapeSecond = 0,
    skinFirst = 0,
    skinSecond = 0,
    shapeMix = 0.0,
    skinMix = 0.0
}

Purpose:

facial genetics
skin blending
parent mixing

Face Features Structure

Example:

faceFeatures = {
    noseWidth = 0,
    jawBoneWidth = 0,
    chinBoneSize = 0
}

Supported categories include:

nose
jaw
chin
cheeks
eyes
neck
lips

Head Overlays Structure

Example:

headOverlays = {
    beard = {
        style = 0,
        opacity = 0,
        color = 1,
        secondColor = 0
    }
}

Supported overlay values:

style
opacity
color
secondColor

Overlay Notes

Some overlays support color palettes while others only support opacity.

Typical colored overlays:

beard
eyebrows
makeup
lipstick
blush

Eye Color Structure

Example:

eyeColor = 0

Used during:

  • surgeon workflows
  • face rebuilding
  • cache synchronization

Components Structure

Components represent GTA clothing categories.

Example:

components = {
    {
        component_id = 11,
        drawable = 5,
        texture = 0
    }
}

Supported values:

component_id
drawable
texture

Props Structure

Props represent removable GTA accessories.

Example:

props = {
    {
        prop_id = 0,
        drawable = -1,
        texture = -1
    }
}

Using:

drawable = -1

removes the prop completely.

Tattoos Structure

Example:

tattoos = {
    ZONE_HEAD = {
        {
            name = "TAT_BB_021",
            opacity = 0.4
        }
    }
}

Supported values:

name
opacity
zone
collection
hashes

depending on synchronization stage.

peddata Structure

The peddata system exists primarily for:

custom peds
addon peds
ped rebuilding
advanced synchronization

Unlike many appearance systems, XDEV separates ped-specific appearance data from freemode structures.

Outfit Data Structure

Outfits intentionally use lightweight structures.

Example:

{
    components = {},
    props = {}
}

Purpose:

preserve identity data
avoid face overwrites
simplify synchronization

Cache Data Structure

Face cache structures typically contain:

{
    headBlend = {},
    faceFeatures = {},
    headOverlays = {},
    eyeColor = 0,
    hair = {}
}

without clothing or tattoo data.

Compare Workflows

The system may internally compare values before saving.

Common compare targets:

item
texture
mix
opacity
color

Purpose:

  • reduce redundant saves
  • optimize synchronization
  • avoid unnecessary updates

Compatibility Structures

The converter layer supports structures from:

Illenium Appearance
legacy appearance systems
custom frameworks

through internal rebuild workflows.

Serialization

Most appearance structures are stored using:

JSON encoding

inside SQL tables.

Typical fields:

skin
tattoo
peddata
components
props

Synchronization Philosophy

XDEV intentionally rebuilds appearance from multiple synchronized structures instead of relying on a single monolithic blob.

Purpose:

better rebuild reliability
modularity
compatibility support
ped synchronization

Developer Notes

The resource intentionally avoids forcing a single rigid appearance structure.

Instead, the architecture focuses on:

conversion
modularity
compatibility
rebuild safety

to simplify long-term maintenance and migrations.