Jedes Script bringt dieselbe Bridge-Schicht mit. Sie erkennt, was auf deinem Server läuft, wählt ein Target und sagt dir, welches. Nichts zu installieren, nichts zu patchen, und die Dateien, die die Arbeit machen, sind lesbar.
ESX, QBCore und vRP haben einen eigenen Zweig, getestet gegen die echten Exports. Standalone braucht gar kein Framework, und custom ist ein leerer Zweig, den du selbst füllst. Qbox und ox_core laufen über den Standalone- oder Custom-Pfad statt über ein getestetes Target, und wir schreiben das lieber hin, als einen Support zu behaupten, den wir nicht geprüft haben.
Die Erkennung läuft beim Start und prüft den echten Export, nicht nur ob eine Resource gestartet ist. Ein Framework, das nach uns hochfährt, legt uns nicht dauerhaft fest: Die Bridge versucht es erneut, gibt dann auf und fällt auf standalone zurück. Jede Bridge setzt ein Ready-Flag, und der Rest der Resource wartet auf dieses Flag statt auf eine geratene Verzögerung. Ein geratenes Wait hat schon dazu geführt, dass auf einem langsamen Server gar kein Kleidungs-Item registriert wurde.
-- 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 | customSetz Config.Debug = true und starte neu. Die Konsole gibt eine Zeile pro Bridge-Kategorie aus und nennt das gewählte Target. Stell es zurück auf false, sobald die Zeilen zu deinem Server passen, denn die Diagnose-Commands, die es freischaltet, kosten einen Frame-Hitch.
Ersetz auto durch den gewünschten Namen. Die Erkennung wird für diese Kategorie dann komplett übersprungen, was auf einem stark modifizierten Setup sinnvoll ist, wo die Prüfung die falsche Antwort liefert. Die fünf Kategorien sind unabhängig: Du kannst das Framework erzwingen und die Notifications auf auto lassen.
Jede Bridge-Datei hat einen custom-Zweig mit einem Kommentar, der dir sagt, wo du deinen eigenen Code einhängst. Er wird nie automatisch gewählt, nur wenn du ihn benennst, denn ein Fallback, der still in einem leeren Zweig landet, wäre schlimmer als einer, der in standalone landet.
Eine harte Abhängigkeit im Manifest, die Zeile @vrp/lib/utils.lua, die man überall sieht, verhindert den Start der Resource auf jedem Server ohne vRP. Die Bridge spricht deshalb direkt mit dem Event-Bus von vRP. Der Nebeneffekt ist real: Die Konventionsunterschiede zwischen vRP-Forks stecken in diesem Helper, direkt zu gehen beseitigt sie alle. vRP 2 und vRP 0.5 werden nicht unterstützt, und die Resource sagt das in der Konsole, statt sich still falsch zu verhalten.
Es läuft, über den Standalone- oder Custom-Pfad, aber nicht über einen Zweig, den wir testen. Qbox ist QBCore nahe genug, dass ein erzwungenes qbcore auf den meisten Builds funktioniert. Wir schreiben das lieber hin, als einen ungeprüften Support zu behaupten.
Nichts geht kaputt. Die Erkennung versucht es erneut, statt beim ersten Blick eine falsche Antwort festzunageln, und die Resource wartet auf das Ready-Flag der Bridge, bevor sie irgendetwas anfasst. Eine Resource, die gar nicht installiert ist, wird sofort verworfen, damit andere Server nicht für die Wartezeit zahlen.
Ja, genau dafür sind sie gebaut. Jedes besitzt seine Hälfte des einzigen Ped-Decoration-Slots und gibt den Rest nach einem Redraw zurück. Was du nicht tun darfst: die einzelnen Resources und das Pack gleichzeitig laufen lassen, und die Konsole sagt es beim Start, wenn du es tust.
Nein. bridges/compat.lua liefert eine native Implementierung von dem, was wir nutzen, also wird ox_lib genommen, wenn es da ist, und ersetzt, wenn nicht. Nichts im Manifest hängt davon ab.
