sm_smelterdelivery von SamuelTV verbindet Erzabbau, Schmelzen, Bauteilfertigung und Kundenlieferungen. Das geprüfte Manifest nennt Version 1.0.0 und importiert ESX direkt. Zusätzlich verwendet es ox_inventory, ox_target und ox_lib; es ist keine eigenständige oder QBCore-Ressource.
Ressource und Inventargegenstände vorbereiten
Verwende den Ordner sm_smelterdelivery mit fxmanifest.lua. Starte passende ESX- und ox-Ressourcen vor ensure sm_smelterdelivery. Ergänze iron_ore, iron, steel_ore, steel und component in den Inventardefinitionen, ohne vorhandene Einträge zu überschreiben. Das mitgelieferte steel_ore trägt fälschlich die Anzeige Component; korrigiere die Bezeichnung und behalte den Schlüssel.
Die Installationsdatei nennt widersprüchliche Bildpfade: web/build/images und web/build/img. Verwende Bildordner und Bildzuordnung deiner installierten ox_inventory-Version, statt beide Pfade blind anzulegen. Sichere die Inventarkonfiguration und prüfe, dass alle fünf mitgelieferten Gegenstandsbilder laden.
Rezepte und Kundenaufträge verstehen
Der Code sieht beim Sammeln 3 iron_ore oder 2 steel_ore vor. Schmelzen verbraucht 3 iron_ore für 1 iron beziehungsweise 2 steel_ore für 1 steel. Aus 2 iron und 1 steel entsteht 1 component. Client-Fortschritt dauert 10 Sekunden beim Sammeln und 6,5 Sekunden beim Schmelzen oder Fertigen; diese Anzeigen erzwingen keine serverseitigen Wartezeiten.
Config.MoneyPerComponent beträgt standardmäßig 1400 Spielgeld pro Bauteil. Easy-Kunden verlangen 1–3, Medium 3–8 und Hard 8–12 Bauteile; die Client-Zeitlimits sind 8, 5 und 3 Minuten. Verfügbare Kunden werden zwischen Spielern geteilt. Der stündliche Reset löscht laufende Lieferungen und erneuert die Kunden; dauerhafte Auftragsspeicherung ist das nicht.
API- und Transaktionsprobleme vor der Freigabe beheben
Der Server ruft wiederholt exports.ox_inventory:Inventory() auf und verwendet Methoden dieses Ergebnisses. Gleiche das mit den dokumentierten Exports deiner Version ab, statt Kompatibilität anzunehmen. Die beiden Sammel-Callbacks lassen außerdem das von ox_lib dokumentierte source-Argument weg und lesen die globale source-Variable. Korrigiere Spielerzuordnung und Inventaranbindung vor Belohnungstests.
Der Server speichert den Besitzer einer Lieferung und lehnt fremde oder abgeschlossene Aufträge ab, speichert aber weder Ziel noch Frist für die Abschlussprüfung. Auch Sammeln und Fertigen prüfen Abstand und Fortschritt nicht auf dem Server. Ergänze verbindliche Orts- und Zeitprüfungen sowie höchstens einen aktiven Auftrag; Client-Timer und Zielzone sind keine Serverberechtigung.
Entnahme und Hinzufügen von Gegenständen werden nicht auf Erfolg geprüft. Eine Lieferung wird erst nach Wartezeiten hinter der Belohnung als abgeschlossen markiert. Reserviere den Abschluss vor dem Warten und sichere Verbrauch und Zahlung gegen Teilfehler ab. Der Client löscht seinen Auftrag ohne erfolgreiche Serverbestätigung. Teste volle Inventare, Materialmangel, wiederholten Abschluss, Zeitablauf, Stundenreset und erneutes Verbinden vor dem Einsatz in einer Live-Wirtschaft.
Am 10. September 2026 anhand der Revision 5fa8179ecaa18aecbacbb11234b6fc1812b9d1ec geprüft. Alle gelieferten Lua-Dateien, Manifest und Installationshinweise wurden gelesen und die offizielle ox-API-Dokumentation abgeglichen. Keine FiveM-Ressource, Fertigung oder Auszahlung wurde ausgeführt.
Geprüften Quellcode von Smelter Delivery lesen