Chaque script embarque la même couche de bridges. Elle détecte ce qui tourne sur votre serveur, choisit une cible, et vous dit laquelle. Rien à installer, rien à patcher, et les fichiers qui font le travail sont lisibles.
ESX, QBCore et vRP ont une branche dédiée, testée sur les vrais exports. Le mode standalone ne demande aucun framework, et custom est une branche vide que vous remplissez vous-même. Qbox et ox_core passent par le chemin standalone ou custom plutôt que par une cible testée, et nous le disons plutôt que de revendiquer un support que nous n'avons pas vérifié.
La détection tourne au démarrage et sonde l'export réel, pas seulement l'état de la ressource. Un framework qui démarre après nous ne nous épingle pas définitivement : le bridge réessaie, puis abandonne et retombe en standalone. Chaque bridge lève un drapeau Ready, et le reste de la ressource attend ce drapeau au lieu d'un délai deviné. Un Wait deviné a déjà fait qu'aucun item de vêtement ne s'enregistrait sur un serveur lent.
-- config/config.lua
Config.Framework = 'auto' -- auto | qbcore | esx | vrp | standalone | custom
Config.Notif = 'auto' -- auto | qbcore | esx | oxlib | okok | vrp | standalone | custom
Config.Interact = 'auto' -- auto | avenida_interact | ox_target | qb-target | standalone | custom
Config.Clothing = 'auto' -- auto | qb-clothing | illenium-appearance | fivem-appearance | esx_skin | vrp | standalone-table | custom
Config.Inventory = 'auto' -- auto | ox_inventory | qb-inventory | esx | standalone | customMettez Config.Debug = true et redémarrez. La console affiche une ligne par catégorie de bridge, nommant la cible retenue. Repassez à false une fois que les lignes correspondent à votre serveur : les commandes de diagnostic qu'elle débloque coûtent un à-coup de frame.
Remplacez auto par le nom voulu. La détection est alors entièrement sautée pour cette catégorie, ce qui est utile sur un environnement très modifié où la sonde donne une mauvaise réponse. Les cinq catégories sont indépendantes : vous pouvez forcer le framework et laisser les notifications en auto.
Chaque fichier de bridge porte une branche custom avec un commentaire qui indique où brancher votre propre code. Elle n'est jamais sélectionnée automatiquement, seulement quand vous la nommez, parce qu'un repli qui atterrirait en silence dans une branche vide serait pire qu'un repli en standalone.
Une dépendance dure dans le manifeste, la ligne @vrp/lib/utils.lua qu'on voit partout, empêche la ressource de démarrer sur tous les serveurs où vRP est absent. Le bridge parle donc directement au fil d'événements de vRP. Le bénéfice secondaire est réel : les différences de convention entre forks vivent dans ce helper, donc y aller direct les supprime toutes. vRP 2 et vRP 0.5 ne sont pas supportés, et la ressource le dit en console au lieu de mal se comporter en silence.
Ça tourne, par le chemin standalone ou custom, mais pas par une branche que nous testons. Qbox est assez proche de QBCore pour que forcer qbcore fonctionne sur la plupart des builds. Nous préférons l'écrire plutôt que revendiquer un support non vérifié.
Rien ne casse. La détection réessaie au lieu d'épingler une mauvaise réponse dès la première tentative, et la ressource attend le drapeau Ready du bridge avant de toucher quoi que ce soit. Une ressource qui n'est pas installée du tout est écartée immédiatement, pour que les autres serveurs ne paient pas l'attente.
Oui, c'est fait pour. Chacun possède sa moitié de l'unique emplacement de décoration du ped et rend le reste après un redraw. Ce qu'il ne faut pas faire, c'est lancer les ressources séparées et le pack en même temps, et la console le signale au démarrage si c'est le cas.
Non. bridges/compat.lua fournit une implémentation native de ce que nous utilisons, donc ox_lib est pris en compte quand il est là et remplacé quand il ne l'est pas. Rien dans le manifeste n'en dépend.
