Converter um script ESX para QBCore (e voltar): mapa de funções e bridge

Você tem um script escrito para ESX, e seu servidor executa QBCore, ou o inverso. A maioria do script é Lua simples e natives que não mudam. Apenas as chamadas do framework mudam, e há menos do que você espera. Este artigo fornece um mapa delas, e então mostra como isolá-las em um arquivo bridge.

#O que fica e o que muda

Natives, NUI, seus próprios eventos, loops, targets e menus funcionam em qualquer framework. O que muda é uma lista curta:

• como você obtém o objeto do framework
• como você obtém um jogador
• dinheiro, jobs e itens
• notificações
• itens usáveis e callbacks
• as tabelas do banco de dados para jogadores

Pesquise o script por ESX. e xPlayer, e cada resultado é algo para converter.

#Mapa de funções

Dois detalhes enganam as pessoas. Tipos de dinheiro: ESX tem money para dinheiro e bank, QBCore usa 'cash' e 'bank' como o primeiro argumento. E a grade: ESX dá um número simples, QBCore uma tabela, então job.grade.level.

Callbacks, que todo segundo script usa, são comparados em detalhes em server callbacks on ESX, QBCore and ox_lib.

#O banco de dados

As tabelas de jogador diferem, então qualquer SELECT ou UPDATE nelas precisa de uma mudança:

Um script que armazena seus próprios dados, com suas próprias tabelas, geralmente continua funcionando, desde que ele chave as linhas em um valor que você pode obter de qualquer framework. Usar o identificador de license para isso funciona em ambos.

#QBox

QBox é mais próximo de QBCore do que de ESX. Seu core é qbx_core, ele mantém uma camada de compatibilidade para exports['qb-core']:GetCoreObject(), e seu inventário é ox_inventory. Um script convertido para QBCore geralmente roda em QBox com poucas mudanças, além de chamadas de inventário.

#A abordagem de arquivo bridge

Se o script deve rodar em ambos, não o polua com if ESX then ... else ... end. Coloque toda chamada do framework em um arquivo, e tenha o resto do script chamar esse arquivo.

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

No manifesto, carregue-o antes dos arquivos que o usam:

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

O script então lê assim, e nunca menciona um framework:

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

Adicione um bridge de cliente para notificações e dados de jogador do mesmo jeito. Quando você adiciona um novo framework, como QBox com qbx_core, você adiciona um branch no bridge, e o script fica como está.

Lembre-se que um bridge só funciona se o framework inicia primeiro. Coloque ensure es_extended ou ensure qb-core acima do script em server.cfg, e leia ESX is nil se o objeto volta nil.

#Checklist