Convertir un script ESX en QBCore (et inversement) : correspondance des fonctions et pont

Vous avez un script écrit pour ESX, et votre serveur exécute QBCore, ou l'inverse. La plupart du script est du Lua simple et des natives qui ne changent pas. Seulement les appels du framework changent, et il y en a moins que vous ne l'attendez. Cet article vous en donne une correspondance, puis montre comment les isoler dans un fichier pont.

#Ce qui reste et ce qui change

Les natives, NUI, vos propres événements, boucles, cibles et menus fonctionnent sur n'importe quel framework. Ce qui change est une courte liste :

• comment vous obtenez l'objet framework
• comment vous obtenez un joueur
• argent, jobs et objets
• notifications
• objets utilisables et callbacks
• les tables de base de données pour les joueurs

Cherchez ESX. et xPlayer dans le script, et chaque résultat est quelque chose à convertir.

#Table de correspondance des fonctions

Deux détails dérangent les gens. Types d'argent : ESX a money pour l'argent et bank, QBCore utilise 'cash' et 'bank' comme premier argument. Et le grade : ESX donne un nombre simple, QBCore une table, donc job.grade.level.

Les callbacks, que chaque deuxième script utilise, sont comparés en détail dans callbacks serveur sur ESX, QBCore et ox_lib.

#La base de données

Les tables de joueurs diffèrent, donc n'importe quel SELECT ou UPDATE sur eux a besoin d'un changement :

Un script qui stocke ses propres données, avec ses propres tables, continue généralement de fonctionner, tant qu'il indexe les lignes sur une valeur que vous pouvez obtenir d'un des deux frameworks. Utiliser l'identifiant license pour cela fonctionne sur les deux.

#QBox

QBox est plus proche de QBCore que d'ESX. Son core est qbx_core, il garde une couche de compatibilité pour exports['qb-core']:GetCoreObject(), et son inventaire est ox_inventory. Un script converti en QBCore s'exécute généralement sur QBox avec peu de changements, à part les appels d'inventaire.

#L'approche du fichier pont

Si le script doit s'exécuter sur les deux, ne le parsemez pas avec if ESX then ... else ... end. Mettez chaque appel du framework dans un fichier, et faites en sorte que le reste du script appelle ce fichier.

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

Dans le manifest, chargez-le avant les fichiers qui l'utilisent :

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

Le script se lit ensuite comme ceci, et ne mentionne jamais 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)

Ajoutez un pont client pour les notifications et les données du joueur de la même façon. Quand vous ajoutez un nouveau framework, comme QBox avec qbx_core, vous ajoutez une branche dans le pont, et le script reste tel qu'il est.

Rappelez-vous qu'un pont fonctionne seulement si le framework démarre en premier. Mettez ensure es_extended ou ensure qb-core au-dessus du script dans server.cfg, et lisez ESX est nil si l'objet revient nil.

#Checklist