dv_multijob — Mehrere Jobs pro Charakter
Dein Framework kennt pro Spieler genau einen Job. dv_multijob führt daneben eine eigene Liste: So viele Jobs, wie du erlaubst (Vorgabe fünf), jeder mit seinem Rang. Am Jobcenter schaltet der Spieler zwischen ihnen um — ohne dass ihn jemand neu einstellen muss.
WIE JOBS IN DIE LISTE KOMMEN
Von selbst, sobald jemand von außen einen Job bekommt: Bossmenü, Admin, ein anderes Script. Über den Katalog des Jobcenters, den du in der config.lua zusammenstellst. Oder per Admin-Befehl. Auch Beförderungen werden mitgeschrieben — wer aufsteigt, kehrt mit seinem neuen Rang zurück, nicht mit dem alten.
DIE OBERFLÄCHE
Ein Fenster, zwei Reiter, sechs fertige Farbpaletten: eine Zeile in der config.lua, und es passt zu deinem Server. Rang, Gehalt und die Zahl eingeloggter Kollegen stehen auf jeder Karte. Kein jQuery, kein Font Awesome, keine Google Fonts — alle Zeichen und Schriften liegen lokal, die Oberfläche steht auch ohne Internetverbindung vollständig da.
DER SERVER ENTSCHEIDET
Über das Netz reist nur der Jobname, nie der Rang. Wer einen Job nicht besitzt, kann ihn nicht aktivieren. Wer nicht am Jobcenter steht, nimmt keinen an. Was nicht im Katalog steht, gibt es nicht. Dazu zwei getrennte Bremsen gegen Event-Spam.
AUSSERDEM
· Öffnen per /jobs oder frei belegbarer Taste. Neue Jobs gibt es nur am Jobcenter — der Weg dorthin bleibt damit ein Weg
· Ort, Blip, Marker und Taste frei einstellbar. Oder ganz ohne Ort, dann zählt nur der Befehl
· Feierabend-Job mit Berechtigungsliste. Fehlt er auf dem Server, sagt das die Konsole beim Start — oder die Ressource legt ihn selbst an
· Sperrzeit zwischen Wechseln, nach Kennung geführt: ein Neuverbinden umgeht sie nicht
· Entfernen fragt nach — der erste Klick auf den Papierkorb, der zweite löscht
· Rückfalljobs stehen bei jedem in der Liste, lassen sich nicht löschen und zählen nicht gegen das Limit
· Gelöschte Jobs werden ausgegraut statt Fehler zu werfen
· Discord-Protokoll, je Ereignis abschaltbar
· /mjadd, /mjremove, /mjlist — mit Rechteprüfung, auch aus der Serverkonsole
· Jeder Text steht in einer locales-Datei
TECHNIK
ESX, QBCore und QBox. Das Framework wird zur Laufzeit über dv_core erkannt — keine Bridge, keine Abhängigkeit zu einer Fremdressource. Statt Dauerschleifen läuft die Interaktion über die gemeinsame Schleife von dv_core, das schont die Serverleistung. Die Datenbanktabelle legt die Ressource beim Start selbst an; ein vorhandener Bestand aus Version 1.x wird automatisch übernommen, ohne die alte Tabelle anzutasten.
VORAUSSETZUNGEN
dv_core · oxmysql
config.lua und die Sprachdatei sind offen und frei anpassbar.