Es gibt keinen offiziellen universellen Gewinner zwischen ESX, QBCore und Qbox. Wähle das Framework, dessen aktuelles Rezept, APIs und kompatible Ressourcen zu deinen erforderlichen Serverfunktionen, vorhandenen Daten und Teamfähigkeiten passen. Wenn du bereits einen stabilen frameworkspezifischen Stack betreibst, ist das Verbleiben in diesem Ökosystem normalerweise die erste zu bewertende Option, da die Migration mehr als den Kernordner betrifft.
Schnellentscheidungsleitfaden
| Ausgangspunkt | Erstes zu bewertendes Framework | Grund zur Überprüfung |
|---|---|---|
| Bestehender ESX-Server | ESX Legacy | Bewahrt ESX-spezifische Daten, Events, Exports und Ressourcenkenntnisse, solange die aktuellen Anforderungen noch erfüllt werden. |
| Bestehender QBCore-Server | QBCore | Vermeidet eine Umstellung, es sei denn, ein anderes Framework erfüllt eine dokumentierte Anforderung, die dies rechtfertigt. |
| Neuer QB-orientierter Build | QBCore oder Qbox | Vergleiche die beiden offiziellen Rezepte, ausgewählten Ressourcen, das API-Modell und die genaue Drittanbieter-Kompatibilität. |
| QBCore-Team, das Qbox in Betracht zieht | Qbox mit Bridge-Audit | Die QB-Bridge hilft vielen Ressourcen, aber dokumentierte Ausnahmen erfordern weiterhin Überprüfungen auf Ressourcenebene. |
| Keine Anforderung an ein Rollenspiel-Framework | Standalone-Ressourcen | Standalone beschreibt ein Abhängigkeitsmuster; bestätige, ob ein vollständiges Framework tatsächlich nicht erforderlich ist. |
Was ein FiveM-Framework macht
Cfx.re beschreibt Frameworks als Grundlagen, die den Aufbau von Serverressourcen erleichtern. Ein Rollenspiel-Framework etabliert in der Regel gemeinsame Muster für Spieler- und Characterdaten, Jobs, Items, Geld, Befehle, Berechtigungen und die Kommunikation zwischen Ressourcen. Die genauen für Spieler sichtbaren Funktionen hängen vom vollständigen Rezept und den installierten Ressourcen ab, nicht nur vom Namen des Kern-Frameworks.
Diese Unterscheidung verhindert einen irreführenden Vergleich. Inventar, Wohnungen, Telefone, Bank- oder Fahrzeugsysteme können separate Ressourcen sein und ersetzt werden. Ein Häkchen neben einem Framework-Namen beweist nicht, welche Implementierung, Version oder Integration ein Produktionsserver verwenden wird.
ESX Legacy
ESX Legacy ist ein Open-Source-Rollenspiel-Framework, dessen aktueller Kern von der offiziellen ESX-Organisation veröffentlicht wird. Das offizielle Tutorial für neue Server verwendet die ESX Legacy txAdmin-Vorlage. Die manuelle Installation dokumentiert oxmysql, spawnmanager, Datenbankimport, Kern- und Addon-Ressourcen, Ausschlüsse und Startreihenfolge.
ESX ist die erste zu bewertende Option, wenn ein bestehender Server bereits ESX-spezifische Spielerdaten, Ressourcen und Teamprozesse hat. Das ist eine Beobachtung zum Migrationsrisiko, keine Marktanteilsbehauptung. Für einen neuen Build überprüfe das aktuelle Rezept und stelle sicher, dass jedes erforderliche Produkt die genaue ESX-Version, das Inventar, die Datenbankbibliothek, Exports und Events unterstützt.
QBCore
Offizielles QBCore qb-core bietet ein Core-Objekt mit Funktionen, Spielerdaten, gemeinsamen Daten, Konfiguration und Befehlen. Gemeinsame Definitionen umfassen Jobs, Gangs, Gegenstände und Fahrzeuge. Die offizielle Windows-Installation verwendet das beliebte QBCore Framework-Rezept in txAdmin, und das Rezept stellt eine Datenbank und einen breiteren Ressourcensatz bereit, nicht nur den Core-Ordner.
QBCore ist ein Kandidat für den Aufbau eines neuen oder bestehenden QB-Ökosystems, wenn seine dokumentierten APIs und kompatiblen Ressourcen die Serveranforderungen abdecken. Es sollte nicht daraus geschlossen werden, dass jede Ressource mit einem QBCore-Label jede Core-Version oder Ersatzinventar unterstützt. Notiere die erforderlichen Exports, Abhängigkeiten, SQL und Startreihenfolge für den genauen Stack.
Qbox
Die offizielle Qbox-Einführung dokumentiert, dass Qbox 2022 aus QBCore hervorgegangen ist und nun über eigene Core-APIs und Ressourcen verfügt. Qbox unterhält eine QB-Kompatibilitätsbrücke für viele ordnungsgemäß geschriebene QBCore-Ressourcen. Die Dokumentation nennt auch Ausnahmen, darunter Ressourcen, die von direktem Datenbankzugriff, internen Core-Dateien oder nicht unterstütztem Verhalten abhängen.
Die offizielle Qbox-Installation verwendet ein QBox-Rezept in txAdmin. Für eine QBCore-Migration behandelt der Migrationsleitfaden Konfigurationsunterschiede, numerische Job- und Gang-Grades, Inventar- und Datenbankkonvertierung sowie schrittweisen API-Ersatz. Qbox ist daher eine bewusste Framework-Wahl mit einem Kompatibilitätsaudit, nicht einfach ein Schalter, der jedes QBCore-Skript unverändert funktionieren lässt.
Vergleichsdimensionen, die du überprüfen kannst
| Dimension | Frage | Nachweis |
|---|---|---|
| Installationspfad | Gibt es ein aktuelles offizielles Rezept und eine vollständige Dokumentation? | Offizielle Dokumentation und Rezept-Repository zum überprüften Datum. |
| Erforderliche Ressourcen | Welche Datenbank, Bibliothek, Inventar- und Support-Ressourcen sind ausgewählt? | Rezeptdateien, Manifeste und Abhängigkeitsdeklarationen. |
| API-Kompatibilität | Welche Exports, Events, Objekte und Datenfelder werden von den erforderlichen Skripten aufgerufen? | Ressourcenquelle, Manifeste und offizielle API-Dokumentation. |
| Datenmodell | Welche Identifikatoren, Grade, Konten und Beziehungen müssen erhalten bleiben? | Schema-Inventar und getestete Migrationszuordnung. |
| Betrieb | Kann das Team den Stack aktualisieren, diagnostizieren und zurücksetzen? | Runbooks, Backups und eine gestaffelte Wiederherstellungsübung. |
| Leistung | Wie verhält sich der genaue Stack unter repräsentativen Aktionen? | Profiler, Ressourcenmonitor und Datenbankprotokolle aus wiederholten kontrollierten Tests. |
Entscheidungscheckliste
- Listen Sie die erforderlichen Spielerfunktionen auf. Nenne die genauen Anforderungen an Jobs, Wirtschaft, Inventar, Wohnung, Telefon, Fahrzeug, Verwaltung und Integration.
- Bestehende Abhängigkeiten des Inventars. Framework-Versionen, Manifestdateien, Datenbanktabellen, Exporte, Events und benutzerdefinierte Core-Änderungen erfassen.
- Ressourcenunterstützung zuordnen. Bestätige für jede erforderliche Ressource, welches Framework und welche Version sie tatsächlich unterstützt, einschließlich Bridges und Ersatzsysteme.
- Team-Wissen überprüfen. Die APIs, Sprachen, das Datenbankmodell und die Betriebswerkzeuge einbeziehen, die die Betreuer diagnostizieren können.
- Migration anhand von Belegen schätzen. Die tatsächlichen Datenbereiche und Integrationen zählen; verwende keine generische Stunden- oder Kostentabelle.
- Einen repräsentativen Test-Stack aufbauen. Das offizielle Rezept, ausgewählte Ressourcen und eine bereinigte Kopie realistischer Daten verwenden.
- Akzeptanz und Rollback definieren. Entscheide, was funktionieren muss und wie die vorherigen konsistenten Dateien und die Datenbank wiederhergestellt werden.
Migration betrifft das gesamte Servermodell.
Der Wechsel von Frameworks kann Identitäten, Charaktere, Geld, Jobs, Gangs, Inventar, Fahrzeuge, Garagen, Wohnungen, Telefone, Bankwesen, Gesellschaftskonten, Berechtigungen und benutzerdefinierte Events betreffen. Datenbeziehungen sind wichtig: Das Erstellen einer neuen Charakterkennung ohne Zuordnung aller zugehörigen Datensätze kann zu verwaisten Assets oder Berechtigungen führen.
Führe kein generisches SQL-Konvertierungssnippet gegen die Produktion aus. Beginne mit einem Schema- und Ressourceninventar, entwerfe eine idempotente Konvertierung gegen eine Testkopie, validiere Datensatzanzahlen und Beziehungen und proben das Rollback. Frameworkspezifische Skripte benötigen möglicherweise eine offizielle Bridge, einen dokumentierten Multi-Framework-Modus oder Codeänderungen. ESX-Skripte sind nicht automatisch auf QBCore oder Qbox portierbar, und die Qbox QB-Bridge ist nicht universell.
So benchmarkst du deinen eigenen Stack
Wenn die Leistung die Wahl beeinflusst, vergleiche kontrollierte Builds, anstatt eine Rangliste zu wiederholen. Verwende denselben Host oder eine isolierte äquivalente Hardware, FXServer-Artifact, Datenbankversion, Datenmenge und repräsentative Spieleraktionen. Halte den Ressourcensatz funktional vergleichbar und gib jede beabsichtigte Abweichung an.
- Wärme jeden Server konsistent auf und erfasse das Leerlaufverhalten.
- Wiederhole dieselben Charakterlade-, Inventar-, Job-, Fahrzeug- und Wirtschaftsaktionen.
- Sammle FiveM-Profiler- oder Resmon-Nachweise sowie Datenbank-Langsamabfragen und Systemmetriken.
- Führe mehrere Stichproben durch und berichte Verteilungen oder Bereiche, nicht eine einzelne beste Zahl.
- Überprüfe Fehler, Datenkorrektheit und Wiederverbindungsverhalten zusammen mit der Zeitmessung.
- Behalte die Konfiguration und die Rohprotokolle, damit ein anderer Prüfer die Schlussfolgerung reproduzieren kann.
Ein Benchmark eines Kerns mit unterschiedlichen Ressourcen isoliert das Framework nicht. Ein Ergebnis von einem synthetischen leeren Server beweist keine Produktionskapazität. Veröffentliche nur Schlussfolgerungen, die durch den aufgezeichneten Aufbau und die Rohdaten gestützt werden.
Praktische Empfehlung
- Wähle ESX wenn aktuelle ESX-Ressourcen, Daten und Team-Wissen die Anforderungen am besten erfüllen und die Migration keinen nachgewiesenen 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 Qbox’s aktuelles Rezept und APIs möchte und eine QB-Bridge- oder Migrationsaudit durchführen kann.
Öffne die dedizierten Framework-Anleitungen für die aktuelle offizielle Installation und Kompatibilitätsgrenze. Ordne dann kommerzielle Ressourcen dem exakt gewählten Stack zu, anstatt eine breite Kategoriebezeichnung als endgültigen Beweis zu behandeln.
Detaillierte Framework-Anleitungen
Fahre mit der genauen Installation und Kompatibilitätsgrenze für ESX Legacy, QBCore oder das Qbox- und Ox-Stack.
