Clothing and tattoos

Clothing

illenium-appearance, fivem-appearance and qb-clothing keep a character’s appearance in playerskins, so the row is written before the player reaches the world and there is nothing more to do.

Every other clothing resource keeps its appearance in tables of its own, so the character is handed over through that resource’s own API instead.

Resource	Appearance kept in	Handed over with
illenium-appearance	playerskins, illenium shape	the row, plus setPedTattoos
fivem-appearance	playerskins, illenium shape	the same
qb-clothing	playerskins, qb shape	the row
skinchanger / esx_skin	users.skin	the row
bl_appearance	its own appearance table	SavePlayerAppearance / SetPedAppearance
rcore_clothing	its own	setPedSkin, then rcore_clothing:saveCurrentSkin
tgiann-clothing	its own tgiann_skin table	GetPedSkinData, then SaveSkin
crm-appearance	its own	crm_get_ped_appearance, then crm_save_appearance

Detection is automatic and reported in the startup banner. Config.Appearance.resource overrides it on a server running two.

Your own clothing resource goes in Config.Appearance.custom and is used exactly like a built-in one. If it can read an appearance off a ped and save one, that pair is all you need — no data shape to get right:

custom = {
    resource = "my_clothing",
    paintFirst = true,
    readPed = "GetPedAppearance",     -- their getter, called as (ped)
    saveSelf = "SaveAppearance",      -- their saver, handed what it returned
},

The full field list, including the fields for a resource whose data shape you do know, is in Config reference § 7.

tattoos is worth having. These resources build every save from a worn-tattoo list held in memory, so a list nothing filled is an empty one — and the first clothing shop the player visits saves that over their ink.

---

Tattoos

A separate question from clothing. driver is who draws the creator’s ped, resource is who dresses the player, and this is who owns their ink.

A dedicated tattoo script keeps its own store and takes ownership of ped decorations — it clears the ped and redraws from that store whenever anything asks it to. Two resources managing decorations do not merge; whichever drew last wins, which is what “my tattoos flicker” and “my ink vanishes at the clothes shop” are.

Install one and this resource stands down: it stops writing ink into the clothing resource’s record, hides the creator’s TATTOOS step, and asks the tattoo resource to redraw at every point something else has cleared the ped.

Resource	Owns decorations	Keyed on
rcore_tattoos	yes	the account, until its own multichar step is done
vms_tattooshop	yes	the character
crm-tattoos	yes	its own
qb-tattooshop	yes	the character
esx_tattooshop	no	the character
anything else	you say	you say — Config.Appearance.tattooCustom

Detection is automatic and reported on the banner’s tattoos line. Config.Appearance.tattooResource overrides it.

Two settings in other resources

Both are one line, both are silent when wrong, and both are named in the console at boot.

1. Make the tattoo resource key on the character. rcore_tattoos files ink against the licence by default, so all four characters wear character one’s tattoos:

-- rcore_tattoos/config.lua
Config.LicenseWithoutPrefix = true

2. Stop your clothing resource managing decorations as well:

-- illenium-appearance/shared/config.lua
Config.RCoreTattoosCompatibility = true

The creator’s TATTOOS step

Hidden automatically when a tattoo resource owns the ink — ink chosen in the creator would never exist in that resource’s store, so its first repaint removes it and its shop cannot take it off either. Config.Appearance.tattooCreator = "on" forces it back on with that consequence.

From your own scripts

Anything that clears ped decorations should say so:

ClearPedDecorations(ped)
-- ... your own decoration work ...
exports.nuggs_multicharacter:ReapplyTattoos()

Safe to call unconditionally — it returns false and does nothing when no tattoo resource is running. See Integration.

Your own tattoo script goes in Config.Appearance.tattooCustom; every field is a name to call, and the list is in Config reference § 7.

---