BonderosaScripts

Lua · FiveM · seit 2021

Scripts, diedeinen Servernicht ausbremsen.

Ich bin Justin. Ich schreibe FiveM-Resources in sauberem, lesbarem Lua — getestet im Live-Betrieb, nicht nur im leeren Testserver.

  • 4+Jahre Lua
  • 2Frameworks
  • 100%Im Spiel einrichtbar
Serverkonsole
resource
bd_autohaus
server
esx_addonaccount · qb-banking · qb-management
client
ESX · jg-advancedgarages · qb-garages · eigene Anbindung

Freitag · 23:41

Du hast acht Monate an dieser Stadt gebaut.

Er brauchte elf Minuten.

Nicht das Script war weg. Der Abend war weg. Und mit ihm die Leute, die seit einem Jahr jeden Freitag da waren.

Das Schlimmste ist nicht der Cheater.

Das Schlimmste ist, dass niemand schimpft. Sie schreiben nichts mehr, sie sind einfach weg. Und am Montag stehen sie auf einem anderen Server und erzählen dort deine Geschichten weiter.

#allgemein

schon wieder der gleiche

meldet das mal wer

ehrlich, so macht das keinen spaß

bin raus für heute

ist wer noch on?

0 von 64 online · 01:12

Ich baue Scripts für Server wie deinen. Ich habe oft genug zugesehen, wie so ein Abend eine Community zerlegt, an der jemand ein Jahr gearbeitet hat.

Und die Antwort war jedes Mal dieselbe: Abo abschließen, etwas einbauen, das dir nie sagt, warum jemand geflogen ist, und hoffen. Das ist keine Antwort.

Also baue ich eine.

  • Serverseitig
  • Nachvollziehbar
  • Ohne Dritte
  • Einmal zahlen

Es gibt AntiCheats für FiveM.Keines, das alle vier zusammen erfüllt. Deshalb dieses.

bd_anticheat · in Entwicklung · kein Termin, bevor es hält

01 / Der Entwickler

Wer hinter BD steckt

Ein Autohaus, das Fahrzeuge gegen Geld ausspuckt, ist ein Automat. Eines, in dem Spieler kalkulieren, ist Rollenspiel.

Ich baue seit mehreren Jahren Scripts für FiveM — angefangen mit kleinen Fixes für den eigenen Server, mittlerweile als das, was ich am liebsten mache.

Alles ist von Hand geschrieben und kommentiert. Wenn etwas nicht läuft, schreib mir auf Discord — da antworte ich selbst.

JustinFiveM Script Developer
Auf Discord schreiben
4+
Jahre Lua
2
Frameworks
100%
Im Spiel einrichtbar
3
Scripts

Wie ich arbeite

  • 01Wirtschaft statt Automat — Scripts, die Spielern etwas zu entscheiden geben.
  • 02Konfiguration, Sprache und Oberfläche gehören dir.
  • 03Alles im Spiel einrichtbar, statt Koordinaten in Dateien zu tippen.
  • 04Support direkt von mir, nicht von einem Ticket-Bot.

02 / Das Angebot

Meine Scripts

Alles was ich veröffentliche, läuft auf meinem eigenen Server im Live-Betrieb.

bd_autohaus

ensure bd_autohaus

Fahrzeughandel, den deine Spieler betreiben — nicht dein Adminteam.

Verfügbarv1.11.125€

Worum es geht

Die meisten Autohaus-Scripts sind Verkaufsautomaten: eine Liste, ein Preis, fertig. Hier entsteht stattdessen eine kleine Wirtschaft.

Die Serverleitung legt fest, welche Fahrzeuge es auf dem Server überhaupt gibt, was sie im Einkauf kosten und wie viele lieferbar sind. Den Rest machen die Spieler: Eine Fraktion bekommt ein Autohaus zugewiesen, kauft daraus im Lagerhaus ein, kalkuliert ihre Verkaufspreise selbst und bestückt ihren Schauraum.

Der Einkaufspreis verlässt dabei den Geldkreislauf. Über ihn steuerst du, wie lukrativ der Fahrzeughandel auf deinem Server ist — ohne eine Zeile Code anzufassen.

Was es kann

Zentraler Fahrzeugmarkt
Du trägst ein, welche Modelle es gibt: Typ, Einkaufspreis, verfügbare Stückzahl. Eine Freigabe-Matrix bestimmt, welches Autohaus welches Fahrzeug führen darf — bei mehreren Autohäusern hat jedes sein eigenes Angebot.
Lagerhaus
Ein begehbarer Ort mit Stellplätzen, auf denen wechselnde Fahrzeuge stehen. Dort kaufen die Besitzer für ihr Autohaus ein und bezahlen sofort aus der Firmenkasse.
Ausstellungsraum
Frei im Spiel gesetzte Stellplätze, auf denen die Fahrzeuge des Autohauses stehen. Kunden gehen hin, drücken E und wählen zwischen Kauf und Probefahrt.
Probefahrten
Zeitlich begrenzt, auf Tempo gedeckelt, gegen Kaution. Wer das Fahrzeug beschädigt zurückbringt, verliert sie an die Firmenkasse. Bei Flugzeug- und Hubschrauberhändlern gilt keine Geschwindigkeitsgrenze.
Rechte über die Fraktion
Kein eigener Job nötig — das Autohaus wird einer bestehenden Fraktion zugewiesen. Welche Ränge verkaufen, Probefahrten anbieten oder Preise setzen dürfen, klickst du im Panel an; Mehrfachauswahl inklusive. Deine Mitglieder behalten ihren Job.
Selbstbedienung, wenn du willst
Der Besitzer stellt ein, ob Kunden nur bei anwesendem Personal kaufen können oder auch allein.
Alles im Spiel
Autohäuser, Lagerhäuser, Stellplätze, Preise und Rechte werden über ein Panel eingerichtet. Nach der Installation musst du keine Datei mehr anfassen.

Technisch

Framework
ESX Legacy 1.9+ / QBCore — automatische Erkennung
Abhängigkeit
oxmysql
Firmenkassen
esx_addonaccount · qb-banking · qb-management
Garagensystem
ESX · jg-advancedgarages · qb-garages · eigene Anbindung
Benachrichtigungen
Framework · ox_lib · okok · mythic · eigenes HUD
Sprache
Deutsch, umstellbar
Änderungen3zuletzt v1.11.0
  • v1.11.0

    Das große Update seit 1.7.0. Neu dazugekommen ist das Leasing — mitsamt einer Übersicht für den Autohaus-Besitzer und einem Schalter, an dem Kunden einzahlen oder ablösen können. Und die Auslieferung ist grundlegend anders: gekaufte Fahrzeuge landen nicht mehr in einer Garage, sondern werden am Autohaus übergeben. --- ## Neu ### Leasing Statt zu kaufen kann ein Kunde ein Fahrzeug leasen. Die Wahl trifft er direkt am Ausstellungsfahrzeug: unter *Kaufen* und *Probefahrt* stehen die angebotenen Laufzeiten mit ihrer Rate. **Es sind Wochenraten**, und das steht überall dabei — auf den Knöpfen, in der Rückfrage vor dem Abschluss, in der Bestätigung danach und bei `/leasing`. Niemand soll Monatsraten erwarten und dann jede Woche abgebucht werden. Die Anzahlung geht beim Abschluss in die Firmenkasse, jede weitere Rate, sobald sie eingeht. Das Autohaus verdient über die Laufzeit mehr als beim Barkauf — und trägt dafür das Risiko. Bleibt eine Rate offen, läuft eine Frist. Danach wird das Fahrzeug eingezogen: es geht zurück in den Bestand des Autohauses und darf erneut verkauft werden, die bereits gezahlten Raten behaltet ihr. Eingezogen wird nur, während der Kunde online ist — er soll die Chance haben, doch noch zu zahlen. War er sehr lange nicht mehr da, wird auch ohne ihn eingezogen. Wer einmal ein Fahrzeug verloren hat, bekommt serverweit kein Leasing mehr. **Die Zinsen setzt der Besitzer selbst**, je Laufzeit einen eigenen Satz, im Reiter *Autohaus*. Sechs Wochen billiger, vierundzwanzig teurer: das ist seine Kalkulation. Unter den Feldern rechnet das Panel ein Beispiel mit. Und ob sein Autohaus überhaupt Leasing anbietet, entscheidet er ebenfalls dort. ### Übersicht für den Besitzer Ein neuer Reiter **Leasing** zeigt alle Verträge des Autohauses: Kunde, Fahrzeug, Kennzeichen, Wochenrate, wie viele Raten bezahlt sind, was noch offen ist, wann die nächste und wann die letzte Rate fällig wird. Überfällige Verträge stehen oben und nennen die Frist bis zum Einzug. Darüber zwei Summen: **wie viel Geld draußen ist** und **was pro Woche hereinkommt**. ### Der Leasing-Schalter Der Besitzer kann einen Ansprechpartner aufstellen. Wer bei diesem Haus least, kommt dort mit **E** an seinen Vertrag und sieht dieselben Zahlen: offener Betrag, Wochenrate, Raten, nächste und letzte Zahlung. Zwei Dinge kann er tun. **Einen Betrag einzahlen**, die Höhe wählt er selbst — was davon volle Wochenraten deckt, gilt sofort als bezahlt und die Fälligkeit rückt vor, der Rest bleibt als Guthaben stehen und wird beim nächsten Einzug zuerst verwendet. Oder **das Leasing ablösen**, also alle offenen Raten auf einen Schlag; danach gehört ihm das Fahrzeug. Jede Zahlung setzt eine Überfälligkeit zurück — die Frist bis zum Einzug läuft dann nicht weiter. Ein Schalter bedient nur Verträge aus dem eigenen Haus; das Geld gehört dem Autohaus, bei dem geleast wurde. ### Auslieferung vor Ort Jedes Autohaus setzt im Panel einen **Auslieferungspunkt**. Dort wird übergeben: das gekaufte oder geleaste Fahrzeug steht fertig da, der Kunde sitzt drin und fährt los. Statt einer Meldung, dass irgendwo etwas eingeparkt wurde, sieht man den Verkauf. --- ## Geändert **Kein Garagensystem mehr.** `Config.Garage`, `Config.DefaultGarage` und die Presets für ESX, jg-advancedgarages, QBCore, die automatische Erkennung und eigene Anbindungen sind alle raus. Übrig bleibt eine einzige Zeile in der Fahrzeugtabelle eures Frameworks: das Fahrzeug gehört dem Kunden und steht von Anfang an draußen. Wo er es danach abstellt, ist Sache seiner Garage — und damit funktioniert es mit jeder. Das heißt auch: **der Auslieferungspunkt ist Pflicht.** Fehlt er, kann ein Autohaus weder verkaufen noch verleasen. Der Kauf wird abgelehnt, bevor Geld bewegt wird, und im Panel steht in Rot, was fehlt. **Kennzeichen bestehen nur noch aus Buchstaben und Ziffern.** Mehr stellt ein Kennzeichen im Spiel nicht dar. Stand ein Sonderzeichen darin, kam es beim Fahrzeug anders an als in der Datenbank — und Garagenscripts fanden ihr Fahrzeug später nicht wieder. **Der Autor** heißt jetzt Bonderosa Scripts, und die **englische Anleitung** ist wieder auf demselben Stand wie die deutsche. --- ## Behoben **Gekaufte Fahrzeuge ließen sich nicht ausparken.** Die Garage meldete *"Could not take vehicle out"*, das Fahrzeug stand in der Liste, kam aber nie heraus. Die gespeicherten Fahrzeugdaten entsprachen nicht genau dem, was ESX beim Einparken schreibt: zwei Felder in der falschen Form, dazu Angaben, die nur QBCore braucht. Beides ist bereinigt. **Durchmischte Stellplätze wechselten vor der Nase des Kunden.** Wer davorstand und kaufte, bekam unter Umständen ein anderes Fahrzeug als das, das er angesehen hatte. Ein Platz wechselt jetzt nicht, solange jemand in der Nähe ist. **An einem durchmischten Stellplatz ließ sich nichts kaufen.** Das Fahrzeug stand da, aber **E** tat nichts. Jetzt lässt sich dort kaufen wie überall sonst. --- ## Beim Update zu beachten **Datenbank.** Führt `install.sql` erneut aus. Bestehende Tabellen werden nicht angerührt; es kommen zwei neue für das Leasing dazu, und dem Autohaus fehlen die Spalten für den Auslieferungspunkt, den Leasing-Schalter und die Zinssätze. Wer lieber einzeln vorgeht, findet die passenden `ALTER TABLE`-Zeilen unten in der Datei. **config.lua.** Eure alte Datei läuft weiter — `Config.Garage` und `Config.DefaultGarage` werden schlicht nicht mehr gelesen. Neu ist der Abschnitt `Config.Leasing`; wollt ihr an Laufzeiten, Anzahlung oder Fristen etwas ändern, übernehmt ihn aus der neuen `config.lua`. **Jedes Autohaus braucht einen Auslieferungspunkt.** Setzt ihn gleich nach dem Update im Panel unter *Autohaus* — vorher verkauft dort nichts mehr.

  • v1.7.0

    Neu Durchmischung der Ausstellung. Ein Autohaus führt meist mehr Fahrzeuge, als in den Schauraum passen. Ein Stellplatz kann deshalb auf Durchmischung gestellt werden: er zeigt dann abwechselnd Fahrzeuge aus eurem Sortiment statt eines festen. Der Kunde bekommt über den Tag alles zu sehen, ohne dass jemand umräumen muss. Im Reiter Slots wählt man beim Platz statt eines Fahrzeugs den Eintrag ↻ Durchmischung. Wie oft gewechselt wird, stellt der Besitzer im Reiter Autohaus ein — ein Wert für alle gemischten Plätze, zwischen 1 und 240 Minuten. Zweimal dasselbe hintereinander kommt nicht vor. Garagensystem automatisch erkennen. Neu ist Config.Garage = 'auto'. Damit schaut das Script selbst nach, welche Spalten eure Fahrzeugtabelle hat, und füllt nur die vorhandenen. Für Garagenscripts gedacht, deren Aufbau nirgends dokumentiert ist — okokGarage etwa. Behoben Gelöschte Stellplätze ließen ihr Fahrzeug stehen. Es verschwand erst beim nächsten Durchlauf einer Prüfschleife. Jetzt ist es sofort weg — im Schauraum wie im Lagerhaus. Ausgestellte Fahrzeuge schwebten. Kam man nach einer Weile zurück, wurde das Auto manchmal gesetzt, bevor der Boden geladen war. Jetzt wird gewartet, bis der Untergrund da ist. Beim Update zu beachten install.sql erneut ausführen oder die ALTER TABLE-Zeilen am Ende nehmen — zwei neue Spalten, autohaus_slots.rotate und autohaus_dealerships.rotate_minutes. Sonst ändert sich nichts, die config.lua könnt ihr behalten.

  • v1.6.1

    Das größte Update seit dem ersten Release. Fahrzeuge werden jetzt per LKW angeliefert, das Panel lässt sich auf eure Serverfarben umstellen, und das Script läuft neben ESX auch auf QBCore. Neu Anlieferung per LKW. Bestellte Fahrzeuge stehen nicht mehr sofort im Bestand. Ein Sattelzug bringt sie ans Autohaus — mit genau den bestellten Modellen auf dem Anhänger. Den Anlieferungspunkt setzt der Besitzer selbst im Panel; ohne ihn kann er nichts bestellen. Wer am Lagerhaus einkauft, hat die Wahl: liefern lassen gegen Gebühr, oder selbst fahren und sparen. Beim Selbstfahren steht das beladene Gespann bereit, das Ziel ist als großer Kreis markiert, und angekommen zählt es erst mit stehendem Fahrzeug. Wer es nicht rechtzeitig schafft, bekommt die Ware trotzdem — bezahlt ist bezahlt. Der LKW ist unantastbar: kein Schaden, keine platzenden Reifen, der Fahrer lässt sich weder töten noch herausziehen. QBCore. Läuft jetzt auf ESX Legacy und QBCore und erkennt beim Start selbst, was vorhanden ist. Lackierungen. Kunden wählen beim Kauf ihre Farbe, Verkäufer stellen sie im Verkaufsreiter ein, bevor sie das Angebot rausschicken. Sechzehn Farben, in der Config änderbar. Farben des Panels. Die Serverleitung stellt zwei Farbwerte ein — acht Vorschläge oder ein eigener Hexwert, Vorschau beim Tippen. Alles Weitere rechnet das Panel selbst aus, die Beschriftung bleibt bei jeder Farbe lesbar. Lizenzsystem. Nach einer erfolgreichen Prüfung gilt die Lizenz sieben Tage lokal und wird täglich erneuert. Ist die Lizenzstelle einmal nicht erreichbar, merkt davon niemand etwas. Geändert Der Reiter Einstellungen heißt jetzt was er ist: serverweite Sachen und alles, was nur die Serverleitung setzen darf. Verkauf ohne Mitarbeiter entscheidet die Serverleitung, pro Autohaus — nicht mehr der Besitzer. Liefergebühr und Frist für Selbstfahrten sind im Panel einstellbar. Jedes Lagerhaus bekommt einen eigenen LKW-Platz: /lager lkw. Behoben Verkaufte Fahrzeuge waren immer schwarz, egal welche Farbe im Schauraum stand. Rote Schrift war auf dem dunklen Grund zu blass. Kontraste und Schriftgrößen überarbeitet, nichts mehr unter 11 px. Geldbeträge in Tabellen standen versetzt. Auswahlfelder im Lagerhaus-Fenster schoben den Text aus der Karte. Tastaturbedienung hatte keinen sichtbaren Fokusrahmen. Unter QBCore landete die falsche Kennung in der Fahrzeugtabelle. Beim Update zu beachten Datenbank. Führ install.sql erneut aus. Bestehende Tabellen werden nicht angefasst, es kommen nur die neuen Spalten und die Tabelle für Lieferungen dazu. Wer schon eine frühere Fassung dieses Updates hatte, findet am Ende der Datei die einzelnen ALTER TABLE-Zeilen. config.lua. Übernimmst du deine alte Datei, fehlen darin die neuen Blöcke Config.Delivery, Config.Colors und Config.Theme. Das Script sagt dir beim Start, was fehlt, und läuft ohne die betroffene Funktion weiter. Am einfachsten ist es, die neue config.lua zu nehmen und deine Werte zu übertragen. Lizenzschlüssel. Trag deinen Schlüssel ein: Config.License.key = 'DEIN-SCHLUESSEL' Anlieferungspunkte. Jedes bestehende Autohaus braucht einen, sonst kann es nichts mehr bestellen. Der Besitzer setzt ihn im Panel unter Autohaus. Sag deinen Fraktionen vorher Bescheid, sonst stehen sie ratlos davor.

UI – Teils mit KI generiert.

  • ESX Legacy
  • QBCore
  • oxmysql
  • Lua

bd_k9

ensure bd_k9

Eine Diensthundeeinheit, die der Officer führt — nicht ein Menü, das Treffer auswürfelt.

Verfügbarv1.2.115 €

Worum es geht

Der Officer ruft seinen Hund, wählt selbst ein Ziel und schickt ihn hin. Es gibt keine Automatik, die im Hintergrund entscheidet: Wer durchsucht werden soll, bestimmt der Spieler, und er muss nah genug dran stehen.

Und es muss keine Polizei sein. Welche Fraktionen einen Diensthund führen dürfen, ist eine Liste in der Config — Bundesheer, Sicherheitsdienst, Zoll, Justizwache, jeder Job deines Servers, wahlweise ab einem Mindestrang. Wer ganz ohne Job-Beschränkung fahren will, schaltet sie aus; für ausgefallene Job-Systeme gibt es zusätzlich eine ACE-Berechtigung.

Der Hund läuft zum Ziel, schnüffelt, kommt zurück. Durchsucht wird das Inventar der Person. Was überhaupt erschnüffelbar ist, trägst du in der Config ein — mit einem Gewicht je Gegenstand, falls Waffen schwerer zählen sollen als Kräuter.

Das Panel liegt oben links über der laufenden Szene. Es dimmt nichts ab und pausiert nichts, weil eine Kontrolle am Straßenrand nicht stehenbleibt, während man ein Menü liest.

Was es kann

Der Officer wählt das Ziel
Keine Automatik. Beim Suchen listet das Panel alle Personen im Umkreis, sortiert nach Nähe. Über dem markierten Ziel schwebt ein gelber Pfeil in der Welt, der beim Blättern mitwandert.
Nicht nur für die Polizei
Welche Fraktionen einen Hund führen dürfen, steht als Liste in der Config — mit optionalem Mindestrang je Job. Bundesheer, Sicherheitsdienst, Zoll: alles möglich. Ohne Job-Beschränkung geht auch, und als unabhängiger Nebenweg gibt es eine ACE-Berechtigung. Geprüft wird serverseitig bei jedem Spawn und jeder Aktion, nicht nur beim Öffnen des Menüs.
Du bestimmst, was er findet
Welche Gegenstände erschnüffelbar sind, ist eine Liste in der Config — und jeder bekommt auf Wunsch ein eigenes Gewicht, damit eine Waffe schwerer zählt als ein Beutel Kraut. Was nicht auf der Liste steht, findet der Hund nicht.
Die Trefferchance stellst du fein ein
Eine Grundchance, ein Zuschlag je gefundenem Stück, eine Deckelung der gezählten Menge und eine Obergrenze, die nie 100 % erreicht. Dazu ein Fehlalarm mit eigener Wahrscheinlichkeit, der genau wie ein echter Treffer aussieht — oder auf null gestellt gar nicht vorkommt. Und ein Cooldown je Officer.
Vier Rassen, frei erweiterbar
Schäferhund, Rottweiler, Husky und Retriever aus dem Grundspiel. Eigene Addon-Peds trägst du in dieselbe Liste ein. Ein Hund pro Officer, dazu ein serverweites Limit gleichzeitig aktiver Einheiten.
Befehle statt Menütiefe
Suchen, Sitz, Fuß, Verfolgen, Wegschicken. Der Hund folgt von selbst, steigt beim Einsteigen mit ins Fahrzeug und beim Aussteigen wieder aus. Ist das Auto voll, kommt eine Meldung statt eines Fehlers.
Läuft mit jedem Inventar
Durchsucht wird das Spielerinventar, und das liest das Script direkt über ESX beziehungsweise QBCore aus. Damit funktioniert es auf jedem Server, ohne dass eine bestimmte Inventar-Resource vorausgesetzt wird.
Räumt hinter sich auf
Stirbt der Officer, verlässt er den Server oder stempelt aus, verschwindet der Hund — und eine laufende Fixierung wird zwingend aufgehoben. Das ist fest im Script, nicht abschaltbar.
Ohne Zusatz-Resource lauffähig
Keine Pflicht-Abhängigkeiten. Die Oberfläche ist ein eigenes NUI, kein ox_lib und kein qb-menu nötig. Ton läuft über die Bordmittel, eigener Sound ist optional.

Technisch

Framework
ESX / QBCore — Erkennung zur Laufzeit
Pflicht-Abhängigkeiten
keine
Durchsucht
Spielerinventar über das Framework
Benachrichtigungen
Framework · ox_lib · Chat, per Config
Oberfläche
eigenes NUI, mitgeliefert
Berechtigung
Job-Liste mit Mindestrang · ACE · oder ganz ohne
Trefferchance
Grundwert, Zuschlag, Deckel, Obergrenze, Fehlalarm
Sprache
Deutsch und Englisch, umschaltbar

UI – Teils mit KI generiert.

  • ESX
  • QBCore
  • Standalone
  • Lua

bd_carwash

ensure bd_carwash

Fahrzeuge werden mit der Zeit sichtbar dreckig — und bleiben es, bis jemand dafür zahlt.

Verfügbarv1.0.120 €

Worum es geht

Ein sauberer Server ist ein toter Server. Hier setzt jedes Fahrzeug über die Zeit Dreck an: nach gefahrenen Kilometern, nach Untergrund, nach Unfällen, sogar im Stand. Regen wäscht ein wenig ab. Wer durch den Schlamm heizt, sieht danach aus, als wäre er durch den Schlamm geheizt.

Der Zustand bleibt. Er übersteht Serverneustart und Despawn, in einer eigenen Tabelle — ohne Anbindung an ein Garagen-, Keys- oder Persistence-Script. Und eine Reparatur wäscht nicht: Wer sein Auto in der Werkstatt richten lässt, fährt trotzdem dreckig weiter.

Sauber wird es nur in der Waschstraße. Standorte legt der Admin im Spiel an, nicht in einer Datei. Gehört die Anlage einer Fraktion, fließt das Geld in ihre Kasse.

Was es kann

Alle sehen denselben Dreck
Der Verschmutzungsgrad ist in FiveM nicht zuverlässig synchron — ohne Gegenmaßnahme sieht jeder Spieler einen eigenen Wert. Hier liegt der maßgebliche Wert im Statebag des Fahrzeugs, serverseitig gesetzt. Jeder Client übernimmt ihn, auch wenn ein bereits dreckiges Fahrzeug erst in Sicht kommt.
Reparieren wäscht nicht
Werkstatt, Garagen-Spawn und Tuning setzen den Dreck engine-seitig auf null. Ein zyklischer Abgleich stellt ihn wieder her. Das braucht keinen Haken in ein fremdes Script und funktioniert deshalb auch mit Scripts, die es heute noch nicht gibt.
Läuft auch ganz ohne Framework
Standalone ist das Hauptziel, nicht der Notfall. ESX, QBCore und QBox kommen über eine Brücke mit automatischer Erkennung dazu. Ohne Framework laufen Verschmutzung, Persistenz und Standortverwaltung voll — nur Bezahlen und damit der Waschvorgang selbst brauchen eines. Fehlt es, wird das Feature sauber abgeschaltet und einmal in der Konsole gemeldet.
Standorte im Spiel setzen
/carwash an der gewünschten Stelle legt einen Standort mit Koordinate und Ausrichtung an. Modus, Radius, Blip, Pakete, Preis-Multiplikator, Öffnungszeiten und Fraktion stellst du je Standort ein — und alles wirkt sofort, ohne die Resource neu zu starten.
Zwei Waschmodi
Durchfahrt mit gesperrter Steuerung und Kamerafahrt, oder Waschen im Stand. In beiden bleibt der Spieler im Fahrzeug, und der Dreck geht sichtbar in Stufen zurück — Vorwäsche, Schaum, Bürsten, Spülen, Trocknen. Bürsten sind Vanilla-Props, es lädt also niemand etwas herunter.
Pakete, die du selbst schneidest
Basis, Premium und Deluxe sind nur Startwerte. Preis, Dauer und Wirkung pflegst du im Admin-Panel, samt Wachs-Buff, der die Verschmutzungsrate eine Stunde lang halbiert. Auf Wunsch steigt der Preis mit dem Verschmutzungsgrad.
Der Server entscheidet
Preis, Abstand zur Anlage, Guthaben und Fahrzeugzuordnung werden serverseitig geprüft, nie im Client. Auch die Admin-Rechte: Framework-Rang, ersatzweise eine ACE-Berechtigung. Discord-Webhooks gehen nie im Klartext an die Oberfläche zurück, sondern nur maskiert.

Technisch

Framework
Standalone · ESX · QBCore · QBox, Erkennung automatisch
Abhängigkeit
oxmysql — die einzige harte
Optional
ox_target · qb-target · ox_lib, mit eigenem Rückfall
Oberfläche
eigenes NUI, keine externen Ressourcen
Standorte
im Spiel angelegt, in der Datenbank
Sprache
Deutsch und Englisch, serverweit fest

UI – Teils mit KI generiert.

  • Standalone
  • ESX
  • QBCore
  • QBox
  • oxmysql

03 / Support

Häufige Fragen

Kauf & Keys3
Woher bekomme ich einen Key?

Am besten registrierst du dir hier oben rechts ein Konto und öffnest ein Ticket — dann läuft die Absprache an einer Stelle und du siehst deine Keys später direkt im Kundenbereich. Alternativ über Discord an bonderosa. Ein Key gehört immer zu genau einem Script; wie oft er für den Download verwendet werden kann und ob er ein Ablaufdatum hat, lege ich pro Key fest.

Kann ich hier direkt kaufen?

Nein. Die Preise auf dieser Seite sind reine Anzeige — es gibt keinen Warenkorb und keine Kasse. Öffne ein Ticket in deinem Konto oder schreib mir auf Discord, dann klären wir Zahlung und Key im Gespräch.

Bekomme ich Updates, und was kosten sie?

Updates sind im Preis enthalten. Neue Versionen landen hier im Download, dein bestehender Key bleibt gültig — du lädst einfach neu herunter. Was sich geändert hat, steht im Changelog direkt beim Script.

Lizenz & Server3
Wie funktioniert die Lizenz auf meinem Server?

Das Script meldet sich beim Start bei bonderosa.de und fragt nach, ob deine Lizenz gültig ist — danach nur noch einmal am Tag. Die Lizenz bindet sich beim ersten Kontakt selbst an deine Server-Installation, bis zu der Anzahl, die ich für dich freigebe. Du musst nichts eintragen außer dem Lizenzschlüssel.

Steht mein Server still, wenn deine Seite ausfällt?

Nein. Erreicht das Script den Lizenzserver nicht, läuft es mit dem zuletzt bekannten Ergebnis eine Karenzzeit von mehreren Tagen weiter und versucht es zwischendurch erneut. Ein Ausfall bei mir darf deinen Server nicht anhalten — abgeschaltet wird nur, wenn ich eine Lizenz aktiv zurücknehme.

Ich ziehe um oder setze neu auf — was passiert mit der Lizenz?

Sag mir Bescheid, dann löse ich die alte Bindung und die neue Installation meldet sich beim nächsten Start von selbst an. Das kostet nichts und dauert keine Minute. Ein Testserver neben dem Live-Server geht ebenso — dafür gebe ich einfach zwei Installationen frei.

Technik3
Läuft das mit meinem Framework?

bd_autohaus und bd_k9 laufen auf ESX Legacy ab 1.9 und QBCore und erkennen beim Start selbst, welches davon aktiv ist. bd_carwash läuft zusätzlich auf QBox und sogar ganz ohne Framework — dann fehlt nur das Bezahlen. Die genaue Liste steht bei jedem Script unter den technischen Daten.

Brauche ich für das Autohaus einen eigenen Job?

Nein. Das Autohaus wird einer bestehenden Fraktion zugewiesen. Welche Ränge verkaufen, Probefahrten anbieten oder Preise setzen dürfen, stellst du im Panel ein — deine Mitglieder behalten ihren Job.

Wie steuere ich damit die Server-Wirtschaft?

Beim Autohaus über den Einkaufspreis: Er verlässt den Geldkreislauf und bestimmt damit, wie viel Gewinn im Fahrzeughandel steckt — dazu die Stückzahl pro Modell. Beim Carwash über Paketpreise und den Faktor je Standort. Alles im Panel, ohne Neustart der Resource.

Support & Daten2
Was ist bei Problemen?

Öffne ein Ticket in deinem Konto — dort siehst du den ganzen Verlauf und ich habe deine Lizenzen direkt daneben. Discord geht auch, Server oder Direktnachricht an bonderosa. Schick mir die Konsolenausgabe und deine Konfiguration, dann schaue ich mir das an. Es antwortet niemand außer mir.

Welche Daten speichert diese Seite über mich?

Ohne Konto: beim Download deine IP-Adresse, damit ich Missbrauch der Key-Eingabe erkennen kann, und beim Lizenzabruf die IP deines Servers — beides wird nach 90 Tagen automatisch gelöscht. Mit Konto kommen deine E-Mail-Adresse, dein Name und deine Lizenzen dazu sowie die Tickets, die du öffnest; geschlossene Tickets werden nach einem Jahr gelöscht. Kein Tracking, keine Werbung, keine Dienste von Dritten. Im Konto kannst du jederzeit eine vollständige Auskunft als PDF anfordern — Einzelheiten in der Datenschutzerklärung.

Frage nicht dabei? Der schnellste Weg zu mir ist Discord.

Direktnachricht an

Discord