Integration

Everything your own resources need in order to talk to this one.

• What you may edit
• Compatibility
• Two kinds of key
• Server exports
• Client exports
• Events
• Recipes
• Adding a language
• Troubleshooting

---

What you may edit

File	Editable	What it is
config.lua	yes	Every tunable
config.lua.example	reference	A pristine copy of the shipped config, for diffing after an update
locales/*.lua	yes	All player-facing text. The whole folder is unlocked and loaded by a glob, so a language file you add is yours and survives updates
customer_client.lua	yes	The client-side exports below
customer_server.lua	yes	The server-side exports below
html/	yes, at your own risk	The NUI. Restyling is fine; changing what it sends is not — the server re-validates everything anyway
install.sql	reference	Reference only — you do not need to run it. Every table the resource owns is created on first start
everything else	no	Encrypted

If you need to change something not on that list, that is a missing config option — open a ticket. An option added for you survives the next update; a workaround does not.

The folder name is locked

The folder must be named exactly nuggs_multicharacter. This is enforced, not advised: the check lives in an encrypted file, there is no config option for it, and under any other name the resource refuses to run — a boxed console error once a minute on the server and on every client, and every player turned away at the connection screen with the fix in the message.

Exports are keyed on the folder name and cannot be aliased, so every exports.nuggs_multicharacter:... call below would stop resolving. The events in the tables further down are built at runtime and would follow a rename into a namespace nothing else is listening on — handlers would simply stop firing, without erroring, which is why the rename is blocked outright rather than left to break quietly later.

A bracketed parent directory is fine ([qbx]/nuggs_multicharacter); only the last path segment is checked. Watch for the suffix an unzip adds on its own — -main, -master, (1), a version number.

To fix: stop the server, rename the folder, make sure server.cfg says ensure nuggs_multicharacter, start again.

---

Compatibility

	Supported
Frameworks	ESX Legacy, QBCore, Qbox (qbx_core)
Detection	automatic, qbx_core → es_extended → qb-core
Override	Config.Framework = "esx" | "qbcore" | "qbox"
Creator driver	skinchanger, or the built-in driver on any framework
Clothing	illenium-appearance, fivem-appearance, qb-clothing, skinchanger/esx_skin, rcore_clothing, bl_appearance, tgiann-clothing, crm-appearance, or anything in Config.Appearance.custom
Clothing override	Config.Appearance.driver, .resource, .publish, .custom
Tattoos	rcore_tattoos, vms_tattooshop, crm-tattoos, qb-tattooshop, esx_tattooshop, or anything in Config.Appearance.tattooCustom. With none installed the clothing resource keeps the ink
Tattoo override	Config.Appearance.tattooResource, .tattooCustom, .tattooKey, .tattooCreator, .tattooSync
Housing / motels	qbx_properties, ps-housing, qb-apartments, qb-houses, esx_property, or anything in Config.Housing.custom
Housing override	Config.Housing.script, .custom
Wardrobes (ESX)	the property datastore — esx_clotheshop, esx_property, anything reading dressing
Wardrobes (QB/Qbox)	player_outfits — illenium-appearance, fivem-appearance, qb-clothing and the housing scripts on top of them
Wardrobe override	Config.OutfitSlots.publish
Database	oxmysql

Where a created character’s appearance goes

A clothing resource that keeps its appearance in playerskins — illenium-appearance, fivem-appearance, qb-clothing — gets a row, written before the player reaches the world. There are two incompatible playerskins shapes, so the right one is chosen from the running resource. Force it with Config.Appearance.publish.

A clothing resource that keeps its own store — bl_appearance, rcore_clothing, tgiann-clothing, crm-appearance — gets the character through its own API instead. Writing playerskins for one of those writes into a table nothing reads: the character spawns in default clothes and the first shop saves those over what the player made.

Where the data shape is not knowable, the handoff reads the ped back — this resource’s driver paints the character, then that resource’s own getter and saver round-trip it through a shape neither side has to agree on. Config.Appearance.custom with just readPed and saveSelf is the whole integration for any clothing resource with a get-from-ped and a save.

Either way, a resource that keeps a worn-tattoo cache is filled as well — otherwise the first shop the player visits saves an empty list over their ink.

Full table: README.md under Clothing.

Starting inside a property

A character who owns a house, flat or motel room gets an arrival card for it. Choosing it lands them at the door and asks the housing script to open it through its own entry point, so the interior, stash, wardrobe and routing bucket are set up by the resource that owns them.

Ownership is read from the housing script’s own table and checked again on the way in. Nothing creates, buys, sells or deletes a property, and no housing table is written to. See README.md under Starting at home.

Starter outfits

Outfits saved on the CLOTHING step live in multicharacter_outfits (what GetCharacterOutfits reads) and are also written into your server’s own wardrobe store:

Store	Shape	Read by
the property datastore, dressing key	{ label, skin }, skin a flat skinchanger table	esx_property’s wardrobe, esx_clotheshop
player_outfits	one row per outfit, components and props arrays	illenium-appearance, fivem-appearance, qb-clothing, the housing scripts built on them

Config.OutfitSlots.publish decides which — "auto", "never", "datastore", "player_outfits", or a list. A store is only used when its table exists.

Entries written from here are tagged: republishing replaces this resource’s own and never touches an outfit the player saved themselves, and deleting a character takes its outfits back out. Characters created before this existed publish theirs on their next login, once each.

---