Admin Tools

mdt_setadmin

Promotes a player to department admin from the server console. Handles every edge case — missing departments, missing ranks, inactive staff, offline players — so you never need to touch raw SQL.

mdt_setadmin <identifier> <job>

What it does

1. Resolves the department — looks up the job in the database. If it doesn't exist yet but is defined in your config, the department is auto-created (including its default admin rank, templates, and licenses).
2. Finds or creates an admin rank — searches for a rank with the wildcard (*) permission. If none exists, creates an "Admin" rank at the highest priority.
3. Resolves the staff record — if the player already has a staff record that is fired, suspended, on leave, or inactive, it reactivates them. If no staff record exists, it creates one (using the player's real name if they're online, or a placeholder "Admin Recovery" if offline).
4. Promotes to admin — sets the staff member's rank to the admin rank.
5. Syncs live state — if the player is online, updates their rank via state bags immediately. Invalidates all rank and permission caches.

Examples

mdt_setadmin license:abc123 police
mdt_setadmin AB12CD34 bcso

Edge cases

mdt_runmigration

Re-runs the full database migration pipeline from the server console. Useful for recovery scenarios or after manual database changes.

mdt_runmigration

What it does

1. Schema transaction — runs all CREATE TABLE IF NOT EXISTS statements for every core table, preserving existing data.
2. Planner queries — executes post-schema changes: column additions (ADD COLUMN IF NOT EXISTS), index creation, ENUM modifications, and framework-specific generated columns.
3. Seed — re-runs the default charges seed (INSERT IGNORE), adding any missing charge entries without duplicating existing ones.
4. Updates KVP — sets the migration version key so the next server boot knows the migration is current.

All steps are idempotent — running this on a healthy database is safe and changes nothing.

When to use

mdt_fixweaponmodels

Repairs existing weapon rows where the model column stores a human-readable label (e.g. AP Pistol) instead of the weapon hash name (e.g. weapon_appistol). Older inventory bridge hooks wrote labels by mistake, which prevented the MDT from resolving weapon images and display names from data/weapons.json.

mdt_fixweaponmodels

What it does

1. Loads data/weapons.json — the canonical map of hash name → label shipped with the resource.
2. Builds a reverse lookup (label → hash) so rows whose model is a known label can be remapped.
3. Scans vx_mdt_weapons for every row with a non-empty model.
4. Classifies each row:
   • Already valid — model is a known hash name (case-insensitive). Skipped.
   • Remappable — model matches a known label. Queued for update to the correct hash.
   • Unmatched — model matches neither. Left untouched and listed at the end of the run.
5. Runs one transaction — all remaps are applied in a single MySQL.transaction.await call.

Example output

[mdt_fixweaponmodels] Scanned 184 rows — 12 already valid, 169 to remap, 3 unmatched
[mdt_fixweaponmodels] Updated 169 weapon row(s).
[mdt_fixweaponmodels] 3 unmatched row(s) left untouched:
  - XJ829S (model: Custom Relic)
  - QQ3341 (model: RP Hammer)
  - MM22C9 (model: Lost MC Blade)

When to use

mdt_refresh_vehicle_cache

Forces a refresh of the vehicle label cache (data/vehicles.json) from a connected client. The cache maps vehicle hashes to display labels and is used to resolve vehicle model names throughout the MDT without needing a connected client on every lookup.

mdt_refresh_vehicle_cache

What it does

1. Guards against re-entry — aborts if a refresh is already in progress (boot, manual, or another concurrent call).
2. Picks the first connected client — issues a server → client callback that enumerates every loaded vehicle model and its GetLabelText-resolved display name.
3. Applies sanity threshold — rejects results below vehicleCache.minExpectedEntries (default 100) to guard against partial client-side failures.
4. Atomic swap + persist — rebinds GLOBAL.STORAGE.VEHICLES (never mutates in place) and writes data/vehicles.json with schema version, count, timestamp, and sv_enforceGameBuild value.

When to use