Documentation
The open files, the integration points and the tests — everything the resource exposes to other scripts.
config/, custom/ and locales/ are in escrow_ignore, so they stay yours across updates.
Path | What it holds |
|---|---|
| Only what must be known before the database can answer: framework, appearance script, inventory, admin groups |
| — your own fonts, gallery designs, image host allowlist |
| Written by |
| Money and identifiers when no framework is detected |
| Every text, including the Settings panel labels |
Everything else is configured in game — see /tattoocreator → Settings.
Support for an appearance script is two small files, neither of them escrowed.
Half | File | What to change |
|---|---|---|
Put tattoos back after a skin reload |
| Copy the closest file, change the event names, add a line to the list in |
List exported catalog tattoos in that script's menu |
| One line |
The two halves are independent. The first keeps player tattoos on the body; the second only matters if you export catalog tattoos.
The Detection List
qs-appearance, illenium-appearance, fivem-appearance, qb-clothing, rcore_clothing and esx_skin / skinchanger are auto-detected. With two installed at once, Config.AppearancePin decides which one wins.
The Signal That Matters
Our decorations are re-applied on top of whatever the appearance script applies, when that script says so:
'qs-appearance:client:tattoosApplied' -- fired after every clear it makes
'rcore_tattoos:applyOwnedTattoos' -- illenium, with RCoreTattoosCompatibilityWithout that signal, a change inside the appearance menu is only caught by the watchdog a few seconds later. If your script fires something equivalent, point the adapter at it and the blink disappears.
A tattoo menu poses the ped and bares the body part it works on, so an inventory that syncs clothing off the ped has to stand down while one is open — otherwise it reads a stripped ped and hands out or takes away clothing nobody touched.
qs-inventory is auto-detected and switched automatically. For anything else:
Copy client/custom/inventory/standalone.lua.
Point it at your export.
Add the resource to the inventories list in config/config.lua.
Both the studio and the customer's live view raise the switch on open and drop it on close — and a resource restart with the menu open drops it too.
ESX, QBCore and Qbox are auto-detected. Anything else runs in standalone mode.
Edit custom/<framework>/server.lua — the surface is small on purpose:
Function | Purpose |
|---|---|
| Who may open the creator. ESX groups via |
Money | Charging a customer, paying a commission, moving the till |
Identifiers | Which character a tattoo belongs to |
There are no ACE lines to add — admins are whoever your framework calls admin.
An export turns a design into a standalone tattoo other scripts can list and apply, published as a normal GTA tattoo with one male and one female preset per item.
Mode | What happens |
|---|---|
| Write the block and bounce the appearance resource |
| Write only |
| Do nothing |
The catalog is maintained as a marked block inside the appearance script's own tattoo file, so the name other scripts reference never changes when you re-bake an entry.
The restart can never loop: the block is remembered in memory, the write is read back before anything is bounced, and a cooldown caps it at one restart per change.
A framework-agnostic copy for wiring any other script lands in qs-tattoo-data/integrations/.
What | Where |
|---|---|
Worn tattoos, AI pictures, uploads, exported catalog |
|
Settings |
|
Everything else |
|
The database keeps file names only, never paths. Moving the server to another folder or machine is safe as long as
qs-tattoo-datamoves with it.