sm_smelterdelivery de SamuelTV associe collecte de minerai, fonte, fabrication de composants et livraisons. Le manifeste examiné indique 1.0.0 et importe directement ESX. Le code utilise aussi ox_inventory, ox_target et ox_lib ; ce n’est pas une ressource autonome ou QBCore.
Préparer la ressource et les objets
Utilisez le dossier sm_smelterdelivery contenant fxmanifest.lua. Démarrez ESX et les ressources ox compatibles avant ensure sm_smelterdelivery. Ajoutez iron_ore, iron, steel_ore, steel et component aux définitions sans écraser les objets existants. Le libellé fourni de steel_ore indique à tort Component ; corrigez l’affichage en conservant sa clé.
Le fichier d’installation donne deux dossiers contradictoires : web/build/images et web/build/img. Utilisez le répertoire et le paramétrage d’images de votre version d’ox_inventory plutôt que de créer aveuglément les deux. Sauvegardez la configuration et vérifiez le chargement des cinq images fournies.
Comprendre recettes et commandes
Le code prévoit 3 iron_ore ou 2 steel_ore par collecte. La fonte consomme 3 iron_ore pour 1 iron ou 2 steel_ore pour 1 steel. La fabrication utilise 2 iron et 1 steel pour 1 component. La progression client dure 10 secondes pour collecter et 6,5 secondes pour fondre ou fabriquer ; ces barres n’imposent aucun délai serveur.
Config.MoneyPerComponent vaut initialement 1400 unités monétaires du jeu par composant. Les clients Easy demandent 1–3 composants, Medium 3–8 et Hard 8–12, avec délais client de 8, 5 et 3 minutes. Les clients disponibles sont partagés entre joueurs. La réinitialisation horaire efface aussi les livraisons actives ; ce n’est pas un stockage persistant des missions.
Corriger API et transactions avant ouverture
Le serveur récupère régulièrement exports.ox_inventory:Inventory() et appelle les méthodes du résultat. Comparez cela aux exports documentés de votre version sans présumer la compatibilité. Les deux callbacks de collecte omettent aussi l’argument source documenté par ox_lib et lisent la variable globale source. Corrigez identité du joueur et intégration d’inventaire avant les tests de récompense.
Le serveur conserve le propriétaire de la livraison et refuse les missions étrangères ou terminées, mais n’enregistre ni destination ni échéance pour valider la fin. Collecte et fabrication ne vérifient pas non plus distance et progression côté serveur. Ajoutez contrôles autoritatifs de lieu, temps et mission active unique ; minuterie et zone client ne sont pas une autorisation serveur.
Les retraits et ajouts d’objets ne sont pas vérifiés. La livraison est marquée terminée seulement après des attentes suivant le paiement. Réservez sa finalisation avant toute attente et rendez consommation et paiement récupérables en cas d’échec partiel. Le client efface sa mission sans confirmation positive. Testez inventaires pleins, matériaux insuffisants, fin répétée, expiration, reset horaire et reconnexion avant une économie publique.
Examiné le 10 septembre 2026 à la révision 5fa8179ecaa18aecbacbb11234b6fc1812b9d1ec. Tous les Lua, manifeste et instructions fournis ont été lus et la documentation officielle des API ox vérifiée. Aucune ressource FiveM, fabrication ou récompense n’a été exécutée.
Lire Smelter Delivery à la révision vérifiée