Konvertiere ein QBCore-Skript zu QBox: qbx_core, ox_inventory, ox_target

Du hast ein Skript für QBCore geschrieben und ein Server läuft QBox. Manchmal startet es und funktioniert, manchmal füllt sich die Konsole mit Fehlern über einen fehlenden qb-inventory, qb-target oder qb-menu. Hier ist die Reihenfolge, in die du es portierst und die Stellen, an denen es normalerweise bricht.

Wenn du immer noch einen Kern wählst, ist die gleiche Aufgabe von der anderen Richtung in Konvertiere ein ESX-Skript zu QBCore.

#Was QBox ändert und was es behält

QBox wird auf qbx_core plus die Overextended-Ressourcen gebaut: ox_lib, oxmysql, ox_inventory und ox_target. Es behält eine Kompatibilitätsebene, daher antwortet exports['qb-core']:GetCoreObject() immer noch und PlayerData hat die gleiche Form (citizenid, job, charinfo, metadata, money). Das ist warum viele Skripte unberührt laufen.

Was es nicht behält sind die alten QB-Utility-Ressourcen. Wo QBCore qb-inventory, qb-target, qb-menu, qb-input und qb-progressbar verwendete, erwartet QBox ox_inventory, ox_target und ox_lib. Das sind die Teile, die du portierst.

Der erste Schritt ist, sicherzustellen, dass der Kern korrekt startet:

ensure oxmysql
ensure ox_lib
ensure qbx_core
ensure ox_inventory
ensure ox_target
ensure my_script

Entferne jeden Rest des qb-core-Ordners, da zwei Kerne in Konflikt geraten. Siehe QBCore ist nil: GetCoreObject, falls das Objekt fehlt.

#Schritt 1: Abhängigkeiten im Manifest

fx_version 'cerulean'
game 'gta5'
lua54 'yes'

shared_script '@ox_lib/init.lua'

dependencies { 'qbx_core', 'ox_lib', 'ox_inventory', 'ox_target' }

@ox_lib/init.lua ist das, was dir das globale lib gibt. Falls es nicht gefunden wird, siehe ox_lib init.lua nicht gefunden.

#Schritt 2: Den Spieler besorgen

Beide funktionieren auf QBox. Der erste ist der Kompatibilitätsstil, der zweite ist der QBox-Weg:

-- QBCore style (still works through the compatibility layer)
local QBCore = exports['qb-core']:GetCoreObject()
local Player = QBCore.Functions.GetPlayer(source)

-- QBox style
local player = exports.qbx_core:GetPlayer(source)
if player then
    print(player.PlayerData.citizenid, player.PlayerData.job.name)
end

Beide geben nil für einen Spieler zurück, der nicht geladen ist, daher behalte die nil-Überprüfung. Um einen geladenen Spieler nach Citizen-ID zu finden, hat QBox auch GetPlayerByCitizenId. Wenn du portierst, kannst du die QBCore-Aufrufe an Ort und Stelle lassen und sie später einzeln ersetzen.

#Schritt 3: Inventar

Hier brechen die meisten Skripte. qb-inventory und ox_inventory teilen weder Gegenstands-Definitionen noch Funktionsnamen.

local src = source
local ok = exports.ox_inventory:AddItem(src, 'water', 2, { quality = 100 })
if not ok then
    lib.notify(src, { description = 'Your inventory is full', type = 'error' })
end

AddItem gibt einen falschen Wert zurück, wenn der Gegenstand nicht existiert oder nicht getragen werden kann, überprüfe es. Gegenstands-Definitionen bewegen sich auch. QBCore behält sie in qb-core/shared/items.lua, ox_inventory in ox_inventory/data/items.lua. Füge jeden Gegenstand, den das Skript verwendet, dort ein, im ox_inventory-Format. Wie man das macht ist in Gegenstände zu ox_inventory hinzufügen, und das QBCore-Format, von dem du kommst, ist in Gegenstände zu qb-inventory hinzufügen.

Usable-Gegenstände werden auch anders registriert: QBCore.Functions.CreateUseableItem wird ein export, das in der Gegenstands-Definition in ox_inventory gesetzt wird, die auf eine Funktion in deinem Skript verweist. Die QBCore-Aufrufe funktionieren möglicherweise immer noch über die Kompatibilitätsebene, daher teste einen Gegenstand, bevor du ihn umschreibst.

#Schritt 4: Benachrichtigungen, Progress und Menüs mit ox_lib

ox_lib ersetzt die separaten QB-Utility-Ressourcen. Die Aufrufe sind nah an dem, was du kennst:

-- QBCore
QBCore.Functions.Notify('Done', 'success', 5000)

-- ox_lib (client)
lib.notify({ title = 'Job', description = 'Done', type = 'success', duration = 5000 })

-- QBCore: QBCore.Functions.Progressbar(...) with a callback
-- ox_lib: returns true when completed, false when cancelled
if lib.progressBar({
    duration = 5000,
    label = 'Repairing',
    useWhileDead = false,
    canCancel = true,
    disable = { car = true, move = true },
    anim = { dict = 'mini@repair', clip = 'fixing_a_ped' },
}) then
    print('finished')
else
    print('cancelled')
end

Menüs bewegen sich von qb-menu zu lib.registerContext und lib.showContext, und Eingabe-Formulare von qb-input zu lib.inputDialog. Vollständige Beispiele sind in Benachrichtigungen und Fortschrittsbalken auf ESX, QBCore und ox_lib und ox_lib Kontext-Menüs.

#Schritt 5: ox_target statt qb-target

qb-target nimmt einen Namen, Koordinaten und eine Tabelle von Optionen in seinem eigenen Layout. ox_target nimmt eine Tabelle:

-- qb-target
exports['qb-target']:AddBoxZone('my_zone', vector3(215.0, -810.0, 30.7), 1.5, 1.5, {
    name = 'my_zone', heading = 0, minZ = 29.7, maxZ = 32.7,
}, {
    options = { { event = 'my_script:client:open', icon = 'fas fa-box', label = 'Open', job = 'police' } },
    distance = 2.0,
})

-- ox_target
exports.ox_target:addBoxZone({
    coords = vector3(215.0, -810.0, 30.7),
    size = vector3(1.5, 1.5, 3.0),
    rotation = 0,
    options = {
        { name = 'my_zone_open', icon = 'fas fa-box', label = 'Open', groups = 'police',
          onSelect = function() TriggerEvent('my_script:client:open') end },
    },
})

Beachte, dass event zu onSelect wird (oder event funktioniert immer noch für einen Client-Event) und job wird groups. Die Details sind in qb-target vs ox_target und ox_target Zonen.

#Was normalerweise bricht

• Fehlende Gegenstands-Fehler. Der Gegenstand existiert in der qb-core-Datei, aber nicht in ox_inventory's. Füge ihn hinzu.
• No such export für qb-inventory, qb-target oder qb-menu. Das Skript ruft sie direkt auf: portiere diese Aufrufe oder es wird nie laufen.
• Callbacks. lib.callback ist der QBox-Stil. Wenn ein Skript immer noch QBCore.Functions.CreateCallback verwendet, teste es und verschiebe es zu ox_lib, falls es fehlschlägt: siehe Server-Callbacks.
• Jobs und Gangs mit Graden. QBox hat seine eigenen Job- und Gruppen-Daten. Teste jeden Job-Check, besonders On-Duty und Grad-Vergleiche.
• Gemischte Kerne. Eine Rest-qb-core-Ressource, die neben qbx_core startet.
• Startreihenfolge. Dein Skript über ox_lib, ox_inventory oder qbx_core in server.cfg.

#Checkliste