Start from a release and retain its version
The project README directs users to releases rather than main. This guide reviews v5.7.0 at commit 1b003ec169b15f145d519438ba7c6454bf746f27. Its linked installation page returned 404 during the November 7, 2026 review, so this page does not reproduce an unverified replacement recipe.
Use the release source and the project’s current support route to obtain the instructions matching your package. Keep the archive version, framework revision and existing appearance resource together in your rollout notes. A fork or redesign can differ from the release reviewed here.
Check framework and database integration before replacing clothing
The release README lists qb-core, ESX and ox_core, with ox_core marked experimental. It lists the corresponding framework dependency and ox_lib, with qb-target optional for QBCore. The manifest also imports the OxMySQL Lua library and includes framework-specific client and server adapters.
For ESX, record the actual es_extended revision, existing skin and appearance resources and the character-loading path. Identify which package currently saves and restores appearance. Do not remove a working resource before rehearsing the replacement and its data requirements on staging.
Follow the release’s actual database and framework instructions rather than borrowing table changes from another fork. Preserve a recoverable copy and compare both existing characters and newly created ones. A new-character menu opening does not establish that historical appearances migrated correctly.
Keep costs, tattoo charging and target access distinct
In the reviewed shared/config.lua, clothing, barber, tattoo and surgeon costs have separate settings. ChargePerTattoo changes tattoo charging behavior, while UseTarget selects a target-related option. A nearby menu appearing does not prove the resulting charge or save operation is correct.
Choose the intended policy first, then test the observable result with synthetic staging characters. Compare preview, confirmation, cancellation and insufficient-funds behavior according to the configured framework. Do not assume that changing one cost field updates every service or UI label.
Use a saved-appearance acceptance matrix
The following is a proposed test plan, not runtime evidence from Magnate. Define expected behavior from your server policy and exact package version. Keep character identity separate from an outfit name or sharing code.
| Scenario | What to verify |
|---|---|
| Existing character joins | Expected saved model and appearance load |
| New character completes setup | Appearance persists after the intended creation flow |
| Player confirms an edit | Expected charge and saved result agree |
| Player cancels an edit | Cancellation follows the configured policy |
| Saved outfit is selected | Model, components and props match the intended outfit |
| Job outfit is used | Role restrictions and reconnect behavior match policy |
| Reconnect or restart | The expected saved appearance returns without duplicate menus |
Evaluate a redesign as another integration change
A redesign can alter the frontend while depending on the original backend contract. Record the upstream version it targets and the files it replaces. A screenshot of a modern menu does not establish compatible save callbacks, translations or framework adapters.
Compare an unmodified staging release with the redesign using the same test character. Exercise preview, save, cancel and reconnect paths. If only the redesigned interface fails, inspect that change before altering saved player data.
Keep custom frontend files recoverable during updates and preserve required attribution and licensing information. This guide does not rank or benchmark redesign vendors, and it does not provide redistributed appearance packages.
Diagnose the right layer when appearance does not persist
Separate an interface that never opens, a save request that fails and a successful save followed by an incorrect restore. Record the first failing step and relevant redacted error. A blank menu does not justify a generic database migration.
If outfits appear wrong after adding clothing, compare the loaded asset collections and the saved component references. A sharing code is not a clothing download. Our outfit-code guide covers that distinction and the clothing-pack guide covers asset integration.
Use the OxMySQL guide for database connectivity checks, then verify the owning appearance resource’s schema and workflow separately. Magnate has not run a skin migration, changed player records or established GTA VI compatibility for this resource.
Questions, answered.
Should I download illenium-appearance from main?
The reviewed project README directs users to releases and discourages using main.
Does this guide provide a tested ESX migration?
No. It reviews release files and provides staging checks. Match the actual framework and migration instructions for your installation.
Does an Illenium Appearance redesign prove the backend is compatible?
No. Verify the upstream version, callback contract and save/cancel/reconnect behavior with the actual redesign.
Sources & editorial notes
Source review: November 7, 2026. Platform announcements can change. This guide separates published facts from Magnate’s original analysis and preparation advice.
- illenium-appearance — v5.7.0 README Release-specific framework requirements and guidance; linked installation page returned 404 at review.
- illenium-appearance — v5.7.0 manifest Framework adapters and database import; reviewed November 7, 2026.
- illenium-appearance — v5.7.0 configuration Cost, tattoo and target settings; not a runtime-tested configuration.
Published by an independent editorial brand. Read our editorial standards.