Converti uno script ESX a QBCore (e viceversa): mappa delle funzioni e bridge

Hai uno script scritto per ESX, e il tuo server esegue QBCore, o viceversa. La maggior parte dello script è Lua semplice e nativi che non cambiano. Solo le chiamate del framework cambiano, e ce ne sono meno di quello che ti aspetti. Questo articolo ti fornisce una mappa di esse, e poi mostra come isolarle in un file bridge.

#Cosa rimane e cosa cambia

Nativi, NUI, i tuoi eventi, loop, target e menu funzionano su qualsiasi framework. Quello che cambia è una breve lista:

• come ottenere l'oggetto del framework
• come ottenere un giocatore
• soldi, lavori e articoli
• notifiche
• articoli usabili e callback
• le tabelle di database per i giocatori

Cerca nel script ESX. e xPlayer, e ogni hit è qualcosa da convertire.

#Mappa delle funzioni

Due dettagli confondono le persone. Tipi di soldi: ESX ha money per contanti e bank, QBCore usa 'cash' e 'bank' come primo argomento. E il grado: ESX fornisce un numero semplice, QBCore una tabella, quindi job.grade.level.

I callback, che ogni secondo script usa, vengono confrontati in dettaglio in server callbacks on ESX, QBCore and ox_lib.

#Il database

Le tabelle dei giocatori differiscono, quindi qualsiasi SELECT o UPDATE su di esse ha bisogno di un cambiamento:

Uno script che memorizza i suoi dati, con le sue proprie tabelle, di solito continua a funzionare, finché chiavi le righe su un valore che puoi ottenere da qualsiasi framework. Usare l'identificatore della licenza per quello funziona su entrambi.

#QBox

QBox è più vicino a QBCore che a ESX. Il suo core è qbx_core, mantiene un livello di compatibilità per exports['qb-core']:GetCoreObject(), e il suo inventario è ox_inventory. Uno script convertito a QBCore di solito viene eseguito su QBox con pochi cambiamenti, a parte le chiamate di inventario.

#L'approccio del file bridge

Se lo script deve essere eseguito su entrambi, non infarcirlo di if ESX then ... else ... end. Metti ogni chiamata del framework in un file, e fai che il resto dello script chiami quel file.

-- 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

Nel manifest, caricalo prima dei file che lo usano:

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

Lo script legge così, e non menziona mai un framework:

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

Aggiungi un client bridge per notifiche e dati di giocatore nello stesso modo. Quando aggiungi un nuovo framework, come QBox con qbx_core, aggiungi un ramo nel bridge, e lo script rimane come è.

Ricorda che un bridge funziona solo se il framework si avvia per primo. Metti ensure es_extended o ensure qb-core sopra lo script in server.cfg, e leggi ESX is nil se l'oggetto torna nil.

#Checklist