Qbox MDT ScriptA FiveM MDT for qbx_core, ox_lib & oxmysql — through one open bridge
What a Qbox MDT script is
A Qbox MDT script is a police MDT/CAD resource built for the Qbox framework: it reads identity, job and grade from qbx_core, uses ox_lib callbacks and menus, stores citizenid-keyed records through oxmysql, and uses ox_target for world interactions. CaseLink MDT is designed to run on that stack through the free, open ForgeCore bridge rather than calling qbx_core directly. It is in development — no runtime proof published, pending Shadow bench — and there is no purchase path.
On Qbox, “supported” usually means a QBCore build with a shim. This page is about the difference.
An MDT is the piece every police department touches every shift, and it's usually the piece that knows the least. It doesn't know what the evidence system logged, the dispatch call it was attached to, or the charge history sitting in another resource's table. So officers narrate the record to each other over voice, the story lives in someone's memory instead of the database, and the scene dies while three people type the same information into three places.
Status honesty: CaseLink MDT is in development. No runtime proof is published — pending Shadow bench — so nothing on this page rests on a performance number. The price shown is a planned target pending the studio pricing lock, not an offer. There is no checkout path on this page or anywhere on this site.
oxmysql → ox_lib → qbx_core → ox_target → ForgeCore → CaseLink.
What actually loads, in the order it matters. The first four are public projects you can read; ForgeCore is free and unescrowed; the last is ours and in development. Longer framework context lives on the Qbox hub.
01oxmysql
The database driverEvery durable MDT row — cases, citizen records, charges, BOLOs, dispatch calls, the audit trail — goes through oxmysql. On Qbox this is not a choice; qbx_core itself requires it. An MDT that ships its own MySQL layer on a Qbox server is duplicating the one already running.
02ox_lib
Callbacks, context menus, progress, notificationsQbox standardizes on ox_lib for the client-server callback pattern (lib.callback) and for UI primitives. An MDT written for Qbox uses lib.callback to Await server reads instead of a framework-specific callback registrar, and ox_lib context menus for the entry points that are not the terminal itself.
03qbx_core
Identity, job and gradeqbx_core is the framework. It owns the player object (PlayerData with citizenid, license, name, job and money), and its job.grade is a table with a level — not a bare number as older code sometimes assumes. Officer authority on a Qbox MDT has to come from this object, read on the server.
04ox_target
World interactions (optional)Qbox servers replace qb-target with ox_target. An MDT rarely needs a target zone for the terminal itself — a command, keybind or item is the normal entry — but any 'search this vehicle' or 'run this plate at the kiosk' interaction on a Qbox build should be an ox_target option, not a qb-target one.
05vf_core (ForgeCore)
The bridge the MDT calls instead of qbx_coreCaseLink is designed to call ForgeCore, never qbx_core directly. ForgeCore's Qbox adapter is the single file allowed to call qbx_core exports; it normalizes the Qbox player shape into one bridge contract and the MDT reads identity, job and grade through that. ForgeCore is free and 100% unescrowed, so the entire Qbox seam is readable before anything paid is installed.
06vf_mdt (CaseLink)
The case spineHard dependencies are designed to be exactly two: vf_core and oxmysql. ox_lib is optional with a native fallback for menus and progress; the crime-economy dispatch seams (Heatline, TurfLedger) are optional and inert when absent rather than a load-order crash. That is the intent — nothing here has runtime proof yet.
One adapter file, and the MDT never touches qbx_core.
Written from ForgeCore's own Qbox adapter, which is open source and free. Every claim in this section is a file you can open.
Detects Qbox at boot, or takes a forced setting
ForgeCore checks whether qbx_core is started and selects the Qbox adapter; qb-core and es_extended are checked next, and a server with none of them gets a standalone adapter. Config.Framework can force 'qbox' explicitly, and an unrecognised value logs an error and falls back to auto-detect rather than silently picking wrong. If a framework starts after ForgeCore (a real server.cfg ordering gotcha), the bridge re-evaluates instead of holding a stale adapter.
Normalises the Qbox player shape once
The adapter reads exports.qbx_core:GetPlayer(source) and flattens PlayerData into one bridge player: identifier, name, and a job table with name, label and a numeric grade taken from job.grade.level. The MDT never sees the raw qbx_core object, which is why a change in qbx_core's shape is a one-file fix in an open resource rather than a hunt through escrowed business logic.
Officer authority is resolved on the server, from the job
CaseLink's authority resolver is designed to read the police job and grade through the bridge (Bridge.GetJob) and map job/grade to officer permissions from an owner-editable config file. The client computes no authority and holds no authoritative state: a non-officer who opens the terminal is denied on the first authority-gated read and the panel never focuses.
Permissions: prefer the job map, watch qbx_core's ACE direction
qbx_core has been moving its own permission helpers toward FiveM's native ACE system. A Qbox MDT should therefore not depend on framework permission functions that may be deprecated; CaseLink's design uses job/grade mapping via the bridge for officer authority and reserves ACE-style permissions for admin commands. Check the current qbx_core documentation for the state of that deprecation before you rely on either.
The data travels. The code is the work.
Six things that change when an MDT moves with a server from QBCore to Qbox. The general migration picture is in the framework lock-in guide; this is the MDT-specific list.
01 · Keep the citizenid-keyed data
Qbox is a maintained fork of QBCore, and the citizenid survives the move. An MDT whose reports, charges and warrants are keyed on citizenid can carry its tables across; the join between a citizen and their rap sheet does not have to be rebuilt. This is the single biggest reason the QBCore → Qbox move is cheaper than any move involving ESX, where identity is a different string altogether.
02 · Replace the core export name
Anything that calls exports['qb-core']:GetCoreObject() or hard-codes the qb-core resource name has to change. This is where most 'Qbox supported' claims turn out to be a compatibility branch: the code still asks for qb-core and depends on a shim to answer. A bridge removes the question — the MDT asks ForgeCore, ForgeCore asks whichever core is running.
03 · Move callbacks to lib.callback
QBCore.Functions.CreateCallback / TriggerCallback becomes lib.callback.register / lib.callback.await. An MDT is mostly server reads — lookup, search, open case, load the dispatch board — so this touches every read path. It is mechanical, but it is not free.
04 · Swap qb-target for ox_target and qb-menu for ox_lib
Any target zone (a plate reader, an evidence locker, a station kiosk) is rewritten as an ox_target option; any qb-menu or qb-input surface becomes an ox_lib context menu or input dialog. If the MDT's whole interface is its own NUI terminal, this is small. If it leans on framework menus, it is most of the job.
05 · Fix the job.grade shape
Code that treats job.grade as a number breaks on Qbox, where grade is a table carrying a level and a name. Authority checks that compare grade >= N need to read grade.level. This is the bug that lets a rookie see a supervisor screen — or locks the chief out — and it is invisible until the first shift.
06 · Re-verify the audit trail survives
Whatever the MDT wrote as history has to remain readable after the move. If report history lived in a JSON blob keyed on the old core's player object, confirm it still resolves. An append-only audit table keyed on citizen identifier and case id — the CaseLink design — is the shape that survives a framework change intact.
Dispatch → lookup → case → charges → evidence → close → audit.
The CaseLink state machine as designed, with the layer that owns each state. Design intent throughout — no runtime proof published — pending Shadow bench.
- 01Dispatch callA call is created server-side and projected to the live board. Designed to accept optional crime-economy sources (drug heat, gang territory) through documented export hooks that are inert when those resources are absent.owner · vf_mdt + oxmysql
- 02Citizen lookupThe terminal awaits an authority-gated server read. Identity resolves through ForgeCore's Qbox adapter, never from the client's own claim about who it is.owner · lib.callback → bridge
- 03Case openedA case row with a schema_version, a status from an owner-config enum, and a primary citizen. Cases are never hard-deleted — status only.owner · vf_mdt
- 04Charges filedCharges link citizen, case and a penal-code entry the department authored itself. No legal content ships in the resource; the config is open and escrow-exempt by design.owner · config/charges.lua
- 05Evidence attachedChainLock (vf_evidence) is designed to attach through a frozen AttachRecordToCase contract rather than by altering the case core — the suite extends through a join, not through schema edits.owner · frozen join
- 06BOLO / closeBOLOs issue and clear; a case closes with a closed_at timestamp. Every transition writes to an append-only audit table with no UPDATE or DELETE path anywhere in the codebase.owner · vf_mdt
- 07Audit readHistory is a query, not a memory. Designed so Watchtower Admin and the rest of the justice stack read the same audit surface the MDT wrote.owner · GetAuditByIdentifier
The Qbox justice stack, with real statuses.
ForgeCore
The free, fully open framework bridge every Vice Drip resource runs through — Qbox (native, on ox_lib), QBCore, and ESX Legacy resolved at start-up from one module. For owners who audit the layer under their economy before trusting it. No escrowed files. Staged; no runtime proof published — pending Shadow bench.
FREE
View docs →CaseLink MDT
One case record that dispatch, evidence, EMS, and K9 all write to — the suspect's history, the custody chain, and the medical report in one file. For law factions that lose the thread between scene and court. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore; escrow split publishes at release. In development; no runtime proof published — pending Shadow bench.
Planned · $44.99
Join preview →ChainLock Evidence
Chain of custody that survives the defense — every transfer appends a row that is never edited afterward, and every item chains into the CaseLink case. For owners whose court scenes collapse on a screenshot. Designed for Qbox, QBCore, and ESX Legacy through ForgeCore; escrow split publishes at release. In development; no runtime proof published — pending Shadow bench.
Planned · $29.99
Join preview →The criteria that decide an MDT on Qbox.
No vendor column and no scores. We have not audited anyone else's MDT, and on the runtime row we would fail our own criteria today. Take these nine questions to every option you shortlist, ours included.
| Criterion | Why it matters on Qbox | What to ask |
|---|---|---|
| Framework support | On Qbox, 'supported' often means a QBCore build with a shim. The difference shows up in job.grade handling and in the core export name. | Is Qbox a tested target or an inherited branch? Which qbx_core, ox_lib and oxmysql versions were tested, and when? |
| Authority model | An MDT is a database write endpoint every client can reach. If the client decides who is an officer, anyone is an officer. | Where is officer authority resolved — server-side from the job via the framework, or from a value the client sends? |
| Dependency chain | qbx_core already requires ox_lib and oxmysql. An MDT that adds a parallel DB layer or an undeclared non-ox companion will fail on first boot or duplicate what is running. | Read fxmanifest.lua: which resources are hard dependencies, which are optional, and what happens when an optional one is absent? |
| Record model | Reports that overwrite on edit are documents, not records. Court RP collapses when the history is whatever the last editor left. | Is history append-only? Can an admin silently edit or delete a report, and does the audit table have an UPDATE path? |
| Configuration surface | Charges, ranks, call types and terminal skin are department policy. If those ship escrowed, you adopt someone else's procedure. | Which files are escrow-exempt? Is the penal code a config file you author, or content baked into sealed logic? |
| Integration contract | 'Integrates with evidence' means nothing without the mechanism. A frozen join with a schema version is checkable; a promise is not. | Which table, which export, which event does the evidence or EMS system attach through? Is the case core versioned? |
| Escrow visibility | Cfx asset escrow seals files from reading and patching. On a framework chosen for auditability, a sealed MDT core is the part you can least afford not to see. | Ask for a file-level escrow manifest before purchase, not a summary after. |
| Runtime proof | An MDT with an open NUI is exactly the shape that idles expensively. A screenshot without a method is not a measurement. | What was measured, on what artifact, at what player count, on what date? Ours: no runtime proof published — pending Shadow bench. |
| Update history | Qbox and the ox resources move faster than older frameworks; an MDT that stops tracking them falls behind sooner. | Is there a dated, versioned changelog that records breaking changes against qbx_core or ox_lib releases? |
What to verify before buying a Qbox MDT script.
Six checks, useful even if you never buy from us. For platform facts — the resource manifest, asset escrow, server-side event handling — read the official Cfx documentation at docs.fivem.net rather than a seller's summary of it.
Open fxmanifest.lua and read the dependencies block before anything else.
A Qbox MDT should declare oxmysql and either qbx_core or a bridge that resolves it; lua54 should be on. Anything that names qb-core as a hard dependency is a QBCore build first. The manifest format and escrow behavior are documented by Cfx at docs.fivem.net — read the platform's own description rather than a store page's.
Grep the source you can see for exports['qb-core'] and job.grade.
The first tells you whether the resource actually targets qbx_core. The second tells you whether it expects a numeric grade (QBCore-era) or a grade table with .level (Qbox). Either one wrong is a shift-one bug.
Ask what happens to a report when it is edited.
If the answer is 'it changes', there is no audit trail. Ask specifically whether the audit table has any UPDATE or DELETE statement against it anywhere in the codebase — the honest answer is a grep, not an adjective.
Ask which side resolves officer authority.
The right answer names a server-side read of the framework job object through an export or bridge. A wrong answer involves the client sending its job with the request. Cfx's own guidance on server-side validation of network events is the standard to hold every MDT to.
Ask for the escrow manifest at file level.
Config, locales and the NUI should be open on any MDT you intend to fit to a real department. If charges or ranks are inside sealed files, procedure changes become tickets.
Ask for the runtime figure with its method — and accept 'pending' as an honest answer.
A number with an artifact version, a player count and a date is a measurement. Ours is not published yet: no runtime proof published — pending Shadow bench. Treat any MDT figure without a method the same way you would treat ours if we printed one.
Related reading: securing net events, asset escrow explained, and the Proof Center.
Qbox and the MDT, without the overclaim.
What is a Qbox MDT script?
A police MDT/CAD resource written for the Qbox framework — meaning it reads identity, job and grade from qbx_core, uses ox_lib for callbacks and menus, stores records through oxmysql, and uses ox_target rather than qb-target for any world interaction. The distinguishing test is whether it targets qbx_core natively or asks for qb-core through a compatibility shim.
Does CaseLink MDT require ox_lib on Qbox?
The design treats vf_core (ForgeCore) and oxmysql as the only hard dependencies; ox_lib is optional for context menus and progress, with a native fallback. On a Qbox server you already run ox_lib because qbx_core requires it, so in practice the question is moot — but the manifest is designed not to crash without it. That is design intent; no runtime proof is published yet.
What does the ForgeCore bridge do on Qbox?
It detects qbx_core at boot (or takes a forced Config.Framework setting), loads a Qbox adapter that is the only file permitted to call qbx_core exports, and normalizes the Qbox player object — including the job.grade table — into one bridge contract. CaseLink reads officer job and grade through that contract, so a change in qbx_core's shapes is a one-file fix in an open, free resource.
Can I move an existing MDT from QBCore to Qbox?
Usually, and the citizenid-keyed data is the part that travels best because Qbox keeps the citizenid. The work is in the code: replacing the qb-core export, moving callbacks to lib.callback, swapping qb-target for ox_target and qb-menu for ox_lib, and fixing any code that reads job.grade as a number. If the MDT is escrowed, you cannot make those changes yourself — which is the strongest argument for checking the escrow manifest first.
Are MDT records on Qbox keyed on citizenid?
On QBCore and Qbox, citizenid is the durable per-character key most resources write rows against, which is why data moves cleanly between the two. CaseLink's citizen records are designed to be keyed on a server-resolved framework identifier rather than anything the client supplies, with cases carrying their own server-generated id and a schema version.
Can I buy CaseLink MDT for Qbox today?
No. CaseLink is in development; there is no checkout path anywhere on this site and the Planned · $44.99 figure is a target pending the studio pricing lock, not a commitment. Runtime status is exactly this: no runtime proof published — pending Shadow bench. The preview page takes a launch-signal email and nothing else. Verified 2026-09-02.
Where should I read platform facts rather than vendor claims?
Cfx documents the resource manifest, asset escrow and server-side event handling at docs.fivem.net; Qbox documents qbx_core's exports and its permission direction in its own docs. Cross-check every technical claim on this page — ours included — against those before you rely on it.
Last verified: 2026-09-02 · no runtime proof published — pending Shadow bench · No purchase path
Hear when CaseLink lands on Qbox.
One email when it ships, with the measured numbers, the tested qbx_core and ox_lib versions, and the escrow manifest attached. No drip campaign, no date we cannot keep.
Write to support@vicedrip.com with “Launch signal” in the subject. We reply once to confirm before adding you, then send one email at launch plus occasional release notes. Reply “unsubscribe” any time. How we handle your data.