Crafting

€25.20

Add to Basket

Ancomox Crafting

Stationen · In-Game-Baukasten · Fertigkeiten & Qualitätsstufen · Neustartfeste Warteschlange · Zerlegen · Baupläne · Platzierbare Werkbänke

Bereit, deinen Spielern mehr zu geben als ein Menü mit einer Fortschrittsleiste? Vergiss Rezeptlisten, die in einer Config-Datei verstauben, vergiss Crafting-Menüs, aus denen man mit vollem Inventar leer herausgeht, und vergiss den Satz „dafür musst du den Server neu starten“. Ancomox Crafting macht aus Herstellung eine echte Wirtschaft: mit einer Oberfläche, die aussieht wie ein Gerät und nicht wie ein Formular, mit Stationen, die genau den Leuten gehören, die sie bedienen dürfen, und mit einem Baukasten, in dem du Rezepte und Werkbänke mitten im laufenden Betrieb baust.

Ob Anfänger mit Schraubenzieher, Mechaniker-Werkstatt ohne Grind oder Gang-Waffenbank hinter drei Schlössern — jede Station bekommt ihre eigenen Rezepte, ihre eigenen Zugriffsregeln und ihre eigene Ausbaustufe. Aufträge laufen im Hintergrund weiter, während der Spieler längst offline ist. Und wenn der Plan nicht aufgeht, wandert der Gegenstand zurück in seine Einzelteile.

💎 Hochmodernes UI-Design

Das komplette Erlebnis läuft über eine einzige Oberfläche statt über verschachtelte Standard-Menüs — gebaut wie ein Tablet, das der Spieler vor die Szene hält.

Das Spielgeschehen bleibt sichtbar. Kein Vollbild-Overlay, kein schwarzer Kasten. Das Panel liegt vor der Welt, dahinter läuft das Spiel weiter — du siehst, wer den Raum betritt, während du herstellst. Wie stark der Hintergrund abgedunkelt wird, bestimmst du auf einer Skala von 0 bis 1; ab Werk steht sie auf 0.
Drei Designs ab Werk, eine Zeile zum Umschalten. Dark Glass mit Neonkanten für den modernen Server, Minimal für den cleanen Look, Industrial für rauen Chrome-Beton-Stil.
Deine Serverfarbe, überall. Ein einziger Hex-Wert färbt das gesamte Interface — Rahmen, Fortschrittsringe, aktive Zustände, Buttons. Die Schriftfarbe auf farbigen Flächen wird automatisch mitberechnet, damit ein knalliges Gelb genauso lesbar bleibt wie ein dunkles Blau.
Animationen, die etwas erzählen. Karten fliegen gestaffelt ein, Kategorien wechseln weich, der laufende Auftrag zeichnet einen Ring, und am Ende dreht sich eine Ergebnis-Karte auf, die die erreichte Qualitätsstufe zeigt.
Zehn Interface-Sounds — ohne eine einzige Audiodatei. Klick, Hover, Erfolg, Fehler, Stufenaufstieg und mehr werden zur Laufzeit über die Web Audio API erzeugt. Keine Lizenzfragen, keine Downloadgröße, Lautstärke frei einstellbar, komplett abschaltbar.
Nie ein kaputtes Bild. Fehlt das Icon eines Items in deinem Inventar, malt die Oberfläche selbst einen sauberen Platzhalter mit Item-Kürzel — statt des berüchtigten zerbrochenen Bildsymbols, das jede Rezeptliste billig aussehen lässt.
Der laufende Auftrag verdeckt nichts. Statt eines Vollflächen-Overlays erscheint eine kompakte Karte am unteren Rand. Rezeptliste, Materialübersicht und die Welt dahinter bleiben lesbar.
Vorher anschauen, ohne Server. web/index.html doppelklicken — die komplette Oberfläche startet im Browser mit Demo-Daten. Rezepte, Warteschlange, Fertigkeiten, Statistik-Tab: alles klickbar.

🏭 Stationen — dein Wirtschaftsmodell, nicht unseres

Rezepte gehören zu Stationen, nicht in eine globale Liste. Jede Werkbank führt genau die Kategorien oder Rezepte, die du ihr gibst. Das ist der Punkt, an dem die meisten Crafting-Skripte bis heute scheitern — und der Grund, warum bei ihnen jeder Spieler überall alles bauen kann.
Drei Betriebsarten pro Station. active heißt: davorstehen und arbeiten. queue heißt: Auftrag abgeben und später abholen. both bietet beides an und lässt den Spieler entscheiden.
Zugriff nach Beruf und Gang — mit Mindestrang. Pro Station und pro Rezept einstellbar, im Baukasten mit Auswahlliste aus deinem eigenen Framework. Leer heißt: jeder darf, so verhält sich ab Werk jede Station. Dazu optional ein Gegenstand, den man dabeihaben muss — die billigste Art, eine „du brauchst den Schlüssel“-Werkbank zu bauen.
Progression abschaltbar, wo sie stört. Eine Mechaniker-Werkstatt soll kein Grind sein: ein Schalter pro Station, ein weiterer pro Kategorie, und dort gibt es weder XP-Anforderungen noch XP-Gewinn.
Ausbaustufen als Geldsenke, die sich lohnt. Drei Stufen, jeweils mit Geld- und Materialkosten. Sie heben Tempo, Qualitätschance und die Zahl paralleler Warteschlangen-Plätze an — und schalten Rezepte frei, die eine ausgebaute Station voraussetzen.
Platzierbare Werkbänke als Item. Aus dem Inventar heraus im Spiel ausrichten und abstellen. Sie übersteht Neustarts, hat eine eigene Kiste, eine eigene Ausbaustufe und fünf Zugriffsmodi: nur du, eine Freigabeliste, dein Beruf, dein Gang oder offen für alle. Mindestabstand, Höchstzahl pro Charakter und Sperren im Fahrzeug oder im Wasser stellst du ein — beim Einpacken kommt das Item zurück ins Inventar.
Acht fertige Stationen liegen bei. Öffentliche Werkbank, gang-gesperrte Waffenbank, Chemielabor im reinen Auftragsbetrieb, Medizinlabor für den Rettungsdienst, Mechaniker-Werkbank ohne XP, Elektronikwerkstatt, mobile Werkbank und Lagerfeuer. Das ist eine spielbare Vorlage, keine leere Hülle.

🔨 Herstellung, Fortschritt & Verwertung

32 Rezepte in 9 Kategorien ab Werk — inklusive mehrstufiger Produktionsketten, die eine Wirtschaft überhaupt erst entstehen lassen: Schrott wird zu Stahl, Stahl zu Bauteilen, Bauteile zum Waffenrahmen. Wer die Kette abkürzen will, muss einkaufen.
Fertigkeiten pro Kategorie: 50 Stufen, 7 Ränge. Ein Meister-Büchsenmacher ist nicht automatisch Chemiker. Die XP-Kurve liegt offen und ist frei einstellbar, der Config-Prüfer meldet dir beim Start, wenn sie nicht mehr monoton steigt.
Fünf Qualitätsstufen von Grob bis Meisterwerk. Ausgewürfelt aus Fertigkeit, Ausbaustufe der Station und Minispiel-Ergebnis. Die Stufe landet als Metadaten am Gegenstand: Rang, Punktzahl, Haltbarkeitsbonus, Name des Herstellers, Zeitstempel und ein Label-Zusatz. Zwei Pistolen sind ab jetzt nicht mehr dieselbe Pistole.
Drei Fortschritts-Boni, jeweils mit Startstufe und Deckel: Materialersparnis, Bonusausbeute und kürzere Herstellungszeit. Alle drei sind Zahlen in der Config, keine verschlüsselte Formel.
Baupläne in drei Varianten. Einmal lesen und dauerhaft freischalten; eine begrenzte Anzahl Nutzungen; oder schlicht dabeihaben müssen. Sieben Baupläne liegen als Beispiel bei — und ein Export, mit dem du einen davon als Heist-Beute verteilst.
Vier Minispiel-Profile. Drei fertige über ox_lib — ruhig, präzise und hektisch — plus ein viertes Profil als dokumentierter Einhängepunkt für jedes beliebige Fremd-Minispiel. Das Ergebnis beeinflusst Erfolgschance und Qualität, niemals ob überhaupt ein Gegenstand entsteht. Niemand verliert Material an einen Lag-Spike.
Zerlegen statt wegwerfen. Jedes Rezept lässt sich rückwärts laufen. Wie viel zurückkommt, hängt an der Fertigkeit des Spielers — von 35 % beim Neuling bis 80 % beim Meister. Aus Fehlkäufen wird Rohstoff, aus Loot wird Wirtschaftskreislauf.
Werkzeuge mit Verschleiß. Eine Zutat lässt sich als Werkzeug markieren: nötig, aber nicht verbraucht — dafür mit Abnutzung pro Herstellung. Der Hammer geht irgendwann kaputt, und genau das hält deinen Werkzeughandel am Leben.
Nebenprodukte mit eigener Chance. Beim Fräsen fällt Schrott ab, beim Kochen Rückstände. Eine Zeile pro Rezept.

📦 Warteschlange & Materialquellen

Zwei Punkte, die im gesamten Marktsegment fehlen — und die den Unterschied zwischen einem Menü und einem Produktionssystem ausmachen.

Aufträge ziehen aus der Kiste neben dir. Zutaten kommen direkt aus dem Behälter der Werkbank, nicht nur aus dem Rucksack. Ob zuerst die Tasche oder zuerst die Kiste durchsucht wird, stellst du ein. Damit kann eine Crew gemeinsam einlagern und jeder daraus produzieren, ohne 40 Kilo Stahl mit sich herumzuschleppen.
Eine Warteschlange, die wirklich weiterläuft. Aufträge liegen in der Datenbank, nicht im Arbeitsspeicher. Sie laufen weiter, während der Spieler offline ist, und überstehen jeden Serverneustart. Wie viele Aufträge parallel laufen dürfen, wächst mit der Ausbaustufe der Station.
Es geht nie etwas verloren. Volles Inventar bei Fertigstellung? Das Ergebnis wandert in die Kiste der Station. Auch die voll? Dann in ein persistentes Abholfach, aus dem der Spieler es später mit einem Befehl holt. Gelöscht wird nichts — das ist der häufigste Support-Fall bei Crafting-Skripten, und hier existiert er nicht.
Gemeinsame oder private Kisten. Eine Kiste pro Station für die ganze Crew, oder ein eigenes Fach pro Charakter. Slots und Gewicht setzt du pro Station.

🧰 Der Baukasten — alles im Spiel bauen

Kein Neustart. Keine Config-Datei. Kein Texteditor. Kein „das mache ich heute Abend, wenn keiner online ist“.

Stationen live in die Welt setzen. „Im Spiel platzieren“ blendet das Panel aus und stellt ein durchscheinendes Geister-Prop vor dich. Linke Maustaste setzt, rechte bricht ab, das Mausrad dreht in 8-Grad-Schritten, die Pfeiltasten justieren die Höhe. Koordinaten und Ausrichtung landen fertig ausgefüllt im Formular zurück.
Item-Browser mit Suche an jedem Item-Feld. Lupe drücken und du siehst dein komplettes Item-Verzeichnis als Raster — Bild, Anzeigename, interner Name. Die Suche filtert beim Tippen, Enter nimmt den ersten Treffer. Kein Alt-Tab in die items.lua, und nie wieder ein Rezept, das nicht funktioniert, weil irgendwo wather_bottle steht.
Vollständige Formulare — alles, was auch die Config kann. Label, Beschreibung, Geldkosten, Schlagworte, Nebenprodukte, Bauplan-Pflicht, benötigter Gegenstand, Werkzeugverschleiß, Stationsbeschränkung, angehängte Kiste, Kartenmarkierung, Qualitätsbonus, Ausbaustufe und der komplette Zugriffs-Abschnitt für Berufe und Gangs.
Die Config wird überlagert, nie überschrieben. Ein Baukasten-Eintrag mit derselben ID legt sich über den Config-Eintrag. Löschst du ihn, ist das Original zurück. Deine Datei-Anpassungen sind damit unantastbar, auch nach einem Update.
Übertragbar auf den nächsten Server. Alles Gebaute wird zusätzlich als data/custom.json mitgeschrieben. Datei kopieren, /ancoimport — fertig. Kein Datenbank-Export, kein Abtippen.
Rechte serverseitig, Eingaben serverseitig. Zugang über Ace-Berechtigung, feste Identifier-Liste oder deine Framework-Admins. Jedes einzelne Feld wird beim Speichern auf dem Server geprüft und begrenzt — ein manipuliertes Formular kann keine 10.000er-Stückzahl durchdrücken.

🛠 Features & Technische Highlights

Universelle Bridge statt „nur QBCore“. 6 Framework-Adapter, 8 Inventar-Adapter, 4 Target-Adapter — alle als offene, lesbare Dateien mit derselben Schnittstelle. Ein weiteres Inventar anzubinden sind rund 60 Zeilen, kein Umbau am Skript.
Automatische Erkennung in der richtigen Reihenfolge. qbx_core meldet sich gegenüber anderen Ressourcen als qb-core, deshalb wird QBox zuerst geprüft. Genau daran scheitert „QBox-Unterstützung“ bei anderen Skripten in der Praxis.
Ein Config-Prüfer, der dir die Zeile nennt. Beim Booten: unbekannte Kategorie, doppelte Rezept-ID, Item existiert nicht in deinem Inventar, Rezept ist von keiner Station aus erreichbar, XP-Kurve nicht monoton. Datei und Zeile stehen dabei — statt eines stummen Skripts, das einfach nichts anzeigt.
Der Ordner darf umbenannt werden. Die Oberfläche fragt ihren eigenen Ressourcennamen ab. Kein „Bitte den Ordner nicht umbenennen“ im Kleingedruckten.
Der Cursor bleibt nie hängen. Ein Wächter gibt den NUI-Fokus zurück, falls die Oberfläche je stehenbleiben sollte. Dazu /craftclose als Notausgang.
Discord-Logging über fünf Kanäle — Herstellung, Warteschlange, Verwertung, Baukasten und Auffälligkeiten. Gebündelt versendet, damit Discord nicht drosselt, wahlweise zusätzlich in die Datenbank.
Wirtschafts-Statistik im Spiel. Ein eigener Tab für Admins: tagesgenaue Auswertung pro Rezept und Kategorie, meistgebaute Gegenstände, laufende Aufträge. Damit siehst du in zwei Klicks, welches Rezept dir die Wirtschaft kaputt macht.
13 Befehle zum Bauen, Nachladen, XP vergeben, Baupläne verschenken, Statistik ausgeben, Importieren, Ergebnisse abholen, Werkbänke auflisten und Stationszonen sichtbar machen.
24 Exports für deine eigenen Skripte. Fertigkeit abfragen, XP vergeben, ein Doppel-XP-Wochenende schalten, einen Bauplan als Heist-Beute verteilen, Rezepte und Stationen zur Laufzeit anlegen, vorab prüfen ob ein Spieler etwas bauen darf, oder eine Herstellung aus einem völlig anderen Skript heraus starten.
Vier Sprachen: Deutsch, Englisch, Französisch, Spanisch. Englisch ist immer der Rückfall — eine unvollständige Übersetzung zeigt also nie einen rohen Schlüssel wie craft.error.no_mats im Chat.
Performance ernst genommen. Fertigkeiten und Rezepte liegen im Arbeitsspeicher, die Datenbank wird nur bei echten Änderungen beschrieben. Props werden pro Client lokal erzeugt und nach Entfernung ein- und ausgeblendet — kein Netzwerk-Entity, keine verwaisten Objekte nach einem Neustart. Und eine Runde pro Öffnen: die komplette Ansicht kommt in einem einzigen Callback.
Null externe Abhängigkeiten in der Oberfläche. Kein CDN, keine Web-Fonts, keine Sounddateien, kein Build-Schritt, kein npm install. Läuft auch auf Servern mit eingeschränktem Netzwerkzugriff.

🔒 Sicherheit & Anti-Exploit

Kein Rezept, keine Menge und kein Ergebnis kommt jemals vom Client. Der Client sagt nur, was er versuchen möchte — alles andere entscheidet der Server.

Material wird beim Start verbraucht, nie am Ende. Genau daraus entstehen sämtliche bekannten Crafting-Dupes dieser Kategorie: Inventar vor der Ausgabe lesen, danach schreiben, und in dem Fenster dazwischen dupliziert der Spieler. Dieses Fenster gibt es hier nicht.
Vollständiger Rollback. Schlägt das Abziehen mitten in einer Zutatenliste fehl, wird alles bereits Entnommene zurückgelegt und der Auftrag abgelehnt. Der Spieler verliert nichts — auch nicht bei einem Timeout des Inventars.
Speedhack-Sperre. Der Server merkt sich, wann ein Auftrag begonnen hat, und lehnt eine zu frühe Fertigmeldung ab: mit voller Rückerstattung und Eintrag im Sicherheitslog.
Distanzprüfung doppelt. Einmal beim Start des Auftrags, einmal beim Abschluss, mit einstellbarer Toleranz für Latenz. Und weil eine Station mehrere Standorte haben darf, wird immer gegen den nächstgelegenen gemessen.
Rate-Limit gegen Spam. Mindestabstand zwischen zwei Anfragen plus ein rollendes Minutenfenster. Überschreitungen landen im Sicherheitslog, nicht nur in einer Fehlermeldung.
Anti-Makro. Optional erzwungenes Minispiel alle N Herstellungen — auch bei Rezepten, die normalerweise keines haben. Ein Makro kann einen Klick wiederholen, aber keine Geschicklichkeitsprüfung bestehen, mit der es nicht gerechnet hat.
Rechte werden zweimal geprüft. Beruf, Gang, Fertigkeitsstufe, Bauplan, Ausbaustufe der Station und getragener Gegenstand: einmal beim Öffnen der Oberfläche und noch einmal bei jedem einzelnen Auftrag. Wer die Uniform mitten im Craft auszieht, produziert nicht weiter.
87 automatisierte Tests liegen dem Paket bei. Sie laden die echte Konfiguration und den kompletten Servercode mit nachgebildeten FiveM-Funktionen und prüfen unter anderem Anti-Dupe-Rollback, Speedhack-Sperre, Mehrfachnutzung eines Auftrags-Tokens, Bauplan-Sperren, Job- und Gang-Sperren, Stash-Sourcing und die Qualitätsmathematik. Mitgeliefert, damit du das nicht glauben musst, sondern selbst laufen lassen kannst.

⚙️ Kompatibilität & Entwicklerfreundlichkeit

Frameworks: qbx_core (QBox), qb-core (QBCore), es_extended (ESX), ox_core, ND_Core — und ein vollwertiger Standalone-Modus ganz ohne Framework. Die Erkennung läuft automatisch, erzwingen kannst du sie mit einer Zeile.
Inventar-Systeme: ox_inventory (vollständig integriert, empfohlen), qb-inventory inklusive ps-inventory und lj-inventory, qs-inventory, codem-inventory, origen_inventory, tgiann-inventory, core_inventory sowie das klassische ESX-Inventar.
Du nutzt ein eigenes Inventar? Die Adapter liegen offen. Eine Datei, eine Handvoll Funktionen — zählen, hinzufügen, entfernen, Traglast prüfen. Fähigkeitsschalter sagen dem Skript, was dein Inventar kann; fehlt eine Fähigkeit wie Metadaten oder Kistenzugriff, schaltet sich genau diese Funktion sauber ab, statt Fehler in die Konsole zu werfen.
Eigenes Framework? Genauso offen. Identifier, Name, Beruf, Gang, Geld — mehr braucht das Skript nicht.
Third-Eye ist optional. ox_target (inklusive sleepless_interact), qb-target oder interact werden erkannt und genutzt. Ist keines davon installiert, schaltet das Skript automatisch auf einen eigenen Hinweistext mit Tastendruck um — es funktioniert also auch komplett ohne Target-Skript.
Dokumentation, die den Namen verdient. Über 4.500 Zeilen in neun Kapiteln: Installation mit fertigen Copy-Paste-Item-Blöcken für jedes unterstützte Inventar, Konfiguration, Rezepte, Stationen, Baukasten, Exports, Bridge-Anbindung und eine Fehlerbehebung als Ursache-und-Lösung-Tabelle.

📋 Systemanforderungen

Bitte stelle vor dem Kauf sicher, dass dein Server die folgenden Voraussetzungen erfüllt:

Zwingend erforderlich

FiveM-Server: Build 7290 oder neuer.
OneSync: muss aktiviert sein.
Framework: qbx_core, qb-core, es_extended, ox_core oder ND_Core — oder der Standalone-Modus, beziehungsweise die Bereitschaft, dein eigenes Framework über die offenen Bridge-Dateien anzubinden.
Datenbank: oxmysql.
ox_lib: wird für Callbacks, Fortschrittsleisten, Minispiele und Benachrichtigungen genutzt.
Ein Inventar-System.Zutaten und Ergebnisse laufen darüber. Unterstützt werden:
- ox_inventory — empfohlen, vollständig integriert inklusive Kistenzugriff, Metadaten und Haltbarkeit
- qb-inventory, ps-inventory, lj-inventory
- qs-inventory, codem-inventory, origen_inventory, tgiann-inventory, core_inventory
- das ESX-Standardinventar
- jedes andere Inventar — über die offene Schnittstelle in den Bridge-Dateien

Optional

Third-Eye: ox_target, sleepless_interact, qb-target oder interact. Ohne eines davon greift der eingebaute Hinweis mit Tastendruck.
Kisten-Unterstützung im Inventar: nötig für Aufträge, die aus der Werkbank-Kiste ziehen. Fehlt sie, greift das Skript still auf den Rucksack des Spielers zurück, statt einen Fehler zu werfen.
Metadaten-Unterstützung im Inventar: nötig für Qualitätsstufen direkt am Gegenstand. Ohne sie lassen sich die Stufen mit einem einzigen Schalter deaktivieren.

Nach dem Kauf in zwei Minuten erledigt

Ordner ancomox_crafting nach resources/ kopieren.
In der server.cfg nach ox_lib, oxmysql und deinem Framework eintragen: ensure ancomox_crafting
Die neuen Items ins Inventar eintragen — die fertigen Copy-Paste-Blöcke für dein System stehen in docs/installation.md.
Server starten. Die acht Datenbanktabellen legt das Skript beim ersten Start selbst an — eine SQL-Datei liegt nur für den Fall bei, dass dein Datenbank-Benutzer keine Rechte zum Anlegen von Tabellen hat.
Ins Spiel, /craftbuilder öffnen und die erste eigene Werkbank in die Welt setzen.

🛡️ Escrow & Anpassbarkeit

Dieses Skript ist durch das offizielle Cfx.re Asset Escrow System geschützt: die Kernlogik ist verschlüsselt. Alles, was ein Serverbetreiber legitimerweise anfassen will, bleibt jedoch offen und vollständig bearbeitbar:

Sämtliche Config-Dateien — Rezepte, Stationen, Kategorien, Fortschritt, Minispiele und die Hauptkonfiguration
Alle Bridge-Adapter — Framework, Inventar und Target. Du kannst jeden davon anpassen oder einen eigenen dazulegen
Die komplette Oberfläche — HTML, CSS und JavaScript. Farben, Layout, Reihenfolge, alles
Die Balancing-Mathematik für Qualitätsstufen und Boni
Alle vier Sprachdateien — und du kannst beliebig viele weitere anlegen
Die SQL-Datei und die vollständige Dokumentation

Praktisch heißt das: Du kannst dieses Skript optisch und spielerisch komplett zu deinem eigenen machen, ohne je eine verschlüsselte Datei zu berühren.

❓ Häufige Fragen

Läuft das auf meinem Framework?
Wenn du QBox, QBCore, ESX, ox_core oder ND_Core nutzt: ja, ohne Anpassung. Wenn du etwas Eigenes nutzt: die Framework-Bridge ist eine offene Datei mit einer Handvoll Funktionen — Identifier, Name, Beruf, Gang, Geld. Mehr braucht das Skript nicht.

Ich habe ein Inventar, das nicht in der Liste steht.
Dann legst du eine Datei nach dem Vorbild der acht mitgelieferten Adapter an — rund 60 Zeilen. Fähigkeitsschalter oben in der Datei sagen dem Skript, was dein Inventar kann; alles, was es nicht kann, schaltet sich sauber ab statt zu crashen.

Muss ich für jedes neue Rezept den Server neu starten?
Nein. Rezepte, Stationen, Zugriffsrechte und Werkbank-Positionen baust du im Spiel über /craftbuilder. Es gibt zusätzlich /ancoreload, wenn du doch einmal an den Config-Dateien gearbeitet hast.

Was passiert, wenn das Inventar des Spielers voll ist?
Das Ergebnis wandert zuerst in die Kiste der Station, und wenn die auch voll ist, in ein persistentes Abholfach, aus dem der Spieler es später mit /craftclaim holt. Es wird nie gelöscht.

Läuft die Warteschlange wirklich weiter, wenn der Spieler ausloggt?
Ja. Aufträge liegen in der Datenbank, nicht im Arbeitsspeicher. Sie überstehen Logout und Serverneustart und werden beim nächsten Login zur Abholung angeboten.

Kann ich Stationen auf bestimmte Berufe beschränken?
Ja — pro Station und pro Rezept, jeweils mit Mindestrang, und ebenso für Gangs. Im Baukasten wählst du Beruf oder Gang aus einer Liste, die aus deinem eigenen Framework kommt. Lässt du das Feld leer, darf jeder — so ist es ab Werk.

Brauche ich zwingend ein Target-Skript?
Nein. ox_target, sleepless_interact, qb-target und interact werden erkannt und genutzt, wenn sie da sind. Ist keines installiert, blendet das Skript einen eigenen Hinweis mit Tastendruck ein.

Kann ich das Design an meine Serverfarben anpassen?
Ja, und dafür musst du keine CSS-Datei anfassen: ein Hex-Wert in der Config färbt das gesamte Interface, drei fertige Designs stehen zur Auswahl. Wer tiefer gehen will, findet die komplette Oberfläche unverschlüsselt im Paket.