20% OFF ALL PACKAGES
If you have installed a KuzQuality script, you may have noticed that kq_link is listed as a required dependency. This post explains what it is, why it exists, and why the pattern behind it is common across the FiveM scripting community.
FiveM servers run on different frameworks. Some use ESX, some use QBCore, some use QBox, vRP, TMC, or something entirely custom. On top of that, each server may use different inventory systems, different targeting systems, and different notification systems.
A script that talks directly to ESX will not work on QBCore without code changes. A script that calls ox_target will break on a server using qb-target. And a script that uses one notification system will look wrong on a server using another.
This creates a problem for any script developer who wants their work to run on more than one server setup. The naive solution is to write separate versions for every framework. That is time-consuming and hard to maintain. The better solution is a bridge.
A bridge is a resource that sits between a script and the server's dependencies. Instead of a script calling ESX or QBCore directly, it calls the bridge. The bridge figures out what framework and dependencies are running, and translates the call accordingly.
This is not a KuzQuality-specific concept. Most serious FiveM script developers use some form of bridge. You may have seen similar resources like ox_lib, jim_bridge, pp-bridge, or tw_bridge listed as dependencies for other scripts. The principle is the same across all of them: write the script once, let the bridge handle the framework differences.
kq_link is KuzQuality's open-source bridge resource. It connects KuzQuality scripts to whichever framework, inventory system, targeting system, and notification system the server is using.
In practical terms, this is what it handles:
Because kq_link handles all of this, each KuzQuality script does not need to know what framework the server is running. The script just calls kq_link, and kq_link does the rest.
kq_link is installed once and shared across all KuzQuality scripts. Every script on the server that uses kq_link benefits from the same bridge, rather than each script bundling its own version of the same code.
This also means updates to framework compatibility only need to happen in one place. When a new framework version changes something, kq_link gets updated, and all KuzQuality scripts benefit automatically.
kq_link is free and open source. It is available on GitHub at github.com/Kuzkay/kq_link.
Installation is straightforward:
resources/ folder. The folder must be named exactly kq_link. Renaming it will break all KuzQuality scripts that depend on it.server.cfg and add ensure kq_link after the framework and any dependencies like targeting or notification systemskq_link/config.lua and set the framework and dependencieskq_link includes automatic framework detection, but it is still recommended to set the framework manually in the config to avoid any ambiguity.
Full installation details are available at docs.kuzquality.com.
Script bridges are a standard pattern in FiveM development. They solve the framework fragmentation problem by acting as a translation layer between a script and the server's dependencies.
kq_link is KuzQuality's version of this. It is free, open source, and required for all KuzQuality scripts. Install it once, configure it for the server's setup, and every KuzQuality script will work regardless of which framework is running.