attempt to index a nil value (global 'QBCore') : le GetCoreObject correctif

Quelque part dans votre console :

SCRIPT ERROR: @my_script/client/main.lua:8: attempt to index a nil value (global 'QBCore')

QBCore est en cours d'exécution, le script semble correct et QBCore est toujours nil. Voici pourquoi et comment résoudre ce problème sur QBCore et sur QBox.

#Pourquoi QBCore est nil

Les anciens scripts QBCore obtenaient l'objet principal avec un événement :

QBCore = nil
TriggerEvent('QBCore:GetObject', function(obj) QBCore = obj end)

Cet événement a été supprimé de qb-core. Personne ne répond plus, donc QBCore reste nil et la première ligne QBCore.Functions… plante.

#Le correctif : GetCoreObject

Demander qb-core son objet à l'export, en haut du fichier :

local QBCore = exports['qb-core']:GetCoreObject()

C'est la même ligne sur le client et sur le serveur. Placez-le dans chaque fichier qui utilise QBCore, ou une fois dans un fichier partagé que le manifeste charge en premier :

-- fxmanifest.lua
shared_script 'shared/core.lua'
client_scripts { 'client/*.lua' }
server_scripts { 'server/*.lua' }

-- shared/core.lua
QBCore = exports['qb-core']:GetCoreObject()

Astuce: si QBCore est local dans un fichier, les autres fichiers ne peuvent pas le voir. Une erreur nil dans un seul fichier du script signifie généralement exactement cela.

#Toujours nil ? qb-core n'est pas encore en cours d'exécution

L'export ne répond que si qb-core a démarré en premier. Dans server.cfg :

ensure oxmysql
ensure ox_lib
ensure qb-core
ensure [qb]

ensure my_script

Alors :

• Vérifiez le propre démarrage de qb-core en haut de la console du serveur. Une erreur de base de données signifie que ses exportations n'existent jamais et vous obtenez No such export GetCoreObject in resource qb-core.
• Ajoutez la dépendance au fxmanifest.lua du script, afin que FiveM démarre qb-core en premier ou refuse de démarrer le script sans cette dépendance :

dependency 'qb-core'

#Le QBox

QBox est qbx_core, et il conserve une couche de compatibilité pour les scripts qb-core : exports['qb-core']:GetCoreObject() renvoie toujours un objet, donc la plupart des scripts QBCore s'exécutent tels quels.

Ce qui change, c'est l'ordre et le nom dans server.cfg :

ensure oxmysql
ensure ox_lib
ensure qbx_core

Il n'y a pas de dossier qb-core distinct sur QBox. Si vous en avez encore un, retirez-le, sinon les deux cœurs se battent.

Pour le nouveau code, QBox préfère ses propres exports à la grande table QBCore, par exemple sur le serveur :

local player = exports.qbx_core:GetPlayer(source)
if player then
    print(player.PlayerData.citizenid)
end

#Données du joueur sur le client

Lire le lecteur trop tôt est l'autre classique nil :

-- this runs before the player is loaded: job is nil
local job = QBCore.Functions.GetPlayerData().job

Attendez plutôt le joueur :

local QBCore = exports['qb-core']:GetCoreObject()
local PlayerData = {}

RegisterNetEvent('QBCore:Client:OnPlayerLoaded', function()
    PlayerData = QBCore.Functions.GetPlayerData()
end)

RegisterNetEvent('QBCore:Client:OnJobUpdate', function(job)
    PlayerData.job = job
end)

Si le script peut également être redémarré pendant que vous êtes en jeu, lisez également les données une fois au démarrage, car OnPlayerLoaded a déjà été déclenché à ce moment-là.

#Liste de contrôle

Exécuter ESX à la place ? Le même problème est ESX et nil : correction de esx:getSharedObject.