Einführung: Dieser praxisorientierte Guide zum Warten von FiveM-Skripten

Dieser praxisorientierte Guide zum Warten von FiveM-Skripten richtet sich an Server-Besitzer, Entwickler und QA-Leads. Du erhältst eine produktionsähnliche „Test City" in Docker, eine Abnahme-Checkliste, die du vollständig durchführen kannst, ein quantitatives Risiko-Scoring-Modell und eine Vendor-Prüf-Rubrik, die dich von Problemen fernhält.

Dieser Guide ist Teil unserer umfassenden FiveM-Skripte-Ressource, wo du alle unsere Skriptempfehlungen, Framework-Vergleiche und Kaufratgeber findest.

TL;DR

• Richte Test City (Docker) ein, um jedes Skript sicher zu isolieren und zu benchmarken.
• Führe die Abnahme-Checkliste aus, bevor Geld fließt.
• Verwende den Risiko-Score (0–100), um Einführen/Zurückhalten/Ablehnen zu entscheiden.
• Prüfe Anbieter mit der Vendor-Rubrik (nicht überspringen).
• Falls du kaufst, bevorzuge seriöse Shops – sieh unsere Empfehlungen: Beste Tebex-Shops.

---

Teil 1 — „Test City" (Docker) für sicheres, wiederholbares Skript-QA

Was du bekommst

• Containerisierter FXServer + MariaDB (+ Adminer)
• Saubere server.cfg mit oxmysql und Basis-Ressourcen
• Bind-gemountetes resources/custom, in das du das zu testende Skript legst
• Deterministische Netzwerknamen/Ports für einfache DB-Strings

test-city.zip herunterladen (Github)

Wie man Docker nutzt (FiveM)

So verwendest du es:

1. Entzippen → cd test-city
2. .env.example nach .env kopieren und LICENSE_KEY setzen (und DB-Zugangsdaten nach Bedarf).
3. oxmysql in server-data/resources/[standalone]/oxmysql/ legen.
4. Das zu testende Skript in server-data/resources/custom/<skriptname>/ ablegen und ensure <skriptname> zur server.cfg hinzufügen.
5. docker compose build && docker compose up -d → via Direct Connect zu localhost:30120 verbinden.

Voraussetzungen: Docker + Docker Compose, ein cfx-Lizenzschlüssel und eine oxmysql-Ressourcenkopie (in server-data/resources/[standalone]/oxmysql ablegen).

Ordnerstruktur

test-city/ ├─ docker-compose.yml ├─ fxserver/ │ ├─ Dockerfile │ └─ entrypoint.sh ├─ server-data/ │ ├─ server.cfg │ └─ resources/ │ ├─ [standalone]/oxmysql/ # oxmysql hier platzieren │ └─ custom/ # das zu testende Skript hier ablegen (z.B. myscript/) └─ .env

.env (Beispiel)

LICENSE_KEY=changeme_cfx_license_key MYSQL_DATABASE=fivem MYSQL_USER=fivem MYSQL_PASSWORD=fivempw MYSQL_ROOT_PASSWORD=rootpw FX_ARTIFACT_URL=https://runtime.fivem.net/artifacts/fivem/build_proot_linux/master/LATEST.tar.xz

docker-compose.yml

version: "3.9"

networks: testcity:

volumes: db_data:

services: db: image: mariadb:10.11 restart: unless-stopped environment:

      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
    command: >
      --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci
      --innodb_buffer_pool_size=256M

volumes:

• db_data:/var/lib/mysql

    networks: [testcity]

adminer: image: adminer:4 restart: unless-stopped ports:

• "8080:8080"

    networks: [testcity]
    depends_on: [db]

fxserver:

    build:

context: ./fxserver args:

        FX_ARTIFACT_URL: ${FX_ARTIFACT_URL}

restart: unless-stopped environment:

      LICENSE_KEY: ${LICENSE_KEY}
      MYSQL_DATABASE: ${MYSQL_DATABASE}
      MYSQL_USER: ${MYSQL_USER}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    depends_on: [db]
    networks: [testcity]

ports:

• "30120:30120/udp"
• "30120:30120/tcp"
• "40120:40120/tcp" # txAdmin (optional) volumes:
• ./server-data:/opt/fivem/server-data

Ausführen

cd test-city docker compose build docker compose up -d

Adminer unter http://localhost:8080 (Server: db, Benutzer: fivem, Passwort: fivempw)

FiveM-Client verbinden → Direct Connect: dein-docker-host:30120

---

Teil 2 — Skript-Abnahme-Checkliste (nicht überspringen)

Verwende dies jedes Mal. In deinen Tracker kopieren und Punkte abhaken.

A. Vorflug (vor der Installation)

• Quelltyp: Open Source / teilweise offen / nur Escrow.
• Abhängigkeiten aufgelistet: Framework (ESX/QBCore/QBOX), ox_lib, oxmysql, PolyZone usw.
• fxmanifest.lua: lua54 'yes', korrektes game 'gta5', fx_version nicht veraltet.
• Dokumentation: Installationsschritte, Konfigurationsbeispiele, Berechtigungen, Locales, bekannte Konflikte.
• Lizenz/AGB: Nutzungsrechte, Rückerstattungsrichtlinie, Updates, Support-Kanal.

B. Installierbarkeit

• Keine Konsolenfehler bei ensure: Null Stack-Traces oder fehlende Asset-Spam.
• Kein deprecated natives-Spam.
• Konfiguration lädt sauber: Keine JSON/Lua-Syntaxfehler.
• DB-Migrationen: Tabellen einmal erstellen; Neustarts wenden sie nicht erneut an oder brechen sie.

C. Funktionalität

• Kernflows funktionieren: Happy Path getestet (z.B. Kauf, Job-Flow, Crafting).
• Edge Cases: Falsche Eingaben, fehlende Berechtigungen, außerhalb des Bereichs liegende Mengen.
• Lokalisierung: Keine hardcodierten Strings wenn Locales versprochen.
• Berechtigungen: Staff/Admin-Commands gesperrt; kein freier Client-seitiger Zugang.

D. Performance (Client & Server)

• resmon: Im Leerlauf ≤ 0,10ms, aktiv ≤ 0,50ms (Client).
• Server-Tick-Gesundheit: keine langen Ruckwarnungen bei normaler Nutzung.
• DB-Abfragen: Keine engen Schleifen; Prepared Statements verwendet; minimales N+1.

E. Sicherheit

• Server-seitige Validierung: Jedes Server-Event validiert source, Berechtigungen und Eingabetypen.
• Kein Vertrauen in den Client: Geld/Inventar-Änderungen nur aus Server-Logik.
• Kein eval/loadstring/remote code-Muster.
• Anti-Missbrauch: Rate Limits/Drosselung bei spam-anfälligen Endpunkten.
• Escrow-Integrität: Keine Backdoors in Nicht-Escrow-Konfigurationsloadern.

Gutes Event-Muster (Beispiel):

RegisterNetEvent('myscript:buy', function(item, amount)
  local src = source
  if type(item) ~= 'string' or type(amount) ~= 'number' or amount < 1 then return end
  if not HasPermission(src, 'shop.buy') then return end
  local xPlayer = GetPlayer(src) -- Framework-Adapter
  if not xPlayer then return end
  -- Preis server-seitig validieren, Inventarlimits prüfen, DB in einer Transaktion
end)

F. Kompatibilität & Sauberkeit

• Framework-Adapter vorhanden (ESX/QBCore/QBOX) oder klar als nicht unterstützt deklariert.
• Kein Globals-Leak, eindeutige Event-Namen, keine Ressourcennamen-Annahmen.
• Deinstallation sauber: Das Entfernen der Ressource bricht keine anderen.

---

Teil 3 — Quantitatives Risiko-Scoring-Modell (0–100)

Verwende dies, um „Einführen/Zurückhalten/Ablehnen" zu entscheiden. Niedriger ist besser.

Faktor

Gewichtung

Wie zu bewerten (0=gut → 5=schlecht)

Performance

0,20

resmon im Leerlauf: 0=≤0,10ms, 1=≤0,20, 3=≤0,50, 5=>0,50; Spitzen +1

Sicherheit

0,25

0=alle server-validiert + Rate Limits; 3=einige Lücken; 5=vertraut Client / unsichere Events

Stabilität

0,15

0=keine Fehler; 3=gelegentliche Warnungen; 5=häufige Fehler/Ruckler

Kompatibilität

0,10

0=Adapter/Tests; 3=nur ein Framework; 5=bricht häufige Abhängigkeiten

Wartbarkeit

0,10

0=Dokumentation/Changelog/semantische Versionen; 5=keine Dokumentation/aufgegeben

Lieferkette/Vendor

0,20

0=seriös, Verlauf, Rückerstattungen; 5=unbekannt, keine Richtlinie

Formel

RisikoScore = 100 * Σ(Gewichtung_i * (Bewertung_i / 5))

Bänder & Aktionen

• 0–24 (Niedrig): In Staging einführen, überwachen.
• 25–49 (Moderat): Fixes erforderlich vor Live.
• 50–74 (Hoch): Zurückhalten; Vendor-Patches anfordern oder ersetzen.
• 75–100 (Kritisch): Ablehnen.

---

Teil 4 — Vendor-Prüf-Rubrik (jedes 0–5 bewerten, höher ist besser)

Kriterium

Was „Gut" aussieht

Hinweise

Identität & Verlauf

Klare Marke, jahrelang aktiv, konsistentes Handle

Burner-Stores meiden

Dokumentation

Installation + Konfiguration + Berechtigungen + Fehlerbehebung

Screenshots/GIFs helfen

Update-Kadenz

Changelog, semantische Versionen, aktuelle Commits/Releases

Quartalsweise+ ist in Ordnung

Support-Qualität

Ticket/Discord-SLAs, reproduzierbare Fixes, nicht nur „neu starten"

Beispiel-Antworten prüfen

Issue-Transparenz

Öffentliche bekannte Probleme & Roadmap

Ehrlichkeit > Perfektion

Rückerstattung/AGB-Klarheit

Rückerstattungszeitraum, Bedingungen, Lizenzbedingungen

Keine Dark Patterns

Test-Nachweis

Staging-Video, Performance-Metriken, Framework-Liste

Noch besser: Demo-Server

Sicherheits-Hygiene

Erwähnt server-seitige Prüfungen, keine sensiblen Schlüssel, kein eval

Nach Audits fragen

Kompatibilitätsrichtlinie

ESX/QBCore/QBOX angegeben, Adapter, Versionsmatrix

Unterstützte Builds angeben

Preis & Wert

Fair für Komplexität, keine Abhängigkeits-Paywalls

Upsell-Fallen beachten

Rubrik-Score (0–50):

• 40–50: Stark — bevorzugter Vendor
• 30–39: Akzeptabel — überwachen
• 20–29: Schwach — vorsichtig vorgehen
• <20: Vermeiden

Profi-Tipp: Querverweise mit seriösen Marktplätzen. Beginne hier: Beste Tebex-Shops.

---

Teil 5 — Wartungs-Playbook (nach der Einführung)

1. Versions-Pinning: Script-Releases + Abhängigkeitsversionen sperren (z.B. oxmysql, ox_lib).
2. Staging zuerst: Alle Updates landen in Test City; Abnahme-Checkliste erneut durchführen.
3. Backups & Rollback: DB-Snapshot + Ressourcendateien vor jedem Update. Eine Rollback.md mit genauen Schritten führen.
4. CI-Smoke-Test (optional, empfohlen): Headless-Client-Verbindung + Command-Makro für Hauptflows; Server-Konsole auf Fehler parsen.
5. Betriebsmetriken: Ein einfaches Ledger pro Skript führen: durchschnittliches resmon (Leerlauf/aktiv), Fehleranzahl/Session, Vorfallsnotizen.
6. Changelog-Disziplin: Vendor-Changelogs einfordern; eigene Integrationsnotizen pflegen.
7. Geplante Events de-risken: Außerhalb der Stoßzeiten aktualisieren; Wartungsfenster ankündigen.

---

Teil 6 — Kopierbare Vorlagen

A. Testplan (pro Skript)

# Skript-Testplan — <Name> <Version>

Kontext

Framework(s): ESX/QBCore/QBOX Abhängigkeiten: oxmysql vX, ox_lib vY, PolyZone vZ DB-Migrationen: ja/nein Escrow: ja/nein

Funktionale Tests

• [ ] Test 1:
• [ ] Test 2:
• [ ] Negativ 1:

Performance

resmon Leerlauf: ____ ms resmon aktiv: ____ ms (Szenario: ______)

Sicherheitsprüfungen

• [ ] Alle Server-Events validieren Source/Berechtigung/Eingabe
• [ ] Rate Limits vorhanden
• [ ] Keine client-vertrauten Geld/Inventar-Mutationen

Logs & Fehler

Snippet einfügen (Server + F8):

Ergebnis

Bestanden/Fehlgeschlagen + Notizen

B. Rollback.md (Gerüst)

# Rollback — <Datum> <Skript> <Von→Nach>

1. Skript deaktivieren: stop <resource>
2. Ressourcendateien aus Backup wiederherstellen: <Pfad>
3. DB-Snapshot wiederherstellen: <Pfad/Befehl>
4. FXServer neu starten
5. Verifizieren: Konsole sauber, Performance normal, Flows ok

C. Issue-Vorlage

Zusammenfassung Was passiert ist vs. erwartet, mit Zeitstempeln.

Reproduktionsschritte

1. ...
2. ...

Umgebung Artifact-Build: Framework & Versionen: Skript-Version: Andere Abhängigkeiten:

Logs Server-Konsole: F8:

Anhänge Screenshots/Video wenn möglich.

---

Wie man diesen Guide effizient nutzt

1. Test City einmal aufsetzen, sauber halten.
2. Für jedes Kandidatenskript:
   • In resources/custom/ ablegen, in server.cfg aktivieren.
   • Die Abnahme-Checkliste durchführen.
   • Den Risiko-Score berechnen.
   • Den Anbieter mit der Vendor-Rubrik prüfen.
   • Falls es besteht, in Staging zusammenführen; falls nicht, Fixes anfordern oder aufgeben.

---

Mehr Test-Guides benötigt? Schau dir den Abschnitt in unserer umfassenden FiveM-Skripte-Ressource an.