Skip to content

4. Character rules

Name, age and height limits. Shared, so the form in the UI and the check on the server can never disagree about what counts as valid.

The player’s own wardrobe: the starter outfits saved on the CLOTHING step. These are empty slots, not presets — SAVE writes whatever the character is wearing into the slot, and clicking the tile puts it back on. A slot left unnamed keeps “Outfit 1”, “Outfit 2” and so on (locale key outfit_slot_name).

Slots are held for the whole of creation and saved with the character.

Config.OutfitSlots must stay in the shared section, above if IsDuplicityVersion() then. The server builds its outfit key whitelist from keys; moving it into the client block empties that whitelist and silently discards every outfit a player saves.

Key Notes
count How many tiles the row offers. The grid is four-up, so more than four wraps onto a second line
publish Where a saved outfit is also written
keys The keys a SAVE takes a copy of
autoSaveSuggested Clicking a suggested outfit files it into a slot as well as wearing it
guaranteeOutfit A player who saved nothing keeps what they had on as slot 1

Default true. A player who clicks a suggested outfit on IDENTITY has chosen that outfit, and it is filed into a starter slot under the preset’s own name rather than only being worn. Without this, a player who never opened the wardrobe panel arrived with an empty wardrobe having believed they had picked an outfit.

The rules it files by:

  • Clicking the same suggestion twice reuses its slot. Four suggestions fill four slots however many times they are clicked, and the wardrobe never holds the same look twice.
  • An empty slot is taken before anything is displaced.
  • A slot the player saved or named themselves is never touched. Once every slot is theirs, a click dresses the character and files nothing.
  • Once the slots are full, the oldest filed suggestion is recycled — relevant only when you offer more suggestions in Config.Outfits than you have slots.
  • SAVE, a rename, or CLEAR takes a slot over. From then on it is the player’s, and no later click will recycle it.

Filed tiles are drawn with a dotted edge so a player can see which ones arrived with a suggestion and are theirs to write over.

Set it to false to go back to a click only dressing the character.

Default true. If the player saved nothing at all, whatever the character has on when CREATE is pressed goes into slot 1, named from the outfit_starter_name locale key.

Their clothes reach the world either way — that is the character’s appearance and it is saved regardless. This is about the wardrobe having something in it: the first time anything puts them in a uniform, a job outfit, a revive or a prison change, an empty wardrobe leaves them with nothing to change back into.

Set it to false to let a player arrive with an empty wardrobe.

This resource keeps its own copy either way (multicharacter_outfits, what GetCharacterOutfits reads) — but a wardrobe in a house, a clothing shop and a changing room each read their own store. Without this, an outfit saved in the creator exists and cannot be worn.

Value Where it writes
"auto" Every store this server actually has
"never" Keep the outfits to ourselves
"datastore" The property datastore under its dressing key — esx_clotheshop writes here, esx_property’s wardrobe reads it
"player_outfits" The shared table used by illenium-appearance, fivem-appearance, qb-clothing and the housing scripts built on them

A list writes to several: { "datastore", "player_outfits" }. Naming a store that is not there is reported in the console rather than failing quietly.

Outfits written from here are tagged: republishing replaces this resource’s own entries and never touches one the player saved themselves, and deleting a character takes its outfits back out.

Clothing and accessories only — hair, face and skin belong to the character, not the outfit. Every name must be a key skinchanger knows and this creator has a control for; a key the ped does not have is skipped rather than erroring.