Zum Inhalt springen
RPScripts

FiveM Frameworks im Vergleich: ESX, QBCore und Qbox

Von Luke

FiveM Frameworks: QBCore vs. ESX
Es gibt keinen offiziellen universellen Gewinner zwischen ESX, QBCore und Qbox. Wähle das Framework, dessen aktuelles Rezept, APIs und kompatible Ressourcen deine erforderlichen Serverfunktionen, vorhandenen Daten und Teamfähigkeiten abdecken. Wenn du bereits einen stabilen Framework-spezifischen Stack betreibst, ist es normalerweise die erste Option, in diesem Ökosystem zu bleiben, da eine Migration mehr als nur den Kernordner betrifft.

Schnelle Entscheidungsanleitung

Ausgangspunkt Erstes zu bewertendes Framework Grund zur Überprüfung
Bestehender ESX-Server ESX Legacy Bewahrt ESX-spezifische Daten, Ereignisse, Exporte und Ressourcenkenntnisse, wenn die aktuellen Anforderungen noch erfüllt sind.
Bestehender QBCore-Server QBCore Vermeidet Konvertierung, es sei denn, ein anderes Framework löst eine dokumentierte Anforderung, die dies rechtfertigt.
Neuer QB-orientierter Build QBCore oder Qbox Vergleiche die beiden offiziellen Rezepte, ausgewählte Ressourcen, das API-Modell und die exakte Drittanbieter-Kompatibilität.
QBCore-Team erwägt Qbox Qbox mit Bridge-Audit Die QB-Bridge hilft vielen Ressourcen, aber dokumentierte Ausnahmen erfordern immer noch Überprüfungen auf Ressourcenebene.
Keine Rollenspiel-Framework-Anforderung Standalone-Ressourcen Standalone beschreibt ein Abhängigkeitsmuster; prüfe, ob ein vollständiges Framework tatsächlich unnötig ist.

Was ein FiveM-Framework leistet

Cfx.re describes frameworks as foundations that make it easier to build server resources. A roleplay framework usually establishes shared patterns for player and character data, jobs, items, money, commands, permissions and communication between resources. The exact features visible to players depend on the complete recipe and installed resources, not only on the core framework name. This distinction prevents a misleading comparison. Inventory, housing, phones, banking or vehicle systems can be separate resources and can be replaced. A checkmark beside a framework name does not prove which implementation, version or integration a production server will run.

ESX Legacy

ESX Legacy is an open-source roleplay framework with its current core published by the official ESX organization. The official new-server tutorial uses the ESX Legacy txAdmin template. The manual installation documents oxmysql, spawnmanager, database import, core and addon resources, exclusions and start order. ESX is the first option to evaluate when an existing server already has ESX-specific player data, resources and team procedures. That is a migration-risk observation, not a market-share claim. For a new build, inspect the current recipe and verify that each required product supports the exact ESX version, inventory, database library, exports and events.

QBCore

QBCores offizielle Kernressource qb-core exposes a Core Object with functions, player data, shared data, configuration and commands. Shared definitions include jobs, gangs, items and vehicles. The official Windows install uses the QBCore Framework popular recipe in txAdmin, and the recipe deploys a database and wider resource set rather than only the core folder. QBCore is a candidate for a new or existing QB ecosystem build when its documented APIs and compatible resources cover the server requirements. Do not infer that every resource carrying a QBCore label supports every core version or replacement inventory. Record required exports, dependencies, SQL and start order for the exact stack.

Qbox

The official Qbox introduction records that Qbox began in 2022 from QBCore and now has its own core APIs and resources. Qbox maintains a QB compatibility bridge for many properly written QBCore resources. Its documentation also names exceptions, including resources that depend on direct database access, internal core files or unsupported behavior. The official Qbox installation uses a QBox popular recipe in txAdmin. For a QBCore migration, the conversion guide covers configuration differences, numeric job and gang grades, inventory and database conversion, and incremental API replacement. Qbox is therefore a deliberate framework choice with a compatibility audit, not simply a switch that makes every QBCore script work unchanged.

Vergleichsdimensionen, die du überprüfen kannst

Dimension Frage Beweis
Installationspfad Gibt es ein aktuelles offizielles Rezept und eine vollständige Dokumentation? Offizielle Dokumente und Rezept-Repository zum Zeitpunkt der Überprüfung.
Erforderliche Ressourcen Welche Datenbank und Bibliothek, welches Inventar und welche unterstützenden Ressourcen sind ausgewählt? Rezeptdateien, Manifeste und Abhängigkeitsdeklarationen.
API-Kompatibilität Welche Exporte, Ereignisse, Objekte und Datenfelder rufen die erforderlichen Skripte auf? Ressourcenquelle, Manifeste und offizielle API-Dokumentation.
Datenmodell Welche Identifikatoren, Ränge, Konten und Beziehungen müssen erhalten bleiben? Schema-Inventar und getestete Migrationszuordnung.
Betrieb Kann das Team den Stack aktualisieren, diagnostizieren und zurücksetzen? Betriebsanleitungen, Backups und eine Wiederherstellungsübung auf Staging.
Leistung Wie verhält sich der genaue Stack unter repräsentativen Aktionen? Profiler, Resmon und Datenbankprotokolle aus wiederholten kontrollierten Tests.

Entscheidungs-Checkliste

  1. Liste die benötigten Funktionen für Spieler auf. Benenne die genauen Anforderungen an Jobs, Wirtschaft, Inventar, Wohnen, Telefon, Fahrzeug, Verwaltung und Integration.
  2. Vorhandene Abhängigkeiten inventarisieren. Framework-Versionen, Manifeste, Datenbanktabellen, Exporte, Ereignisse und benutzerdefinierte Kernänderungen aufzeichnen.
  3. Ressourcenunterstützung abbilden. Bestätige für jede erforderliche Ressource das Framework und die Version, die sie tatsächlich unterstützt, einschließlich Brücken und Ersatzsysteme.
  4. Überprüfe das Teamwissen. Berücksichtige die APIs, Sprachen, das Datenbankmodell und die Betriebswerkzeuge, mit denen die Verantwortlichen Fehler diagnostizieren können.
  5. Schätze die Migration anhand von Beweisen ab. Zähle die realen Datendomänen und Integrationen; verwende keine generische Stunden- oder Kostentabelle.
  6. Baue einen repräsentativen Test-Stack auf. Verwende das offizielle Rezept, ausgewählte Ressourcen und eine bereinigte Kopie realistischer Daten.
  7. Definiere Akzeptanz und Rollback. Entscheide, was funktionieren muss und wie die vorherigen konsistenten Dateien und die Datenbank wiederhergestellt werden können.

Migration betrifft das gesamte Servermodell

Changing frameworks can involve identities, characters, money, jobs, gangs, inventory, vehicles, garages, housing, phones, banking, society accounts, permissions and custom events. Data relationships matter: creating a new character identifier without mapping all related records can orphan assets or permissions. Do not run a generic conversion SQL snippet against production. Begin with a schema and resource inventory, design an idempotent conversion against a test copy, validate record counts and relationships, and rehearse the rollback. Framework-specific scripts may need an official bridge, a documented multi-framework mode or code changes. ESX scripts are not automatically portable to QBCore or Qbox, and the Qbox QB bridge is not universal.

So benchmarkst du deinen eigenen Stack

Wenn Leistung die Wahl beeinflusst, vergleiche kontrollierte Testaufbauten, statt eine Rangliste zu wiederholen. Verwende denselben Host oder isolierte gleichwertige Hardware, dasselbe FXServer-Artefakt, dieselbe Datenbankversion, dasselbe Datenvolumen und dieselben repräsentativen Spieleraktionen. Halte die Ressourcen funktional vergleichbar und dokumentiere jeden beabsichtigten Unterschied.
  1. Wärme jeden Server konsistent auf und erfasse das Leerlaufverhalten.
  2. Wiederhole dieselben Vorgänge zum Laden von Charakteren sowie dieselben Inventar-, Job-, Fahrzeug- und Wirtschaftsaktionen.
  3. Sammle FiveM Profiler- oder Resmon-Beweise sowie Datenbank-Slow-Query- und Systemmetriken.
  4. Führe mehrere Stichproben durch und berichte Verteilungen oder Bereiche, nicht eine einzelne Bestzahl.
  5. Überprüfe Fehler, Datenkorrektheit und Wiederverbindungsverhalten zusammen mit dem Timing.
  6. Behalte die Konfiguration und die Rohprotokolle, damit ein anderer Prüfer die Schlussfolgerung reproduzieren kann.
Ein Benchmark eines Kerns mit verschiedenen Ressourcen isoliert das Framework nicht. Ein Ergebnis von einem synthetischen leeren Server beweist nicht die Produktionskapazität. Veröffentliche nur Schlussfolgerungen, die durch die aufgezeichnete Einrichtung und die Rohdaten gestützt werden.

Praktische Empfehlung

  • Wähle ESX wenn die aktuellen ESX-Ressourcen, Daten und das Teamwissen die Anforderungen am besten erfüllen und eine Migration keinen erwiesenen Nutzen hat.
  • Wähle QBCore wenn das offizielle QB-Rezept und das dokumentierte Ökosystem zu einem neuen Build oder einem bestehenden QB-Server passen.
  • Wähle Qbox wenn das Team bewusst das aktuelle Rezept und die APIs von Qbox einsetzen möchte und eine Prüfung der QB-Bridge oder der Migration durchführen kann.
Öffne die dedizierten Framework-Anleitungen für die aktuelle offizielle Installations- und Kompatibilitätsgrenze. Gleiche dann kommerzielle Ressourcen mit dem exakt gewählten Stack ab, anstatt ein breites Kategorielabel als endgültigen Beweis zu behandeln.

Detaillierte Framework-Anleitungen

Weiterführende Details zur Installation und zu den Kompatibilitätsgrenzen von ESX Legacy, QBCore oder dem Qbox und Ox Stack.

Referenzdokumentation

Cfx.re — Frameworks · Quelle: docs.qbox.re · Quelle: qbcore-fivem/qb-core · Quelle: esx-framework/esx_core

Premium-Empfehlungen für deinen Server

Zum Shop