Nie ma oficjalnego uniwersalnego zwycięzcy między ESX, QBCore i Qbox. Wybierz framework, którego aktualne przepisy, APIs i kompatybilne zasoby odpowiadają wymaganym funkcjom serwera, istniejącym danym i umiejętnościom zespołu. Jeśli już prowadzisz stabilny stos specyficzny dla frameworka, pozostanie w tym ekosystemie jest zazwyczaj pierwszą opcją do oceny, ponieważ migracja dotyczy więcej niż tylko folderu rdzeniowego.
Szybki przewodnik decyzyjny
| Punkt wyjścia | Pierwszy framework do oceny | Powód do weryfikacji |
|---|---|---|
| Istniejący serwer ESX | ESX Legacy | Zachowuje dane, zdarzenia, eksporty i wiedzę o zasobach specyficznych dla ESX, gdy aktualne wymagania są nadal spełnione. |
| Istniejący serwer QBCore | QBCore | Unika konwersji, chyba że inny framework rozwiązuje udokumentowany wymóg, który to uzasadnia. |
| Nowa wersja zorientowana na QB | QBCore lub Qbox | Porównaj dwa oficjalne przepisy, wybrane zasoby, model API i dokładną zgodność z oprogramowaniem stron trzecich. |
| Zespół QBCore rozważa Qbox | Qbox z audytem mostu | Most QB pomaga wielu zasobom, ale udokumentowane wyjątki nadal wymagają kontroli na poziomie zasobu. |
| Brak wymogu frameworka roleplay | Zasoby Standalone | Standalone opisuje wzorzec zależności; potwierdź, czy pełny framework jest faktycznie niepotrzebny. |
Co robi framework FiveM
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
QBCore’s official 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.
Comparison dimensions you can verify
| Wymiar | Pytanie | Dowody |
|---|---|---|
| Ścieżka instalacji | Czy istnieje aktualny oficjalny przepis i kompletna dokumentacja? | Oficjalne dokumenty i repozytorium przepisów z daty przeglądu. |
| Wymagane zasoby | Jakie zasoby bazy danych, biblioteki, ekwipunku i wsparcia są wybrane? | Pliki przepisu, manifesty i deklaracje zależności. |
| Kompatybilność z API | Które eksporty, zdarzenia, obiekty i pola danych są wywoływane przez wymagane skrypty? | Źródło zasobu, manifesty i oficjalna dokumentacja API. |
| Model danych | Jakie identyfikatory, stopnie, konta i relacje muszą zostać zachowane? | Inwentaryzacja schematu i przetestowane mapowanie migracji. |
| Operacje | Czy zespół potrafi aktualizować, diagnozować i wycofywać stos? | Runbooki, kopie zapasowe i ćwiczenie etapowego odzyskiwania. |
| Wydajność | Jak dokładnie stos zachowuje się podczas reprezentatywnych akcji? | Profiler, resmon i logi bazy danych z powtarzanych kontrolowanych testów. |
Lista kontrolna decyzji
- Wymień wymagane funkcje gracza. Nazwij dokładne wymagania dotyczące pracy, ekonomii, ekwipunku, mieszkań, telefonu, pojazdów, administracji i integracji.
- Inwentaryzuj istniejące zależności. Zapisz wersje frameworków, manifesty, tabele baz danych, eksporty, zdarzenia i niestandardowe zmiany w rdzeniu.
- Mapuj wsparcie zasobów. Dla każdego wymaganego zasobu potwierdź, jaki framework i jaką wersję faktycznie obsługuje, w tym mosty i systemy zastępcze.
- Sprawdź wiedzę zespołu. Uwzględnij API, języki, model bazy danych i narzędzia operacyjne, które mogą zdiagnozować opiekunowie.
- Oszacuj migrację na podstawie dowodów. Policz rzeczywiste domeny danych i integracje; nie używaj generycznej tabeli godzinowej lub kosztowej.
- Zbuduj reprezentatywny stos testowy. Użyj oficjalnego przepisu, wybranych zasobów i oczyszczonej kopii realistycznych danych.
- Zdefiniuj akceptację i wycofanie. Zdecyduj, co musi działać i jak przywrócić poprzednie spójne pliki i bazę danych.
Migracja wpływa na cały model serwera
Zmiana frameworków może obejmować tożsamości, postacie, pieniądze, pracę, gangi, ekwipunek, pojazdy, garaże, mieszkania, telefony, bankowość, konta społeczne, uprawnienia i niestandardowe zdarzenia. Relacje danych mają znaczenie: utworzenie nowego identyfikatora postaci bez mapowania wszystkich powiązanych rekordów może spowodować osierocenie zasobów lub uprawnień.
Nie uruchamiaj ogólnego fragmentu konwersji SQL na produkcji. Zacznij od inwentaryzacji schematu i zasobów, zaprojektuj idempotentną konwersję na kopii testowej, zweryfikuj liczbę rekordów i relacje, a następnie przećwicz wycofanie. Skrypty specyficzne dla frameworka mogą wymagać oficjalnego mostu, udokumentowanego trybu wieloframeworkowego lub zmian w kodzie. Skrypty ESX nie są automatycznie przenośne do QBCore lub Qbox, a most Qbox QB nie jest uniwersalny.
Jak przeprowadzić benchmark własnego stosu
Jeśli wydajność wpływa na wybór, porównaj kontrolowane kompilacje zamiast powtarzać ranking. Użyj tego samego hosta lub izolowanego równoważnego sprzętu, artefaktu FXServer, wersji bazy danych, objętości danych i reprezentatywnych akcji gracza. Utrzymuj zestaw zasobów porównywalny funkcjonalnie i podaj każdą zamierzoną różnicę.
- Rozgrzej każdy serwer konsekwentnie i zarejestruj zachowanie bezczynności.
- Powtórz te same akcje dotyczące postaci, ekwipunku, pracy, pojazdu i ekonomii.
- Zbierz dowody z profilera FiveM lub resmon, a także metryki wolnych zapytań bazy danych i systemu.
- Uruchom wiele próbek i zgłaszaj rozkłady lub zakresy, a nie pojedynczą najlepszą liczbę.
- Sprawdź błędy, poprawność danych i zachowanie ponownego połączenia wraz z czasem.
- Zachowaj konfigurację i surowe logi, aby inny recenzent mógł odtworzyć wniosek.
Benchmark jednego rdzenia z różnymi zasobami nie izoluje frameworka. Wynik z syntetycznego pustego serwera nie dowodzi wydajności produkcyjnej. Publikuj tylko wnioski poparte zarejestrowaną konfiguracją i surowymi dowodami.
Praktyczna rekomendacja
- Wybierz ESX gdy obecne zasoby ESX, dane i wiedza zespołu najlepiej spełniają wymagania, a migracja nie przynosi udowodnionych korzyści.
- Wybierz QBCore gdy oficjalny przepis QB i udokumentowany ekosystem pasują do nowej kompilacji lub istniejącego serwera QB.
- Wybierz Qbox gdy zespół celowo chce obecnego przepisu Qbox i API oraz może przeprowadzić audyt mostu lub migracji QB.
Otwórz dedykowane przewodniki po frameworkach dla obecnej oficjalnej granicy instalacji i kompatybilności. Następnie dopasuj zasoby komercyjne do dokładnie wybranej konfiguracji, zamiast traktować szeroką etykietę kategorii jako ostateczny dowód.
Szczegółowe przewodniki po frameworkach
Kontynuuj z dokładną granicą instalacji i kompatybilności dla ESX Legacy, QBCore lub Qbox i stos Ox.