@ox_lib/init.lua non trouvé et erreurs ox_lib : comment corriger

Un script qui utilise ox_lib échoue à charger dans votre console et le message mentionne @ox_lib/init.lua, ou il échoue avec :

No such export <name> in resource ox_lib

ou ox_lib lui-même ne démarre jamais. Tous ceux-ci proviennent des mêmes quelques causes : le mauvais téléchargement, le mauvais nom de dossier, le mauvais ordre de démarrage, ou une ligne manquante dans le manifeste. Voici la correction pour chacun.

#Ce qu'est ox_lib

ox_lib est une bibliothèque partagée sur laquelle de nombreux scripts comptent : rappels, notifications, menus, barres de progression, locales. Un script se lie avec une ligne dans son manifeste :

shared_script '@ox_lib/init.lua'

Le préfixe @ox_lib/ dit à FiveM de lire le fichier à partir de la ressource appelée ox_lib, pas à partir du dossier du script lui-même. Donc ox_lib doit exister, avoir exactement ce nom, et être démarré.

#1. Télécharger la build de release, pas le source zip

C'est la cause que la plupart des gens rencontrent. Sur GitHub, le bouton vert Code vous donne un zip de la source. ox_lib a une interface web (menus, barres de progression) qui est construite à partir de fichiers source. Le zip source ne contient pas les fichiers construits, donc ox_lib échoue à charger son interface utilisateur ou enregistre un message sur l'interface utilisateur non construite.

À la place :

1. Ouvrez le dépôt ox_lib sur GitHub, puis Releases.
2. Sur la dernière version, téléchargez le fichier nommé ox_lib.zip sous Assets.
3. Décompressez-le. Le dossier à l'intérieur doit être ox_lib et fxmanifest.lua doit s'asseoir directement dedans.

resources/[standalone]/ox_lib/fxmanifest.lua

Si vous avez un dossier source appelé ox_lib-main, supprimez-le et installez la version à la place. Voir aussi Could not find dependency pour les problèmes de noms de dossiers.

#2. Démarrer ox_lib avant les scripts

Dans server.cfg, ox_lib doit venir avant toute ressource qui l'importe :

ensure oxmysql
ensure ox_lib
ensure es_extended   # or qb-core / qbx_core

ensure my_script

Si my_script est assuré au-dessus de ox_lib, il peut se charger en premier et échouer. Le déplacer vers le bas est la correction. Voir the right ensure order in server.cfg.

Ajoutez la dépendance dans le manifeste du script aussi, afin que FiveM la vérifie :

dependency 'ox_lib'

#3. Ajouter le shared script et lua54

Les scripts qui utilisent les fonctions lib. ont besoin de deux lignes dans fxmanifest.lua. Sans l'importation, lib est nil dans le script, et vous obtenez des erreurs comme attempt to index a nil value (global 'lib') :

fx_version 'cerulean'
game 'gta5'

lua54 'yes'

shared_script '@ox_lib/init.lua'

client_scripts { 'client/*.lua' }
server_scripts { 'server/*.lua' }

L'ordre importe : shared_script '@ox_lib/init.lua' doit être listé pour qu'il se charge avant les fichiers de script qui appellent lib. Mettez-le au-dessus de client_scripts et server_scripts.

#4. No such export in resource ox_lib

No such export <name> in resource ox_lib

Cela signifie que le script appelle une export ox_lib qui n'existe pas sur votre serveur. Il y a deux causes :

• Un vieux ox_lib. Le script a été écrit pour une version plus récente. Mettez à jour vers la dernière build de release.
• ox_lib n'a pas pu démarrer, donc aucune de ses exports n'existe. Regardez la console où ox_lib démarre. S'il a imprimé une erreur là, corrigez-la d'abord.

Vérifiez qu'ox_lib démarre proprement : exécutez ensure ox_lib dans la console du serveur et lisez ce qui s'imprime. Un démarrage sain n'imprime aucune erreur et aucune ligne d'échec.

#5. Vérifier l'artifact du serveur

ox_lib a besoin d'une build de serveur FiveM raisonnablement actuelle. Si ox_lib refuse de démarrer et que le message mentionne la version du serveur, mettez à jour vos artifacts. Les étapes sont dans updating FiveM server artifacts.

#6. Le script lui-même n'est pas en faute

Si ox_lib est installé et démarré, mais qu'un script se casse toujours, confirmez que :

• Le dossier du script est nommé comme la ligne ensure le dit.
• Vous n'avez pas copié ox_lib dans le dossier du script. Il doit y avoir une ressource ox_lib, au niveau supérieur de resources (ou dans un dossier à crochets).
• Aucune deuxième copie de ox_lib n'existe dans un autre dossier de catégorie. Deux dossiers avec le même nom de ressource causent un comportement imprévisible.

Astuce : quand vous mettez à jour ox_lib, supprimez le dossier ancien en premier au lieu de décompresser sur lui. Les anciens fichiers laissés derrière peuvent se mélanger avec les nouveaux.

#Liste de contrôle