Garage FiveM : owned_vehicles et player_vehicles, voitures manquantes corrigées

Symptômes typiques :

You bought a car, and the garage says "No vehicles". Or the car was parked at the street, the server restarted, and it is gone.

Presque tous les scripts de garage lisent la même chose : une table avec une ligne par véhicule possédé. Quand une voiture manque, la ligne est mauvaise, pas le script. Cet article explique les deux tables standard, ce que les colonnes stored et state signifient, et le SQL qui corrige les cas habituels.

#Les deux tables

ESX utilise owned_vehicles. QBCore et QBox utilisent player_vehicles. Les noms sont les mêmes sur tous les serveurs, les colonnes exactes dépendent de votre version et de votre script de garage, alors regardez d'abord la vôtre :

DESCRIBE owned_vehicles;
DESCRIBE player_vehicles;

#ESX : owned_vehicles

Les colonnes principales dans ESX Legacy :

Les scripts de garage ajoutent leurs propres colonnes, par exemple pour le nom du garage ou un état de fourrière.

#QBCore et QBox : player_vehicles

QBox utilise la même table avec les mêmes idées. D'autres colonnes, comme les données de financement, varient.

#Propriétés en JSON

La colonne vehicle sur ESX et la colonne mods sur QBCore contiennent l'apparence et le tuning de la voiture en JSON : couleurs, mods, roues, plaque, extras, néon, et ainsi de suite. Un garage la lit quand vous sortez la voiture, et la réécrit quand vous la stockez.

-- when storing, on the client
local props = lib.getVehicleProperties(vehicle)
TriggerServerEvent('my_garage:store', plate, json.encode(props))

Le JSON doit être valide. Si un script a écrit une chaîne cassée, la voiture ne peut pas être restaurée et spawne en stock ou pas du tout. L'article sur propriétés du véhicule montre comment les construire et les appliquer.

#Véhicules manquants du garage

Exécutez ceux-ci dans l'ordre.

#1. La ligne existe mais appartient à quelqu'un d'autre

La liste du garage filtre par propriétaire. Si la valeur du propriétaire n'est pas celle que le serveur utilise pour votre personnage, la ligne est invisible :

SELECT owner, plate, stored FROM owned_vehicles WHERE plate = 'MIC 001';

SELECT citizenid, license, plate, state FROM player_vehicles WHERE plate = 'MIC 001';

Comparez le propriétaire avec votre vrai personnage :

• ESX : l'identificateur dans users.identifier pour ce personnage. Avec un script multi-personnage, il peut avoir un préfixe tel que char1:, et une voiture achetée avant d'installer le multi-personnage a l'ancienne valeur sans.
• QBCore et QBox : le citizenid dans la table players.

Après un changement de framework, une importation d'un autre serveur ou une insertion manuelle, c'est la cause la plus courante. Corrigez-le en pointant la ligne vers la bonne valeur :

UPDATE owned_vehicles SET owner = 'char1:abcdef...' WHERE plate = 'MIC 001';
UPDATE player_vehicles SET citizenid = 'ABC12345' WHERE plate = 'MIC 001';

Remplacez les valeurs par les vraies de vos tables.

#2. L'état est bloqué « dehors »

Une voiture que vous avez sortie et qui n'est jamais revenue, par exemple après un crash ou un redémarrage, reste marquée comme sortie. Le garage ne liste que les voitures stockées.

ESX, remettez le drapeau stored :

UPDATE owned_vehicles SET `stored` = 1 WHERE `stored` = 0;

QBCore et QBox, mettez l'état à garé :

UPDATE player_vehicles SET state = 1 WHERE state = 0;

Attention : sur un serveur en direct, cela stocke aussi les voitures que les joueurs conduisent en ce moment. Exécutez-le au démarrage, ou limitez-le avec un WHERE sur une plaque ou un propriétaire.

Beaucoup de serveurs exécutent un nettoyage comme celui-ci automatiquement quand la ressource démarre, car après un redémarrage, aucun véhicule ne peut encore être dehors. Si le vôtre ne le fait pas, vous pouvez le faire vous-même :

-- server side, runs when the garage resource starts
AddEventHandler('onResourceStart', function(resource)
    if resource ~= GetCurrentResourceName() then return end
    MySQL.update('UPDATE player_vehicles SET state = 1 WHERE state = 0')
end)

Notez les backticks autour de stored dans la requête ESX : stored est un mot réservé dans MySQL et échoue sans. Certains scripts envoient alors ces voitures à un état de fourrière au lieu du garage, vérifiez donc ce que votre garage attend.

#3. L'id du garage ne correspond pas

Sur QBCore, la colonne garage dit quel garage la voiture vit dans. Un garage nommé dans votre config qui n'est pas dans la ligne, ou un garage renommé, n'affiche rien. Listez les valeurs en utilisation :

SELECT garage, COUNT(*) FROM player_vehicles GROUP BY garage;

Mettez les voitures à un garage qui existe dans votre config.

#4. Le type de voiture ne correspond pas

Les scripts de garage séparent les voitures, bateaux et avions par la colonne type ou la classe du véhicule. Un bateau enregistré comme car n'apparaît jamais dans le garage des bateaux.

#Plaques

La plaque lie le monde, la base de données et les clés. Gardez ces règles :

• La plaque est unique par ligne. Un doublon cause le chargement de la mauvaise voiture.
• La plaque est au maximum 8 caractères dans le jeu, la colonne peut être plus longue sur ESX.
• Les espaces comptent. MIC 001 et MIC001 sont deux plaques, utilisez donc un format.

Pour les clés, voir clés de véhicule.

#Ajouter une voiture à un joueur via SQL

Vous pouvez donner un véhicule en insérant une ligne. Prenez la liste des colonnes de votre propre DESCRIBE, car une colonne requise manquante rend l'insertion échouer :

INSERT INTO owned_vehicles (owner, plate, vehicle, type, `stored`)
VALUES ('identifier-here', 'MIC 001', '{"model":-1130810103,"plate":"MIC 001"}', 'car', 1);

Le model dans le JSON est le hash du modèle, pas le nom. Votre framework ou votre garage a généralement une commande ou une fonction qui le fait correctement, ce qui est la façon la plus sûre quand elle existe.

#Liste de vérification