Documentation Index
Fetch the complete documentation index at: https://docs.cc-scripts.com/llms.txt
Use this file to discover all available pages before exploring further.
cc_lib is the glue layer the rest of the CC Scripts stack builds on. It wraps third-party resources (qbx_core, ox_inventory, ox_target, ox_doorlock, ox_lib, qbx_vehiclekeys) behind a stable, named API, and ships its own TaskUI — the on-screen task list with a master countdown and per-task checkbox/counter/timer chips.
If you swap an underlying resource later, the wrapper changes; your heist code doesn’t.
At a glance
Single export
Everything is reached via
local cc = exports.cc_lib:GetLib(). There’s one shape on the client and one on the server.Module auto-detection
On resource start,
cc_lib probes for the supported backing resources and loads the matching adapter. Missing? The module slot is simply absent — calls error early instead of silently no-op’ing.TaskUI
Server-authoritative task list rendered as a corner NUI. Master timer, per-task status, per-task counter chips, and per-task countdown chips. Survives respawn via auto re-sync.
Used everywhere
cc_heistcontracts, cc_pacificheist, cc_paletoheist, cc_fleecaheist all depend on this. Boot order matters — see Installation.What’s inside
TaskUI
Full TaskUI reference: list lifecycle, master timer, task status, counter chips, and per-task countdown timers.
Module reference
Every adapter module —
Core, Inventory, Groups, Doorlock, Notification, Target, Interface, VehicleKeys — and what backing resource each one wraps.Calling shape
Notification and Core are server-only; Target and Interface are client-only. The full table is in the Module reference.
Modules whose backing resource isn’t running are absent from the cc table — guard with if cc.Inventory then ... if you can’t assume the dependency is up.