Konvertiere ein ESX-Skript zu QBCore (und zurück): Funktionskarte und Bridge

Du hast ein Skript für ESX geschrieben, und dein Server läuft QBCore, oder umgekehrt. Das meiste des Skripts ist einfach Lua und natives, das sich nicht ändert. Nur die Framework-Aufrufe tun es, und es gibt weniger davon als du denkst. Dieser Artikel gibt dir eine Karte davon, und zeigt dir dann, wie man sie in einer Bridge-Datei isoliert.

#Was bleibt und was ändert sich

Native, NUI, deine eigenen Events, Schleifen, Ziele und Menüs funktionieren auf jedem Framework. Was sich ändert ist eine kurze Liste:

• wie du das Framework-Objekt bekommst
• wie du einen Spieler bekommst
• Geld, Jobs und Gegenstände
• Benachrichtigungen
• usbare Gegenstände und Callbacks
• die Datenbanktabellen für Spieler

Suche das Skript nach ESX. und xPlayer und jeder Hit ist etwas zu konvertieren.

#Funktionskarte

Zwei Details verwirren Menschen. Geldtypen: ESX hat money für Bargeld und bank, QBCore verwendet 'cash' und 'bank' als das erste Argument. Und der Grad: ESX gibt eine einfache Zahl, QBCore eine Tabelle, also job.grade.level.

Callbacks, die jedes zweite Skript verwendet, werden detailliert verglichen in Server-Callbacks auf ESX, QBCore und ox_lib.

#Die Datenbank

Die Spieler-Tabellen unterscheiden sich, daher braucht jede SELECT oder UPDATE auf ihnen eine Änderung:

Ein Skript, das seine eigenen Daten speichert, mit seinen eigenen Tabellen, funktioniert normalerweise weiterhin, solange es die Zeilen mit einem Wert schlüsselt, den du von jedem Framework bekommen kannst. Den License-Identifier dafür zu verwenden funktioniert auf beiden.

#QBox

QBox ist näher an QBCore als an ESX. Sein Kern ist qbx_core, es behält eine Kompatibilitätsschicht für exports['qb-core']:GetCoreObject() und sein Inventar ist ox_inventory. Ein Skript, das zu QBCore konvertiert wurde, läuft normalerweise auf QBox mit wenigen Änderungen, abgesehen von Inventar-Aufrufen.

#Der Bridge-Datei-Ansatz

Wenn das Skript auf beiden laufen muss, verteile es nicht mit if ESX then ... else ... end. Lege jeden Framework-Aufruf in eine Datei und lasse den Rest des Skripts diese Datei aufrufen.

-- bridge.lua (server)
Bridge = {}

local framework
if GetResourceState('es_extended') == 'started' then
    framework = 'esx'
    ESX = exports['es_extended']:getSharedObject()
elseif GetResourceState('qb-core') == 'started' then
    framework = 'qb'
    QBCore = exports['qb-core']:GetCoreObject()
end

function Bridge.GetPlayer(src)
    if framework == 'esx' then return ESX.GetPlayerFromId(src) end
    return QBCore.Functions.GetPlayer(src)
end

function Bridge.AddCash(src, amount)
    local player = Bridge.GetPlayer(src)
    if not player then return false end

    if framework == 'esx' then
        player.addMoney(amount)
    else
        player.Functions.AddMoney('cash', amount)
    end
    return true
end

function Bridge.GetJob(src)
    local player = Bridge.GetPlayer(src)
    if not player then return nil end

    if framework == 'esx' then
        return player.job.name, player.job.grade
    end
    return player.PlayerData.job.name, player.PlayerData.job.grade.level
end

Im Manifest lade es vor den Dateien, die es verwenden:

server_scripts {
    'bridge.lua',
    'server.lua',
}

Das Skript liest sich dann so und erwähnt nie ein Framework:

RegisterNetEvent('my_script:pay', function()
    local src = source
    local job = Bridge.GetJob(src)
    if job == 'mechanic' then
        Bridge.AddCash(src, 100)
    end
end)

Füge eine Client-Bridge für Benachrichtigungen und Spieler-Daten auf die gleiche Weise hinzu. Wenn du ein neues Framework hinzufügst, wie QBox mit qbx_core, fügst du einen Zweig in der Bridge hinzu, und das Skript bleibt wie es ist.

Denk daran, dass eine Bridge nur funktioniert, wenn das Framework zuerst startet. Lege ensure es_extended oder ensure qb-core über dem Skript in server.cfg ein und lese ESX ist nil, falls das Objekt nil zurückkommt.

#Checkliste