ESX Legacy, QBCore oder Qbox? Der Vergleich zeigt Unterschiede in Aufbau, Script-Angebot, Datenbank und Performance und hilft bei der Wahl für neue Server.
Bei ESX vs QBCore geht es weniger um besser oder schlechter als um Herkunft und Bauweise. ESX Legacy ist das ältere Framework mit dem größten Bestand an Scripts. QBCore ist jünger, einheitlicher aufgebaut und bringt viele aufeinander abgestimmte Basis-Ressourcen mit. Wer heute einen neuen Roleplay-Server startet, sollte außerdem Qbox kennen, einen modernisierten Ableger von QBCore.
Dieser Vergleich ergänzt die technische Einrichtung eines FiveM-Servers. Wie du txAdmin, die server.cfg und die Ports aufsetzt, steht in der Anleitung FiveM Server erstellen mit txAdmin und server.cfg. Hier geht es um die Frage, die danach kommt: Welches Framework legst du darauf?
FiveM selbst liefert nur die Multiplayer-Basis für GTA V. Alles, was einen Roleplay-Server ausmacht, also Charaktere, Geld, Jobs, Inventar und Fahrzeugbesitz, kommt aus einem Framework. Es speichert Spielerdaten in einer Datenbank und stellt anderen Scripts Funktionen bereit, etwa um einem Spieler Geld zu geben oder seinen Job abzufragen.
Das ist der entscheidende Punkt: Fast jedes weitere Script, das du installierst, spricht direkt mit dem Framework. Deine Wahl bestimmt also, welche Scripts ohne Anpassung laufen. Genau deshalb ist die Entscheidung später so schwer rückgängig zu machen.
ESX (ursprünglich es_extended) ist eines der ersten großen FiveM-Frameworks und prägte über Jahre die deutschsprachige Roleplay-Szene. Die alten Versionen wurden irgendwann nicht mehr gepflegt, Ableger verschiedener Gruppen entstanden. ESX Legacy ist die heute aktiv weiterentwickelte Linie, die den alten Code aufgeräumt und modernisiert hat. Wenn heute jemand ESX empfiehlt, ist in aller Regel Legacy gemeint.
QBCore kam deutlich später und wurde von Anfang an als zusammenhängender Baukasten gedacht. Zum Kern gehören viele Ressourcen mit dem Präfix qb-, etwa für Charakterauswahl, Garagen, Telefon oder Jobs. Die Bausteine sind aufeinander abgestimmt, was den Einstieg für viele einfacher wirkt.
Qbox ist ein Fork von QBCore. Das Projekt setzt stark auf Bibliotheken aus dem Overextended-Umfeld wie ox_lib, ox_inventory und ox_target und hat viel internen Code neu geschrieben. Wichtig für die Praxis: Qbox bringt eine Kompatibilitätsschicht mit, über die viele QBCore-Scripts weiterlaufen.
Am schnellsten siehst du den Unterschied, wenn du dir anschaust, wie ein Script einem Spieler Geld aufs Konto bucht. Bei ESX Legacy:
local ESX = exports['es_extended']:getSharedObject()
local xPlayer = ESX.GetPlayerFromId(source)
xPlayer.addAccountMoney('bank', 500)
print(xPlayer.getJob().name)Bei QBCore sieht dasselbe so aus:
local QBCore = exports['qb-core']:GetCoreObject()
local Player = QBCore.Functions.GetPlayer(source)
Player.Functions.AddMoney('bank', 500)
print(Player.PlayerData.job.name)Und bei Qbox, das direkte Exports bevorzugt:
local player = exports.qbx_core:GetPlayer(source)
player.Functions.AddMoney('bank', 500)Die Logik ist überall ähnlich, die Funktionsnamen und Datenstrukturen aber nicht. Ein ESX-Script, das xPlayer.addAccountMoney aufruft, findet unter QBCore schlicht nichts. Daraus ergibt sich die wichtigste Erkenntnis dieses Vergleichs: Du entscheidest dich nicht für ein Framework, sondern für ein Ökosystem aus Scripts, das daran hängt.
Ein zweiter struktureller Unterschied betrifft Jobs. ESX legt Jobs und Rangstufen klassisch in Datenbanktabellen ab (jobs und job_grades). QBCore und Qbox definieren sie in einer Lua-Datei im Framework, etwa shared/jobs.lua. Das eine ist bequem per SQL zu pflegen, das andere gut versionierbar, wenn du deinen Server mit Git verwaltest.
ESX hat durch sein Alter den größten Bestand an Scripts, kostenlos wie kommerziell. Der Haken: Ein großer Teil davon wurde für alte ESX-Versionen geschrieben. Solche Scripts nutzen teils veraltete Aufrufe wie TriggerEvent('esx:getSharedObject', ...) oder das frühere mysql-async und brauchen Nacharbeit, bevor sie sauber unter Legacy laufen.
Bei QBCore ist das Angebot kleiner, aber im Schnitt jünger. Viele aktuelle kommerzielle Scripts unterstützen inzwischen mehrere Frameworks und schalten per Konfiguration um, typischerweise so:
Config.Framework = 'qb' -- oder 'esx' oder 'qbx'Ein praktischer Prüfpunkt vor jedem Download: Schau in die fxmanifest.lua und die Abhängigkeiten. Stehen dort es_extended, qb-core oder qbx_core? Und wann wurde zuletzt etwas geändert? Ein Script, das seit Jahren nicht angefasst wurde, ist bei jedem Framework ein Risiko. Wie du Ressourcen auf einen gehosteten Server bringst, beschreibt der Hilfeartikel zu Mods, Plugins und Dateien auf dem Game-Server.
In einem Punkt sind sich die drei Frameworks heute einig: Sie arbeiten mit MySQL beziehungsweise MariaDB und nutzen oxmysql als Verbindungsressource. Die Verbindung steht in der server.cfg:
set mysql_connection_string "mysql://fivem:geheim@127.0.0.1/fivem_rp?charset=utf8mb4"
ensure oxmysqloxmysql muss vor dem Framework starten, sonst findet das Framework beim Hochfahren keine Datenbank. Der Zeichensatz utf8mb4 verhindert, dass Umlaute oder Emojis in Charakternamen zu Fehlern führen.
Unterschiedlich ist das Tabellenschema. ESX speichert Spieler in der Tabelle users, verknüpft über einen Identifier. QBCore und Qbox nutzen die Tabelle players mit einer citizenid und legen Geld, Charakterinfos, Job und Metadaten als JSON-Spalten ab. Beides funktioniert, ist aber nicht zueinander kompatibel. Genau das macht später den Umstieg zwischen ESX und QBCore aufwendig.
Diese Frage taucht in jedem Forum auf, und die ehrliche Antwort lautet: Das Framework selbst ist selten der Flaschenhals. Ein sauber aufgesetzter ESX-Legacy-Server und ein QBCore-Server liegen im Grundzustand nah beieinander. Ruckler, Desync und hohe Serverlast entstehen fast immer durch einzelne Scripts.
Typische Ursachen sind Schleifen, die in jedem Frame laufen (Wait(0)), obwohl ein Spieler gar nicht in der Nähe ist, oder Scripts, die bei jeder Aktion die Datenbank abfragen, statt Daten zwischenzuspeichern. Prüfen kannst du das direkt im Spiel über die F8-Konsole:
resmon 1Der Ressourcenmonitor zeigt die CPU-Zeit pro Script. Als Faustregel gilt: Was im Leerlauf dauerhaft deutlich über 0,1 ms liegt, solltest du dir genauer ansehen. Qbox hat hier einen kleinen strukturellen Vorteil, weil viele Teile auf den gut optimierten ox-Ressourcen aufbauen. Ein schlecht geschriebenes Zusatzscript macht diesen Vorteil aber schnell wieder zunichte.
Für einen Neustart ohne Altlasten hilft diese grobe Orientierung:
Ein guter Test vor der Entscheidung: Schreib die fünf bis zehn Scripts auf, die für dein Konzept unverzichtbar sind, etwa Inventar, Telefon, Garagen und Polizei-MDT. Prüfe für jedes, welche Frameworks es unterstützt. Oft ist die Entscheidung danach schon gefallen.
Praktisch für den Einstieg: txAdmin bietet beim ersten Einrichten fertige Rezepte für ESX Legacy und QBCore an, Qbox stellt ein eigenes Rezept bereit. Das Rezept lädt Framework und Basis-Ressourcen herunter und legt die Datenbank an. Für einen ersten Testserver ist das deutlich schneller als jede manuelle Installation.
Einen Knopf zum Umschalten gibt es nicht. Wie aufwendig der Wechsel ist, hängt stark von der Richtung ab:
Wenn du wechselst, geh in dieser Reihenfolge vor:
mysqldump -u fivem -p fivem_rp > vor_wechsel.sql, und zusätzlich den Ressourcenordner.Vor dem ersten Schritt lohnt ein zusätzlicher Snapshot des ganzen Servers. Wie das bei einem eigenen Server funktioniert, steht im Artikel zu Backups deines Servers erstellen und wiederherstellen.
Alle drei Frameworks laufen auf jedem FiveM-Server, egal ob verwaltet oder selbst aufgesetzt. Bei Hostleaf gibt es beide Wege: Du kannst einen FiveM Server mieten und ihn über Konsole und Dateimanager im Panel verwalten, oder du richtest alles selbst auf einem Root Server mit eigenem KVM-Kernel ein, inklusive eigener MariaDB. Die Rechenzentren stehen in Deutschland und den Niederlanden, netzwerkseitiger DDoS-Schutz ist standardmäßig aktiv. Welches Framework du darauf nutzt, bleibt deine Entscheidung.
Nicht direkt. ESX-Scripts rufen Funktionen wie ESX.GetPlayerFromId auf, die es in QBCore nicht gibt. Du musst sie entweder umschreiben oder eine Version suchen, die mehrere Frameworks unterstützt.
Nein. Qbox ist ein Fork von QBCore mit überarbeitetem Code und starker Bindung an die ox-Ressourcen. Über eine Kompatibilitätsschicht laufen aber viele QBCore-Scripts auch unter Qbox.
Mit den txAdmin-Rezepten ist die Installation bei allen dreien ähnlich schnell. QBCore und Qbox wirken für viele zugänglicher, weil die Basis-Ressourcen zusammenpassen. ESX lohnt sich, wenn du gezielt auf dessen großes Script-Angebot zugreifen willst.
Ja, beide benötigen MySQL oder MariaDB, angebunden über oxmysql. Nutze pro Server und Framework eine eigene Datenbank, weil die Tabellenschemata nicht miteinander kompatibel sind.
Vom Lizenzschlüssel bis zum ersten Connect: So erstellst du einen FiveM-Server auf Linux mit txAdmin, konfigurierst die server.cfg und vermeidest typische Startfehler.
So richtest du einen Palworld Dedicated Server unter Linux ein: Hardware, SteamCMD, wichtige Einstellungen, Ports und geplante Neustarts gegen steigenden RAM.
Postfach anlegen, MX, SPF, DKIM und DMARC setzen, IMAP und SMTP im Mailprogramm eintragen: So landen Mails von deiner eigenen Domain im Posteingang statt im Spam.