Kartik Scripts

Access Control & Blacklists

Everything that decides who may wear what, and where they may buy it, in one place.

There are four independent layers. They stack, and none of them requires editing a config file:

LayerQuestion it answersWhere you set it
๐Ÿฌ Store accessWho can open this store at all, and what does it sell?/shopmanager UI
๐Ÿ”’ Item locksWho may wear this specific garment or colour?LOCK EDITOR in any clothing shop
๐Ÿšซ BlacklistShould this garment exist for anyone?LOCK EDITOR โ†’ Blacklist entirely
๐Ÿง‘ Ped accessWhich ped models may this player use?/pedunlock ยท /pedlock

[!TIP] Coming from illenium-appearance? Their Config.Blacklist imports straight into layers 2 and 3, paste it into /shopmanager โ†’ Blacklist Import. See Blacklist Import (illenium).

[!IMPORTANT] All four are enforced server side. The UI is authoring only, a spoofed NUI, a modified client, or a player who never opened a shop still cannot save a garment they are not entitled to. On save the server re-resolves every lock and replaces anything disallowed with the slot's value from Config.BareDefaults.


๐Ÿฌ Layer 1, Store Access (/shopmanager)

This is the layer people usually mean by "assign clothing to different areas".

Each store is its own row in kc_shops, created and edited in the /shopmanager UI:

  • Required Job: leave blank for a public store, or set a job so only that job can buy there. The server re-checks it on every purchase. The Job Locked card on the Shop Overview counts these stores.
  • Shop type: clothing, barber, tattoo, wardrobe, ped changer, or job store. The type decides which categories (from shared/categories.lua) the store shows; per-store category lists are not supported yet.
  • Price multiplier: per-store pricing on top of Config.Prices.
  • Placement: coords, heading, blip sprite and colour, and the interaction zone (built with the 3D Zone Builder).

Nothing here needs a restart. See Dynamic Shop Manager.


๐Ÿ”’ Layer 2 & 3, Item Locks and Blacklists (in the shop UI)

The full walkthrough lives in Item Locks & Restricted Clothing. The short version:

  1. Open any clothing shop as an admin (/clothing).
  2. Press LOCK EDITOR, the button sits at the top of the garment grid, next to COMPAT EDITOR. It only renders for admins.
  3. Every garment tile now shows its id and a pencil. Click the pencil on the garment you want to restrict.
  4. In the panel:
    • Tick Blacklist entirely โ†’ nobody wears it. This is your blacklist.
    • Or add + JOB / + CITIZEN ID rules โ†’ only those people wear it.
  5. SAVE LOCK.

To undo, open the same garment and press REMOVE LOCK / REMOVE BLACKLIST.

[!TIP] While the editor is armed, restricted garments stay visible to you even when Config.ItemLocksShowLocked = false, you cannot lock what you cannot see.

The equivalent commands (/lockitem, /lockworn, /unlockitem, /itemlocks) do exactly the same thing and write the same rows. Use them for bulk work or from the server console; the UI is the intended path for everyday use. See Item Lock Commands.


๐Ÿง‘ Layer 4, Ped Access

Custom ped models from Config.Peds are entitlements rather than locks: a player must hold an unlock to pick that ped.

/pedunlock a_m_y_hipster_01 ABC12345
/pedlock   a_m_y_hipster_01 ABC12345
/pedstatus ABC12345

Behaviour switches (Config.PedShopOwnersOnly, Config.PedUnlocksAreSingleUse, Config.PedAdminBypass, Config.PedChangeCooldown, Config.PedsShowLocked) are in Configuration. See Ped Catalog & Unlocks.


โš™๏ธ The Only Config Keys Involved

Restrictions themselves are data, not config. These four switches change how they behave:

-- shared/config.lua
Config.ItemLocksShowLocked   = true   -- grey out restricted garments (true) or hide them (false)
Config.ItemLocksAdminBypass  = false  -- may admins wear restricted garments?
Config.PedsShowLocked        = true   -- same idea for peds
Config.AdminOnlyCommands     = true   -- gate the appearance/shop command names to admins

Config.AdminOnlyCommands gates command names only. Permission for the actions (saving a lock, granting a ped, approving a design) is always re-checked server side, whichever framework you run, see Admin Guide.


๐Ÿง  Rule Semantics (worth knowing once)

  • Rules OR together. A garment with job:police:2 and cid:ABC12345 is wearable by police grade 2+ and by that one citizen.
  • min_grade is a minimum, not an exact grade.
  • A lock with no rules and no blacklist is wearable by nobody. Both the UI and the commands fail closed on purpose; the UI refuses to save one and tells you to tick Blacklist if that is what you meant.
  • Scope is matched most specific first: a colour-scoped lock beats a whole-garment lock, and a body-scoped lock beats both bodies.
  • Drawable ids do not line up between male and female peds. Lock from the body you read the garment on, or you will restrict an unrelated garment on the other one.

โณ Not Yet Covered

Being transparent about the gaps, since they come up often:

RequestStatus
Blacklisting tattoosNot supported yet. Config.Tattoos in shared/config_tattoos.lua is a catalog with no lock layer, so the only way to remove a tattoo today is to delete or comment out its entry. Locking tattoos by job/gang is planned.

๐Ÿ”Œ For Developers

-- Every lock and its rules
local locks = exports['kartik-clothing']:getItemLocks()

-- Whether one player may wear one garment right now
if not exports['kartik-clothing']:mayWearItem(source, 'component', 11, 84) then
    -- refuse the uniform issue
end

See getItemLocks and mayWearItem.

On this page