MrPoulpi Labs
ox_target

Available scripts

FR
Documentation centre

Integrations

Frameworks, emotes, medical, inventory, notifications, inputs, weather, keys, invoices, repair and appearance — values accepted by each selector and the exact behaviour of the bridge presets.

Goal: connect ox_target to your existing scripts. Files: config.lua (Config.*Script selectors), then if needed config_client.lua and config_server.lua (hooks).

How the bridge decides

For every function (Bridge.Notify, Bridge.PlayEmote, Bridge.RevivePlayer…), the bridge applies this order:

  1. Hook: if Config.ClientHooks.<Name> (or Config.ServerHooks.<Name> server side) is a function, it is called and fully replaces the preset.
  2. Preset: otherwise, the selector value decides.

Possible values fall into four modes:

  • Detection ('auto'): the bridge takes the first resource of its list that is started (started or starting) at call time; failing that, a fixed fallback (often native, command or no integration).
  • Named resource ('esx_ambulancejob', 'av_weather'…): the matching preset is used. Depending on the preset, the resource state is checked or not: see each table.
  • 'command' and 'native': commands from Config.Commands, or GTA natives without an external script.
  • 'custom': no preset; only your hooks act. Some selectors also accept false to disable the integration.

Framework

Values Behaviour
'auto' Default First started among es_extended, qbx_core, qb-core, ox_core, ND_Core; otherwise standalone.
Detection order: es_extended → qbx_core → qb-core → ox_core → ND_Core → standalone
'esx'
Job via ESX (PlayerData.job / xPlayer.job), staff group via xPlayer.getGroup() compared exactly to the group name.
'qb'
Job via QBCore PlayerData.job; staff group via QBCore.Functions.HasPermission then ACE group.<name>.
'qbx'
Job via exports.qbx_core GetPlayerData / GetPlayer; staff group via ACE group.<name>.
'ox' The bridge does not read the job or framework inventory: provide GetPlayerJob and HasItem hooks.
No job lookup in the bridge; staff group via ACE group.<name>.
'nd' The bridge does not read the job or framework inventory: provide GetPlayerJob and HasItem hooks.
No job lookup in the bridge; staff group via ACE group.<name>.
'standalone'
No job; staff group via ACE group.<name>.

Hooks that replace this preset: Config.ClientHooks.GetPlayerJob Config.ClientHooks.HasItem Config.ServerHooks.GetPlayerJob Config.ServerHooks.HasGroup Config.ServerHooks.HasItem Config.ServerHooks.RemoveItem

Config.Framework only affects the bridge. The native groups filter uses a separate module (client/framework) that detects ox_core, es_extended, qb-core, qbx_core then ND_Core when the resource starts.

The bridge uses the framework to read the job (GetPlayerJob), the staff groups (HasGroup) and the framework inventory. With ox, nd or standalone, the bridge reads no job: define GetPlayerJob client and server side if you use jobs filters.

Emotes

Values Behaviour
'auto' Default rpemotes-reborn then rpemotes; otherwise command mode.
Detection order: rpemotes-reborn → rpemotes → command
'rpemotes-reborn'
Personal emote: EmoteCommandStart export if the resource is started, otherwise the command. Shared emote: always Config.Commands.sharedEmote. Copy: IsPlayerInAnim export, used only when it returns a name.
'rpemotes'
Same behaviour as rpemotes-reborn with the rpemotes resource.
'command' Runs Config.Commands.emote / sharedEmote / cancelEmote.
ExecuteCommand with Config.Commands. Emote copy finds no name without a GetCurrentEmote hook.
'custom' The bridge plays nothing: define the PlayEmote, PlaySharedEmote, GetCurrentEmote hooks.

Hooks that replace this preset: Config.ClientHooks.PlayEmote Config.ClientHooks.PlaySharedEmote Config.ClientHooks.GetCurrentEmote Config.ClientHooks.CancelEmote Config.ClientHooks.Me

/me (Bridge.Me) and emote cancel always use Config.Commands.me and cancelEmote whatever the preset, unless a Me or CancelEmote hook exists.

Emote copy asks the targeted player for the current emote through Bridge.GetCurrentEmote; only a name (non-empty string) is usable. Depending on the rpemotes version, the IsPlayerInAnim export may return a boolean: the copy then answers with copy_emote_none. Define the GetCurrentEmote hook if your script exposes the name differently.

Medical

Values Behaviour
'auto' Default esx_ambulancejob then qb-ambulancejob; otherwise native mode.
Detection order: esx_ambulancejob → qb-ambulancejob → native
'esx_ambulancejob'
esx_ambulancejob:revive and esx_ambulancejob:heal ('big', true) events.
'qb-ambulancejob'
hospital:client:Revive and hospital:client:HealInjuries ('full') events.
'command' Config.Commands.reviveSelf/healSelf (client) and revivePlayer/healPlayer (server console) commands.
Config.Commands commands; server side through ExecuteCommand in the console.
'native' Resurrection and heal through GTA natives, without a medical script.
NativeRevive / NativeHeal client routines.
'custom' No preset: define RevivePlayer/HealPlayer (server) and ReviveSelf/HealSelf (client) hooks.

Hooks that replace this preset: Config.ClientHooks.ReviveSelf Config.ClientHooks.HealSelf Config.ServerHooks.RevivePlayer Config.ServerHooks.HealPlayer

With Config.Medical.nativeHealFallback = true, a native heal runs after every heal, including when a hook is defined.

Config.Medical.selfMode decides where self revive/heal runs: 'client' calls Bridge.ReviveSelf / HealSelf after server validation; 'server' calls Bridge.RevivePlayer(source, source) / HealPlayer. The success message (self_revived, self_healed) is sent by the server in both cases, without waiting for the medical script’s result.

Inventory

Values Behaviour
'auto' Default ox_inventory when started; otherwise the framework inventory.
Detection order: ox_inventory → framework
'ox_inventory'
exports.ox_inventory:Search('count', item) and RemoveItem server side.
'framework' ESX or QBCore/Qbox inventory through the resolved framework.
ESX: getInventoryItem / removeInventoryItem. QBCore/Qbox: Functions.GetItemByName / RemoveItem. Nothing for ox, nd and standalone.
'custom' HasItem / RemoveItem hooks. Without hooks the client shows the option and the server reads the framework inventory.

Hooks that replace this preset: Config.ClientHooks.HasItem Config.ServerHooks.HasItem Config.ServerHooks.RemoveItem

Client side, the item check only shows or hides an option; the server checks again before the action. The native items filter of options uses another mechanism (original ox_target module) that reads ox_inventory when present, otherwise the detected framework inventory.

Notifications

Values Behaviour
'ox_lib' Default
'esx' ESX.ShowNotification when the ESX object is available, otherwise ox_lib.
'qb' QBCore.Functions.Notify when QBCore is available, otherwise ox_lib.
'dNotif' exports.dNotif:SendBasicNotif with Config.DNotifColors when dNotif is started, otherwise ox_lib.
'chat' chat:addMessage message prefixed with “Target”.
'custom' Nothing is shown without a Notify hook.

Hooks that replace this preset: Config.ClientHooks.Notify Config.ServerHooks.Notify

Server side, Bridge.Notify sends an event to the client, which then applies this choice.

Internal types are info, success, error, warning and primary. ox_lib receives inform for info and primary; QBCore receives primary, success or error (warning becomes error). Config.DNotifColors maps a dNotif colour to each type.

Inputs and confirmations

Values Behaviour
'ox_lib' Default
'dNotif' Text input and confirmation via dNotif when started. Multi-field forms (invoice) stay on ox_lib.
'custom' Without TextInput / Confirm / InputDialog hooks the bridge uses ox_lib.

Hooks that replace this preset: Config.ClientHooks.TextInput Config.ClientHooks.InputDialog Config.ClientHooks.Confirm Config.ClientHooks.ProgressBar Config.ClientHooks.ShowTextUI Config.ClientHooks.HideTextUI

With dNotif, the confirmation only shows the text: the title is not passed.

Bridge.ProgressBar, ShowTextUI and HideTextUI always use ox_lib unless hooked.

Weather

Values Behaviour
'auto' Default av_weather when started; otherwise no integration.
Detection order: av_weather → false
'av_weather'
av_weather exports updateZone, updateTime, setBlackout, getBlackout, generateWeathers, getTime, getZone, setRain and the av_weather:freeze event.
'custom' Server hooks SetWeather, SetTime… and client hooks SetLocalRain / SetLocalFreeze.
false

Hooks that replace this preset: Config.ClientHooks.SetLocalRain Config.ClientHooks.SetLocalFreeze Config.ServerHooks.SetWeather Config.ServerHooks.SetTime Config.ServerHooks.FreezeTime Config.ServerHooks.SetBlackout Config.ServerHooks.GetBlackout Config.ServerHooks.GenerateWeathers Config.ServerHooks.GetTime Config.ServerHooks.GetZoneInfo

The weather menu is only visible client side when av_weather is resolved and started, or when a SetLocalRain or SetLocalFreeze client hook exists. Server hooks alone do not make it appear.

With av_weather, the zones and values sent are those of Config.Weather. Check that they exist in your av_weather configuration (santos, sandy, paleto, cayo and the CLEAR, RAIN… types by default).

Vehicle keys

Values Behaviour
'auto' Default qs-vehiclekeys when started.
Detection order: qs-vehiclekeys → false
'qs-vehiclekeys'
exports['qs-vehiclekeys']:GiveKeys(plate, model, true).
'custom' Requires the GiveVehicleKeys client hook.
false

Hooks that replace this preset: Config.ClientHooks.GiveVehicleKeys

Billing

Values Behaviour
'auto' Default esx_billing when started.
Detection order: esx_billing → false
'esx_billing'
TriggerServerEvent('esx_billing:sendBill', id, Config.Billing.societyPrefix .. job, reason, amount).
'custom' Requires the SendBill client hook.
false

Hooks that replace this preset: Config.ClientHooks.SendBill

Invoicing is not an engine server action: its validation relies on the receiving billing script.

The option is hidden for jobs in Config.Billing.excludedJobs and for a player without a job. The amount is rounded down to an integer.

Repair

Values Behaviour
'auto' Default jg-mechanic when started; otherwise native mode.
Detection order: jg-mechanic → native
'jg-mechanic'
TriggerEvent('jg-mechanic:client:repair-vehicle'). When chosen explicitly, this preset does not check that jg-mechanic is started.
'native' Progress bar then repair through natives.
Duration and animation from Config.Vehicles.repair, then SetVehicleFixed and engine/body health at 1000.
'custom' Requires the RepairVehicle client hook.

Hooks that replace this preset: Config.ClientHooks.RepairVehicle

Appearance

Values Behaviour
'auto' Default illenium-appearance when started.
Detection order: illenium-appearance → false
'illenium-appearance'
illenium-appearance:server:getAppearance callback then setPlayerAppearance export.
'custom' Requires the RestoreAppearance client hook.
false

Hooks that replace this preset: Config.ClientHooks.RestoreAppearance

“Take appearance” (dev_clone_ped) does not use this selector: it applies the ped model directly with SetPlayerModel.

Example: moving an integration to a hook

Your keys script is not qs-vehiclekeys. Set Config.KeysScript = 'custom', then in config_client.lua:

Config.ClientHooks.GiveVehicleKeys = function(vehicle, plate, model)
    TriggerEvent('my_keys:give', plate)
end

my_keys:give is an example name. The hook also makes the “give keys” option available: without it, with 'custom', the option stays hidden.

Common mistakes

  • NotifyScript = 'custom' without a Notify hook: no notification at all.
  • WeatherScript = 'custom' with server hooks only: the weather menu stays invisible client side. Also add SetLocalRain or SetLocalFreeze in config_client.lua (behaviour observed in bridge/client.lua).
  • MedicalScript = 'auto' without a medical script: fallback to native; revive works but without your script’s logic (hospital bills, states…).
  • RepairScript = 'jg-mechanic' without the resource: the event goes nowhere and the player still sees repair_done.

Search

Type a term: setting, export, error…