Frameworks & compatibility
ZAIDERS Appearance finds your framework on its own and saves looks in the tables your server already uses. It also answers the exports and events of the best-known clothing menus, so scripts made for them keep working without changes.
Supported frameworks
| QBCore | Qbox | ESX | |
|---|---|---|---|
| Found as | qb | qbx | esx |
| Looks saved in | playerskins | playerskins | users.skin |
| Model saved as | its number | its name | skinchanger's format, with the exact face inside |
| Money | cash and bank | cash and bank | money and bank |
| Job uniforms and job-only garments | Yes | Yes | Yes |
| Gang uniforms and gang-only garments | Yes | Yes | No (ESX has no gangs) |
| Peds shop | Yes | Peds the server knows by name | Not with skinchanger running |
| Height staff (character height, off out of the box) | ACE or qb-core permissions, or a job from a grade | ACE or qb-core permissions, or a job from a grade | ACE, ESX groups, or a job from a grade |
Config.Framework = 'auto' looks for Qbox, then QBCore, then ESX. The console says which one it found (framework: qb). Without a framework the menu opens, but nothing is charged or saved.
ZAIDERS Appearance reads the looks saved by illenium-appearance, fivem-appearance, qb-clothing and esx_skin as they are. Nobody has to make their character again.
QBCore and Qbox
- New characters: the multicharacter fires qb-clothing's new-character event and the creator opens. See Character creator.
- Qbox: the character screen loads the model by its name, so only peds the server knows by name are saved: the game's peds and your addon peds from the panel. On start, appearances saved with the model as a number are converted to its name, and the console says how many.
ESX
- With esx_multicharacter: keep
esx_skinandskinchangerrunning, because esx_multicharacter needs them to start. New characters are made with esx_skin's menu, and the shops, barber, tattoos and wardrobe are this menu's. Looks are saved in skinchanger's format, which the character screen and esx_skin read, with the exact face inside. When a character joins, this menu puts on the exact face and the tattoos. - Without a multicharacter: you can stop both
esx_skinandskinchanger. This menu answers in their place, with its creator for new characters. - Peds: not sold while skinchanger runs, because skinchanger only keeps the freemode man and woman.
esx_skin:save: wardrobes and lockers that save clothes this way don't save out of the box, because any player can send that event with any clothes, without paying.Config.Compat.esxSkinSave = trueallows it. See What the server checks.
Scripts made for other clothing menus
While these resources are not running, ZAIDERS Appearance answers under their names. Scripts that call them work as they are. Config.Compat.exports = false turns this off.
| What other scripts call | Used by |
|---|---|
exports['illenium-appearance'] and exports['fivem-appearance']: getPedAppearance, setPedAppearance, setPlayerAppearance, setPlayerModel, startPlayerCustomization and the rest of that API | Qbox and many multicharacters |
qb-clothing's events: qb-clothing:client:openMenu, openOutfitMenu (housing wardrobes) and loadOutfit (job uniforms), and exports['qb-clothing']:reloadSkin() | QBCore scripts, housing, jobs |
illenium-appearance's events: open the shops, the outfits and the job uniforms, changeOutfit and reloadSkin | Scripts made for illenium-appearance |
On ESX, skinchanger's and esx_skin's exports and events: GetSkin, LoadSkin, LoadClothes, esx_skin:openSaveableMenu… | ESX scripts |
The usual load events: qb-clothing:client:loadPlayerClothing, qb-clothes:loadPlayerSkin | Multicharacter previews, revive scripts |
Looks put on by other scripts aren't saved
What another script puts on through these exports and events isn't saved. What a player keeps always goes through the shops, where the server checks the price.
Config.Compat.loadSkin puts the saved clothes back on when a character joins, and whenever another script reloads them (after reviving, in a multicharacter's preview). If another clothing resource that answers those events is running, it stays out of the way.
HUDs
While a menu or the panel is open, the HUD hides, and it comes back as it was when the menu closes:
- The game's own HUD always hides. Many server HUDs follow it by themselves.
- Another resource's HUD goes in
Config.HideHud.resources, with its export or its event. - Any other HUD can use
Config.HideHud.custom, or listen to thezaiders_appearance:hudevent.
If a script turns the HUD back on while a menu is open, such as a multicharacter that restores it a few seconds after the spawn while the creator is already open, it hides again. See Config reference and Exports, events & hooks.
Tattoo resources
If a resource from Config.Tattoos.owners is running, ZAIDERS Appearance's tattoo shop turns itself off: its shops leave the map, it doesn't sell, and it doesn't put saved tattoos on. Config.Tattoos.enabled = false turns it off by hand. The console says once, at start, which resource handles the tattoo shop. The tattoo sync stays on either way. When this menu changes the player's model, the client event zaiders_appearance:modelChanged lets that resource put its tattoos back (on ESX, also skinchanger:modelLoaded while skinchanger isn't running). See Tattoo shop.
Opening the menus from your scripts
Housing wardrobes, job lockers and ox_target zones can open any menu:
exports.zaiders_appearance:openShop('clothing') -- 'barber', 'tattoo' or 'wardrobe'A multicharacter or another wardrobe can also use this menu's own exports: getAppearance, setAppearance and reloadSkin in the player's game, and wearOutfit on the server. See Exports, events & hooks.