Installation

Install tCAD on your FiveM server: requirements, the build step that is not optional, server.cfg load order, the first ACE grant, and how to confirm the resource came up.

tCAD has one dependency, no database requirement and no SQL to import. The one step that is easy to skip and that fails silently is the build, so it is first.

Requirements

Requirement	Detail
tLib	v1.0 or newer. tCAD declares `tlib_min_version '1.0'` and reports a shortfall rather than starting broken. Free
A FiveM server	`lua54` and `fx_version 'bodacious'`, both declared by tCAD
A database	Optional. See Storage

tCAD uses six tLib modules: permission, logger, diag, fs, platform and config. All six are declared eagerly in the manifest, because tLib's import layer answers an unknown module name with a truthy proxy rather than nil — so an absent module would otherwise surface as attempt to index a function value halfway down an unrelated file instead of as a missing-module error.

Build it first — this is not optional

A release archive ships both of these already built. A git clone does not, and neither failure announces itself as a missing build.

bash

bun install
bun run build

Output	What it is	Symptom if missing
`client/ui/`	The NUI panel, built from `client/web`. Declared as the `ui_page`	`/tcad` gives you a cursor over a blank screen, silently
`server/dist/bundle.js`	The filesystem bridge. Registers this resource's own file writer	On the `data.json` backend, every write is silently dropped

bun and bunx only. tCAD pins eighty dependency versions exactly and carries two local patches, and npm, yarn and pnpm do not apply them — a floated version drops the patch that keeps the UI from crashing.

Load order

tLib must start before tCAD. If you use a database resource, it starts before both.

cfg

ensure tLib
ensure tDB        # optional — see Storage
ensure tCAD

The resource folder must be named tCAD. The name appears in escrow_ignore paths and in provide 'tCAD', and a renamed folder is the usual cause of an update overwriting a config that was supposed to survive it.

Grant somebody access

The minimum that gets one person in:

cfg

add_ace group.admin "tcad" allow

ACE inheritance applies and every tCAD key shares the tcad. prefix, so that one line grants the whole tree — appropriate for yourself on a test server and for nobody else. Permissions has a per-role starter block and explains which keys reach personal data.

Confirming it came up

Four stages, and knowing which one failed saves the most time. Run these in the server console, not in chat.

Stage	How to confirm it
The config parsed	`tcad_config` reports every key with its resolved value and names anything malformed
The hooks are intact	`tcad_hooks` lists the eight hooks and whether each has the expected signature
A storage backend bound	`tcad_selftest` names the backend it resolved. On JSON, `tcad_writeprobe` proves a write actually lands
The domain works	`tcad_selftest` runs 35 assertions against the live backend and reports pass/fail per case

tcad_selftest is console-only — it has no player, so it proves the server half and nothing else. See Status for what that does and does not cover.

Opening it


Command	`/tcad`. Always works, regardless of the keybind
Keybind	F10 by default, rebindable by each player under Settings → Key Bindings

F10 was chosen after checking tELS, tRadio, tRadar, tDetector, tMenu, tUnit, tAFK and tLib: no t* resource defaults to it. F11 was rejected because pma-voice, bundled inside tELS, defaults cycleproximity to it.

What it writes to disk

On the JSON backend, one file: data.json in the resource folder, plus a data.json.bak rotation. It is created on first boot and holds everything — agencies, departments, calls, records.

It is gitignored and never shipped: a shipped data.json would silently overwrite a server owner's data on update. Storage covers the write path, the recovery path and how to back it up.

Was this page helpful?