Qu’est-ce que kq_link ? Le bridge derrière les scripts KuzQuality

Si tu as installé un script KuzQuality, tu as peut-être remarqué que kq_link figure parmi les dépendances requises. Cet article explique ce que c’est, pourquoi il existe et pourquoi ce principe est courant dans toute la communauté des développeurs FiveM.

Le problème : les serveurs FiveM ne sont pas standardisés

Les serveurs FiveM tournent sur des frameworks différents. Certains utilisent ESX, d’autres QBCore, d’autres encore QBox, vRP, TMC ou un framework entièrement personnalisé. En plus, chaque serveur peut avoir son propre système d’inventaire, de ciblage et de notifications.

Un script qui communique directement avec ESX ne fonctionnera pas sur QBCore sans modifier le code. Un script qui appelle ox_target cassera sur un serveur qui utilise qb-target. Et un script basé sur un système de notifications aura l’air bancal sur un serveur qui en utilise un autre.

C’est un vrai problème pour tout développeur qui veut que son travail tourne sur plus d’une configuration de serveur. La solution naïve consiste à écrire une version séparée pour chaque framework, mais ça prend du temps et c’est difficile à maintenir. La meilleure solution, c’est un bridge.

Qu’est-ce qu’un bridge de script ?

Un bridge (une passerelle) est une ressource qui se place entre un script et les dépendances du serveur. Au lieu d’appeler ESX ou QBCore directement, le script appelle le bridge. Le bridge détecte le framework et les dépendances en place, puis traduit l’appel en conséquence.

Ce n’est pas un concept propre à KuzQuality. La plupart des développeurs de scripts FiveM sérieux utilisent une forme de bridge. Tu as peut-être déjà vu des ressources similaires comme ox_lib, jim_bridge, pp-bridge ou tw_bridge listées comme dépendances d’autres scripts. Le principe est le même pour toutes : on écrit le script une seule fois et le bridge gère les différences entre frameworks.

Qu’est-ce que kq_link ?

kq_link est la ressource bridge open source de KuzQuality. Elle relie les scripts KuzQuality au framework, au système d’inventaire, au système de ciblage et au système de notifications du serveur, quels qu’ils soient.

Concrètement, voici ce qu’elle gère :

• Détection du framework : identifie automatiquement si le serveur tourne sous ESX, QBCore, QBox, vRP, TMC ou sans aucun framework
• Intégration de l’inventaire : transmet les vérifications, ajouts et retraits d’items au bon système d’inventaire
• Système de notifications : envoie les notifications via la ressource de notification utilisée par le serveur
• Système de ciblage : fonctionne avec ox_target, qb-target ou, à défaut, un texte 3D intégré
• Fonctions utilitaires : des outils partagés sur lesquels s’appuient les scripts KuzQuality, pour ne pas avoir à les réécrire dans chaque ressource

Comme kq_link s’occupe de tout ça, aucun script KuzQuality n’a besoin de savoir sur quel framework tourne le serveur. Le script appelle simplement kq_link, et kq_link fait le reste.

Pourquoi une ressource séparée ?

kq_link s’installe une seule fois et sert à tous les scripts KuzQuality. Tous les scripts du serveur qui utilisent kq_link profitent du même bridge, au lieu que chacun embarque sa propre copie du même code.

Ça veut aussi dire que les mises à jour de compatibilité avec les frameworks se font à un seul endroit. Quand une nouvelle version d’un framework change quelque chose, kq_link est mis à jour et tous les scripts KuzQuality en profitent automatiquement.

Installer kq_link

kq_link est gratuit et open source. Il est disponible sur GitHub à l’adresse github.com/Kuzkay/kq_link.

L’installation est simple :

1. Télécharge ou clone kq_link dans le dossier resources/ du serveur. Le dossier doit s’appeler exactement kq_link. Si tu le renommes, tous les scripts KuzQuality qui en dépendent cesseront de fonctionner.
2. Ouvre server.cfg et ajoute ensure kq_link après le framework et les dépendances comme les systèmes de ciblage ou de notifications
3. Ouvre kq_link/config.lua et définis le framework et les dépendances

kq_link détecte automatiquement le framework, mais il reste recommandé de le définir manuellement dans la config pour éviter toute ambiguïté.

Tous les détails d’installation sont disponibles sur docs.kuzquality.com.

En résumé

Les bridges de script sont un modèle standard dans le développement FiveM. Ils règlent le problème de la fragmentation des frameworks en servant de couche de traduction entre un script et les dépendances du serveur.

kq_link est la version KuzQuality de ce principe. Il est gratuit, open source et requis pour tous les scripts KuzQuality. Installe-le une fois, configure-le selon ton serveur, et chaque script KuzQuality fonctionnera quel que soit le framework utilisé.