Framework & Bridges

Every third-party system the script talks to sits behind a small open adapter in bridge/. You pick your systems with the Config.*System selectors in config.lua.

#The four values every selector accepts

#Core

The character selector is only used for three things: sending a player back to the selector after a face implant (off by default), hiding our HUD while the selector is open, and the install notes. Every surveyed selector logs characters in through the framework, so framework events cover them all.

#Appearance and tattoos

Clothing itself is read from GTA natives and works with any appearance script or none. The appearance selector is only used for the face editor the implant clinic opens and for "outfit changed" hints.

natives works on every server for tattoos. If your tattoo script is in the list (illenium-appearance, rcore_tattoos), you can pick it instead.

#Voice

Auto order: pma-voice → saltychat → yaca-voice → tokovoip_script → native.

Only pma-voice supports the audible voice changer. On every other system the changer still fools the scan and still links crimes to the same device — people nearby just hear the wearer's normal voice. Details: Voice & Voice Changer.

#Interaction and feedback

The progress bar is used for surgery, printing and device setup. It is never used for the scan itself — the scan has its own HUD.

The target selector is only used when Config.StartMode = 'target', and for the clinic NPC.

#Death, police, MDT, evidence

native on the death selector means our own detection plus the movement rule — it always runs underneath whichever script is selected. The police selector never blocks anything; it only tells the proof log who cuffed, robbed, searched or escorted whom.

#Capture and HUD

'auto' on screenshots tries builtin first (needs nothing), then screencapture, then screenshot-basic.

Config.NametagSystem defaults to 'none': hiding a masked player's floating name is opt-in, because it changes how your whole server reads at a glance.

#The boot summary

After boot the server prints what every server-side bridge resolved to:

[5code-recognition] Integrations: framework=qbx inventory=ox_inventory voice=pma-voice appearance=illenium-appearance tattoos=illenium-appearance death=qbx_medical police=qbx_police mdt=none evidence=none target=none textui=native hud=jg-hud screenshot=builtin

That line is the first thing to read when an integration "does not work". If a system shows as none and you expected it, either the resource is not started, or it is started after us and did not re-resolve, or you pinned a name that does not match the folder.

With Config.Debug = true the summary adds a second line with the two job whitelists, because a mistyped job name is otherwise invisible:

[5code-recognition] Jobs: police={police} (duty required) hint={police} (duty not required) acceptTypes={leo}

recognition:selftest also names any job in those lists that your framework does not have (see Police jobs).

Client bridges print the selector they resolved to F8 only when Config.Debug = true. They print the "…but <x> is not started" warning to F8 whatever Config.Debug is set to — see Troubleshooting. Each player's voice provider is reported to the server and shown in recognition:status.

#Standalone

With no framework at all, every bridge falls back to a native or standalone branch and the whole loop still works. One setting decides what a "character" is:

ServerConfig.Standalone = {
    CharacterKey = 'license',   -- 'license' | 'license2' | 'fivem' | 'custom'
}

'custom' calls Hooks.GetCustomCharacterId in bridge/hooks.lua. There is one character per key, so a standalone server has one character per player.

Jobs work the same way: without a framework nobody is police unless you wire Hooks.GetCustomJob.

#Adding a system that is not listed

Set the selector to 'custom' and fill the 'custom' branch in the matching bridge/*.lua file. The core only ever calls the small set of functions that branch defines, so you never need access to the protected code.

Full walkthrough with the function list per bridge: Writing a Custom Adapter.