Game integrationGame

SuperMDT works perfectly well on its own, as a web intranet. The game integration also connects it to your FiveM server: characters become citizen records, going on duty in game shows up in the MDT, officers open the MDT on an in-game tablet, and the live map shows who is patrolling where.

The link goes through a FiveM resource, supermdt-bridge (“the bridge”), that you install on your server. It reads the game state from your framework and sends it to SuperMDT. SuperMDT never connects to your game server’s database.

Screenshot coming soongame-settings

Settings › Game: the switch, the bridge status, the key, jobs and integrations

The switch

Everything starts with the Turn on game integration switch, at the top of Settings › Game. Only organization administrators can use it.

• Off (the setting for a new organization): SuperMDT behaves like a web intranet. The bridge is refused if it tries to connect, and players, the tablet, the live map, duty from the game, linking by code and character choice are hidden.
• On: your game server can connect with the bridge key, and your members link their game account, then sign in with their characters.

Turning the integration off deletes nothing: players, characters, settings and key stay in place, and everything comes back when you turn it on again. The change is written to the audit log.

Settings changes reach the game within a few seconds: linked jobs, services, plate reader, alerts, panic, quick dispatch, billing… Players already in game see them without reconnecting. Only turning the integration back on can take up to 30 seconds.

What depends on it

Feature	Without the integration	With the integration
Citizen records	entered by hand	every game character becomes a record, with the Game badge; identity is read-only
Duty	from the MDT	synced with the game, both ways (Duty and positions)
Displayed name	the account name	the roleplay name of the chosen character (Accounts and characters)
In-game tablet	—	the MDT in game, F6 key (F4 on ESX) (In-game tablet)
Live map	—	positions of on-duty officers
In-game photos, quick dispatch	—	tablet options
Panic button	from the MDT	also from the tablet, the /panique command or a key, with the character’s position
Game alerts	—	shots fired, robberies, vehicle thefts, 911 calls: a call at dispatch, merged and capped
Electronic tags	—	a tagged person followed on the live map, zone and disconnection alerts
Weapons, vehicles, transfers, licenses, fines, plate reader, properties, phone number	—	optional integrations, one by one (see below)

Supported frameworks

The bridge works with three frameworks, and only these:

• ESX Legacy;
• QBCore;
• Qbox (qbx_core).

It detects them on its own at startup. On any other framework (ox_core, vRP, ND…), it writes the reason in the server console and stays inactive: nothing is sent.

A heavily modified framework

The bridge reads data where the framework stores it out of the box (job, grade, duty state, character identity). If your server rewrote these parts, reading may be incomplete. supermdt status, in the server console, tells you what the bridge found (see Install the bridge).

Accounts, players and characters

Three levels, not to be confused:

• the MDT member: the person who signs in to the website with Discord, a member of your organization;
• the player: the same person as seen by the game, recognized by their Rockstar license (with their Discord and FiveM IDs);
• the characters: the ones this player plays on your server. Each one is a citizen record.

MDT member (Discord account)
   │  linked through Discord (automatic), with a /mdtlink code, or by an administrator
   ▼  1 member → 5 players at most
Player (Rockstar license, Discord, FiveM)
   │
   ▼  1 player → several characters
Characters = citizen records (“Game” badge)
   │  the character's in-game job (police, ambulance…)
   ▼
A service of your organization (Settings › Game › Jobs and services)

A member is linked to players, never directly to characters: their characters are those of their players. A character counts for a member when its in-game job is linked to a service the member is assigned to (an administrator sees all of them).

The roleplay name

When you sign in to the MDT, you choose which character you play (nothing to choose if you only have one). This active character sets:

• the name displayed everywhere in the MDT: reports, log, dispatch, map;
• the current service: the one of the character’s job;
• the callsign: the one of your assignment in that service.

Without a character (integration off, no linked player), it’s your account name, as without the game. Full details: Accounts and characters.

Optional integrations

On top of the base (players, characters, duty, positions, tablet), nine integrations are turned on one by one in Settings › Game › Integrations. They are all off by default, and each depends on the scripts installed on your server:

Integration	What it does	Page
Automatic weapon registry	one record per weapon bought or given in game, with its serial number	Weapons
Owned vehicles	characters’ vehicles arrive in the vehicle file	Vehicles
Salary transfers	approved payslips are paid in game	Salary transfers
Character licenses	read, revoke and give back licenses from the citizen record	Licenses
Fine collection	a file’s fine is invoiced or debited in game	Fines
Care billing	care from a medical visit is invoiced or debited in game, with the same modes as fines (set on the medical service)	Fines and care
In-game printing	an exported document becomes a sheet in the inventory, to read, show or give (set per service, Documents module)	In-game printing
In-game plate reader	plates read by Wraith ARS 2X or the built-in reader are checked against the MDT, in-game alert	Plate reader
Character properties	characters’ homes, read only, on the citizen record	Properties

The phone number on citizen records has no switch: the bridge reads it from the in-game phone when it recognizes it (Phone number).

Alerts and your dispatch script

Game alerts have no switch here either: SuperMDT works with your dispatch script, without replacing it. The bridge listens to ps-dispatch Tested in game, cd_dispatch, qs-dispatch or rcore_dispatch Experimental (core_dispatch is not supported: use the Alert export); the alert’s in-game title becomes the call’s nature. Without a dispatch script, its built-in detections report shots fired, people down and vehicle thefts; with a script, they turn themselves off to avoid duplicates. On top of that come the framework’s police and EMS alert, robberies, /911p and /911e, 911 calls from phones and the Alert export.

The Alerts and dispatch row in Settings › Game › Integrations shows what the bridge listens to on your server (dispatch script, phones, detections’ state, support level) and leads to Set up game alerts: each service chooses the alerts it receives in Settings › Operations › Game alerts.

Under each switch, SuperMDT shows what the bridge detected on your server (“Uses ox_inventory”, “Detected but not supported yet: …”) and warns you if you turn on an integration with no compatible resource.

Three support levels

Every third-party script carries a badge, in the compatibility tables, in Settings › Game and in supermdt status:

• Tested in game: tried in game, on a real server;
• Verified in code: written from the script’s source code or native API and covered by the bridge’s tests, but not tried in game yet;
• Experimental: written from the publisher’s public documentation (paid or encrypted script), never tried.

Until a script is Tested in game, check it on your server before relying on it.

Where to start

1. Install the bridge and link your jobs to your services: the Connect your game server assistant of getting started guides you up to the first player on duty.
2. Ask your members to link their game account.
3. Show them the in-game tablet.
4. Then turn on the integrations you need, one by one.