Le callback serveur retourne nil : rappels ESX, QBCore et ox_lib

Un script client demande des données au serveur, et ce qui revient est nil, ou rien du tout :

SCRIPT ERROR: @my_script/client/main.lua:21: attempt to index a nil value (local 'result')

Les callbacks serveur sont comment le client demande une question au serveur et reçoit une réponse. Chaque framework a le sien, et ox_lib en a un qui fonctionne partout. Cet article montre les trois et pourquoi ils retournent nil.

#ESX

Enregistrez sur le serveur, déclenchez du client :

-- server
ESX.RegisterServerCallback('my_script:getMoney', function(source, cb)
    local xPlayer = ESX.GetPlayerFromId(source)
    cb(xPlayer.getMoney())
end)

-- client
ESX.TriggerServerCallback('my_script:getMoney', function(money)
    print(money)
end)

La fonction serveur reçoit source et cb, et vous passez la réponse à cb. Les arguments supplémentaires du client arrivent après cb. La fonction client reçoit ce que cb a envoyé.

#QBCore

Les noms diffèrent, la forme est la même :

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

QBCore.Functions.CreateCallback('my_script:getMoney', function(source, cb)
    local Player = QBCore.Functions.GetPlayer(source)
    cb(Player.PlayerData.money.cash)
end)

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

QBCore.Functions.TriggerCallback('my_script:getMoney', function(money)
    print(money)
end)

Si ESX ou QBCore est nil à l'intérieur du script, le callback ne s'enregistre jamais. Consultez ESX est nil et QBCore est nil.

#ox_lib

Les callbacks ox_lib n'ont pas besoin de framework, et la réponse est une valeur de retour au lieu d'une fonction cb :

-- server
lib.callback.register('my_script:getMoney', function(source)
    local xPlayer = ESX.GetPlayerFromId(source)
    return xPlayer.getMoney()
end)

-- client
local money = lib.callback.await('my_script:getMoney', false)
print(money)

Le deuxième argument de await est un délai en millisecondes entre l'appel et la réponse (utilisez false pour aucun). Les arguments pour le serveur le suivent :

local ok = lib.callback.await('my_script:buy', false, 'burger', 2)

lib.callback.register('my_script:buy', function(source, item, amount)
    -- ...
    return true
end)

Pour que le callback existe, le script charge ox_lib dans son manifeste :

shared_script '@ox_lib/init.lua'

Sans lui, lib est nil : consultez ox_lib init.lua non trouvé.

Le serveur peut aussi appeler un client : lib.callback.await('name', playerId, ...) sur le serveur, avec lib.callback.register sur le client. Si vous préférez ne pas attendre, lib.callback('name', false, function(result) end) prend une fonction à la place.

#Pourquoi un callback retourne nil

Presque tous les cas sont l'un de ceux-ci :

1. Le nom ne correspond pas. Les noms de registre et de déclenchement doivent être identiques, y compris la casse. Une faute de frappe ne lève pas une erreur que vous remarquerez, cela ne répond jamais.
2. Il n'est pas enregistré. Le fichier serveur ne s'est jamais exécuté : il est manquant de server_scripts, la ressource ne s'est pas démarrée, ou elle a échoué avant d'atteindre la ligne d'enregistrement.
3. Une erreur sur le serveur, avant la réponse. Si la fonction serveur génère une erreur, par exemple xPlayer est nil, la réponse n'est jamais envoyée. Vérifiez la console serveur, pas celle du client.
4. Vous n'appelez jamais cb sur chaque chemin. Sur ESX et QBCore, une branche qui revient sans appeler cb(...) laisse le client en attente :

-- wrong: no cb when the player is missing
ESX.RegisterServerCallback('my_script:getJob', function(source, cb)
    local xPlayer = ESX.GetPlayerFromId(source)
    if xPlayer then
        cb(xPlayer.job.name)
    end
end)

-- right
ESX.RegisterServerCallback('my_script:getJob', function(source, cb)
    local xPlayer = ESX.GetPlayerFromId(source)
    cb(xPlayer and xPlayer.job.name or nil)
end)

5. Vous avez oublié return sur ox_lib. Une fonction lib.callback.register qui n'a pas de return répond nil.
6. Vous appelez trop tôt. Un callback client déclenché au démarrage du script peut atteindre le serveur avant que son registre s'exécute, après un redémarrage par exemple. Déclenchez-le après le chargement du joueur.
7. Styles mélangés. Un callback enregistré avec lib.callback.register ne peut pas être appelé avec ESX.TriggerServerCallback. Utilisez la paire correspondante.

Conseil : pour savoir quel cas vous avez, ajoutez un print comme première ligne de la fonction serveur. Pas d'impression signifie les étapes 1 ou 2, une impression sans réponse signifie 3 à 5.

#Se protéger contre nil sur le client

Traitez la réponse comme quelque chose qui peut manquer :

local money = lib.callback.await('my_script:getMoney', false)
if not money then
    return print('No answer from the server')
end

Pour les anciens frameworks, vérifiez l'argument avant de l'indexer :

QBCore.Functions.TriggerCallback('my_script:getJob', function(job)
    if not job then return end
    print(job)
end)

#Celui à utiliser

• Écrire pour un seul framework : son propre callback est bien.
• Écrire pour plusieurs frameworks, ou pour QBox : utiliser ox_lib, donc un callback fonctionne partout.
• Écrire du nouveau code : lib.callback retourne des valeurs et se lit comme une fonction normale, ce qui rend les erreurs plus faciles à repérer.

Si vous portez un script entre ESX et QBCore, les noms de callback sont une ligne dans la carte de fonction.

#Liste de contrôle