Intégrations
Frameworks, emotes, médical, inventaire, notifications, saisies, météo, clés, factures, réparation et apparence — valeurs acceptées par chaque sélecteur et comportement exact des presets du bridge.
But : brancher ox_target sur vos scripts existants.
Fichiers : config.lua (sélecteurs Config.*Script), puis si besoin config_client.lua et config_server.lua (hooks).
Comment le bridge choisit
Pour chaque fonction (Bridge.Notify, Bridge.PlayEmote, Bridge.RevivePlayer…), le bridge applique cet ordre :
- Hook : si
Config.ClientHooks.<Nom>(ouConfig.ServerHooks.<Nom>côté serveur) est une fonction, elle est appelée et remplace entièrement le preset. - Preset : sinon, la valeur du sélecteur décide.
Les valeurs possibles se répartissent en quatre modes :
- Détection (
'auto') : le bridge prend la première ressource de sa liste qui est démarrée (startedoustarting) au moment de l’appel ; à défaut, un repli fixe (souventnative,commandou aucune intégration). - Ressource nommée (
'esx_ambulancejob','av_weather'…) : le preset correspondant est utilisé. Selon le preset, l’état de la ressource est vérifié ou non : voir chaque tableau. 'command'et'native': commandes deConfig.Commands, ou natives GTA sans script externe.'custom': aucun preset ; seuls vos hooks agissent. Certains sélecteurs acceptent aussifalsepour désactiver l’intégration.
Framework
| Valeurs | Comportement |
|---|---|
'auto' Défaut | Premier démarré parmi es_extended, qbx_core, qb-core, ox_core, ND_Core ; sinon standalone. Ordre de détection : es_extended → qbx_core → qb-core → ox_core → ND_Core → standalone |
'esx' | Métier via ESX (PlayerData.job / xPlayer.job), groupe staff via xPlayer.getGroup() comparé exactement au nom du groupe. |
'qb' | Métier via QBCore PlayerData.job ; groupe staff via QBCore.Functions.HasPermission puis ACE group.<nom>. |
'qbx' | Métier via exports.qbx_core GetPlayerData / GetPlayer ; groupe staff via ACE group.<nom>. |
'ox' | Le bridge ne lit pas le métier ni l’inventaire framework : prévoyez les hooks GetPlayerJob et HasItem. Aucune lecture de métier dans le bridge ; groupe staff via ACE group.<nom>. |
'nd' | Le bridge ne lit pas le métier ni l’inventaire framework : prévoyez les hooks GetPlayerJob et HasItem. Aucune lecture de métier dans le bridge ; groupe staff via ACE group.<nom>. |
'standalone' | Aucun métier ; groupe staff via ACE group.<nom>. |
Hooks qui remplacent ce preset : Config.ClientHooks.GetPlayerJob Config.ClientHooks.HasItem Config.ServerHooks.GetPlayerJob Config.ServerHooks.HasGroup Config.ServerHooks.HasItem Config.ServerHooks.RemoveItem
Config.Framework ne concerne que le bridge. Le filtre natif groups des options utilise un module séparé (client/framework) qui détecte lui-même ox_core, es_extended, qb-core, qbx_core puis ND_Core au démarrage de la ressource.
Le framework sert au bridge pour lire le métier (GetPlayerJob), les groupes staff (HasGroup) et l’inventaire framework. Avec ox, nd ou standalone, le bridge ne lit aucun métier : définissez GetPlayerJob côté client et serveur si vous utilisez des filtres jobs.
Emotes
| Valeurs | Comportement |
|---|---|
'auto' Défaut | rpemotes-reborn puis rpemotes ; sinon mode command. Ordre de détection : rpemotes-reborn → rpemotes → command |
'rpemotes-reborn' | Emote perso : export EmoteCommandStart si la ressource est démarrée, sinon commande. Emote partagée : toujours Config.Commands.sharedEmote. Copie : export IsPlayerInAnim, exploité seulement s’il renvoie un nom. |
'rpemotes' | Même comportement que rpemotes-reborn avec la ressource rpemotes. |
'command' | Exécute Config.Commands.emote / sharedEmote / cancelEmote. ExecuteCommand avec Config.Commands. La copie d’emote ne trouve aucun nom sans hook GetCurrentEmote. |
'custom' | Le bridge ne joue rien : définissez les hooks PlayEmote, PlaySharedEmote, GetCurrentEmote. |
Hooks qui remplacent ce preset : Config.ClientHooks.PlayEmote Config.ClientHooks.PlaySharedEmote Config.ClientHooks.GetCurrentEmote Config.ClientHooks.CancelEmote Config.ClientHooks.Me
/me (Bridge.Me) et l’annulation d’emote utilisent toujours Config.Commands.me et cancelEmote, quel que soit le preset, sauf hook Me ou CancelEmote.
La copie d’emote demande au joueur ciblé son emote en cours via Bridge.GetCurrentEmote ; seul un nom (chaîne non vide) est exploitable. Selon la version de rpemotes, l’export IsPlayerInAnim peut renvoyer un booléen : la copie répond alors « Le joueur ne fait aucune emote à copier. » Définissez le hook GetCurrentEmote si votre script expose le nom autrement.
Médical
| Valeurs | Comportement |
|---|---|
'auto' Défaut | esx_ambulancejob puis qb-ambulancejob ; sinon mode native. Ordre de détection : esx_ambulancejob → qb-ambulancejob → native |
'esx_ambulancejob' | Événements esx_ambulancejob:revive et esx_ambulancejob:heal ('big', true). |
'qb-ambulancejob' | Événements hospital:client:Revive et hospital:client:HealInjuries ('full'). |
'command' | Commandes Config.Commands.reviveSelf/healSelf (client) et revivePlayer/healPlayer (console serveur). Commandes de Config.Commands ; côté serveur via ExecuteCommand dans la console. |
'native' | Résurrection et soin par natives GTA, sans script médical. Routines client NativeRevive / NativeHeal. |
'custom' | Aucun preset : définissez les hooks RevivePlayer/HealPlayer (serveur) et ReviveSelf/HealSelf (client). |
Hooks qui remplacent ce preset : Config.ClientHooks.ReviveSelf Config.ClientHooks.HealSelf Config.ServerHooks.RevivePlayer Config.ServerHooks.HealPlayer
Avec Config.Medical.nativeHealFallback = true, un heal natif est appliqué après chaque heal, y compris quand un hook est défini.
Config.Medical.selfMode décide où s’exécute le revive/heal sur soi : 'client' appelle Bridge.ReviveSelf / HealSelf après validation serveur ; 'server' appelle Bridge.RevivePlayer(source, source) / HealPlayer. Le message de réussite (self_revived, self_healed) est envoyé par le serveur dans les deux cas, sans attendre le résultat du script médical.
Inventaire
| Valeurs | Comportement |
|---|---|
'auto' Défaut | ox_inventory si démarré ; sinon inventaire du framework. Ordre de détection : ox_inventory → framework |
'ox_inventory' | exports.ox_inventory:Search('count', item) et RemoveItem côté serveur. |
'framework' | Inventaire ESX ou QBCore/Qbox via le framework résolu. ESX : getInventoryItem / removeInventoryItem. QBCore/Qbox : Functions.GetItemByName / RemoveItem. Rien pour ox, nd et standalone. |
'custom' | Hooks HasItem / RemoveItem. Sans hook, le client affiche l’option et le serveur lit l’inventaire du framework. |
Hooks qui remplacent ce preset : Config.ClientHooks.HasItem Config.ServerHooks.HasItem Config.ServerHooks.RemoveItem
Côté client, la vérification d’item ne sert qu’à afficher ou masquer une option ; le serveur revérifie avant l’action. Le filtre natif items des options passe par un autre mécanisme (module d’origine d’ox_target) qui lit ox_inventory s’il est présent, sinon l’inventaire du framework détecté.
Notifications
| Valeurs | Comportement |
|---|---|
'ox_lib' Défaut | |
'esx' | ESX.ShowNotification si l’objet ESX est disponible, sinon ox_lib. |
'qb' | QBCore.Functions.Notify si QBCore est disponible, sinon ox_lib. |
'dNotif' | exports.dNotif:SendBasicNotif avec Config.DNotifColors si dNotif est démarré, sinon ox_lib. |
'chat' | Message chat:addMessage avec le préfixe « Target ». |
'custom' | Rien n’est affiché sans hook Notify. |
Hooks qui remplacent ce preset : Config.ClientHooks.Notify Config.ServerHooks.Notify
Côté serveur, Bridge.Notify envoie un événement au client, qui applique ensuite ce choix.
Les types internes sont info, success, error, warning et primary. ox_lib reçoit inform pour info et primary ; QBCore reçoit primary, success ou error (warning devient error). Config.DNotifColors associe une couleur dNotif à chaque type.
Saisies et confirmations
| Valeurs | Comportement |
|---|---|
'ox_lib' Défaut | |
'dNotif' | Saisie de texte et confirmation via dNotif si démarré. Les formulaires multi-champs (facture) restent ox_lib. |
'custom' | Sans hook TextInput / Confirm / InputDialog, le bridge utilise ox_lib. |
Hooks qui remplacent ce preset : Config.ClientHooks.TextInput Config.ClientHooks.InputDialog Config.ClientHooks.Confirm Config.ClientHooks.ProgressBar Config.ClientHooks.ShowTextUI Config.ClientHooks.HideTextUI
Avec dNotif, la confirmation n’affiche que le texte : le titre n’est pas transmis.
Bridge.ProgressBar, ShowTextUI et HideTextUI utilisent toujours ox_lib sauf hook.
Météo
| Valeurs | Comportement |
|---|---|
'auto' Défaut | av_weather si démarré ; sinon aucune intégration. Ordre de détection : av_weather → false |
'av_weather' | Exports av_weather updateZone, updateTime, setBlackout, getBlackout, generateWeathers, getTime, getZone, setRain et événement av_weather:freeze. |
'custom' | Hooks serveur SetWeather, SetTime… et hooks client SetLocalRain / SetLocalFreeze. |
false |
Hooks qui remplacent ce 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
Le menu météo n’est visible côté client que si av_weather est résolu et démarré, ou si un hook client SetLocalRain ou SetLocalFreeze existe. Les hooks serveur seuls ne suffisent pas à l’afficher.
Avec av_weather, les zones et valeurs envoyées sont celles de Config.Weather. Vérifiez qu’elles existent dans votre configuration av_weather (santos, sandy, paleto, cayo et les types CLEAR, RAIN… par défaut).
Clés de véhicule
| Valeurs | Comportement |
|---|---|
'auto' Défaut | qs-vehiclekeys si démarré. Ordre de détection : qs-vehiclekeys → false |
'qs-vehiclekeys' | exports['qs-vehiclekeys']:GiveKeys(plaque, modèle, true). |
'custom' | Nécessite le hook client GiveVehicleKeys. |
false |
Hooks qui remplacent ce preset : Config.ClientHooks.GiveVehicleKeys
Facturation
| Valeurs | Comportement |
|---|---|
'auto' Défaut | esx_billing si démarré. Ordre de détection : esx_billing → false |
'esx_billing' | TriggerServerEvent('esx_billing:sendBill', id, Config.Billing.societyPrefix .. métier, motif, montant). |
'custom' | Nécessite le hook client SendBill. |
false |
Hooks qui remplacent ce preset : Config.ClientHooks.SendBill
La facture n’est pas une action serveur du moteur : sa validation repose sur le script de facturation destinataire.
L’option est masquée pour les métiers de Config.Billing.excludedJobs et pour un joueur sans métier. Le montant est arrondi à l’entier inférieur.
Réparation
| Valeurs | Comportement |
|---|---|
'auto' Défaut | jg-mechanic si démarré ; sinon mode native. Ordre de détection : jg-mechanic → native |
'jg-mechanic' | TriggerEvent('jg-mechanic:client:repair-vehicle'). Choisi explicitement, ce preset ne vérifie pas que jg-mechanic est démarré. |
'native' | Barre de progression puis réparation par natives. Durée et animation de Config.Vehicles.repair, puis SetVehicleFixed et santé moteur/carrosserie à 1000. |
'custom' | Nécessite le hook client RepairVehicle. |
Hooks qui remplacent ce preset : Config.ClientHooks.RepairVehicle
Apparence
| Valeurs | Comportement |
|---|---|
'auto' Défaut | illenium-appearance si démarré. Ordre de détection : illenium-appearance → false |
'illenium-appearance' | Callback illenium-appearance:server:getAppearance puis export setPlayerAppearance. |
'custom' | Nécessite le hook client RestoreAppearance. |
false |
Hooks qui remplacent ce preset : Config.ClientHooks.RestoreAppearance
« Prendre apparence » (dev_clone_ped) n’utilise pas ce sélecteur : il applique directement le modèle du PNJ avec SetPlayerModel.
Exemple : passer une intégration en hook
Votre script de clés n’est pas qs-vehiclekeys. Réglez Config.KeysScript = 'custom' puis, dans config_client.lua :
Config.ClientHooks.GiveVehicleKeys = function(vehicle, plate, model)
TriggerEvent('mes_cles:donner', plate)
endmes_cles:donner est un nom d’exemple. Le hook rend aussi l’option « Se donner les clés » disponible : sans lui, avec 'custom', elle reste masquée.
Erreurs fréquentes
NotifyScript = 'custom'sans hookNotify: plus aucune notification.WeatherScript = 'custom'avec uniquement des hooks serveur : le menu météo reste invisible côté client. Ajoutez aussiSetLocalRainouSetLocalFreezedansconfig_client.lua(comportement observé dansbridge/client.lua).MedicalScript = 'auto'sans script médical : repli surnative; le revive fonctionne mais sans la logique de votre script (factures d’hôpital, états…).RepairScript = 'jg-mechanic'sans la ressource : l’événement part dans le vide et le joueur voit quand même « Véhicule réparé ».