attempt to index a nil value (global 'QBCore'): la solución con GetCoreObject

En algún punto de tu consola:

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

QBCore está funcionando, el script parece correcto y QBCore sigue siendo nil. Aquí tienes el porqué y cómo arreglarlo en QBCore y en QBox.

#Por qué QBCore es nil

Los scripts de QBCore antiguos obtenían el core object con un evento:

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

Ese evento se eliminó de qb-core. Ya nadie le responde, así que QBCore se queda en nil y la primera línea QBCore.Functions… peta.

#La solución: GetCoreObject

Pídele el objeto a qb-core con el export, al principio del archivo:

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

Es la misma línea en el cliente y en el servidor. Ponla en todos los archivos que usen QBCore, o una sola vez en un archivo shared que el manifest cargue primero:

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

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

Consejo: si QBCore es local en un archivo, los demás archivos no pueden verlo. Un error de nil en un solo archivo del script suele significar justo eso.

#¿Sigue siendo nil? qb-core todavía no está funcionando

El export solo responde si qb-core arrancó antes. En server.cfg:

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

ensure my_script

Después:

• Revisa el arranque del propio qb-core al principio de la consola del servidor. Un error de base de datos ahí significa que sus exports nunca llegan a existir, y te sale No such export GetCoreObject in resource qb-core.
• Añade la dependencia al fxmanifest.lua del script, para que FiveM arranque primero qb-core o se niegue a arrancar el script sin él:

dependency 'qb-core'

#En QBox

El core de QBox es qbx_core, y mantiene una capa de compatibilidad para los scripts de qb-core: exports['qb-core']:GetCoreObject() sigue devolviendo un objeto, así que la mayoría de scripts de QBCore funcionan tal cual.

Lo que cambia es el orden y el nombre en server.cfg:

ensure oxmysql
ensure ox_lib
ensure qbx_core

En QBox no hay una carpeta qb-core aparte. Si todavía tienes una, quítala, o los dos cores se pelearán entre sí.

Para código nuevo, QBox prefiere sus propios exports antes que la gran tabla QBCore, por ejemplo en el servidor:

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

#Datos del jugador en el cliente

Leer al jugador demasiado pronto es el otro nil clásico:

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

En lugar de eso, espera al jugador:

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 el script también se puede reiniciar mientras estás dentro del juego, lee los datos una vez al arrancar, porque para entonces OnPlayerLoaded ya se ha disparado.

#Checklist

¿Usas ESX? El mismo problema allí está explicado en ESX es nil: cómo arreglar esx:getSharedObject.