
- ESX
- QBCore
- QBOX
10% off com ROLEPLAY1010% de desconto em todos os pedidos com o código ROLEPLAY10 no checkout
Por Luke

Não há um vencedor universal oficial entre ESX, QBCore e Qbox. Escolha o framework cuja receita atual, APIs e recursos compatíveis correspondam aos recursos de servidor necessários, dados existentes e habilidades da equipe. Se você já opera uma pilha estável específica do framework, permanecer nesse ecossistema geralmente é a primeira opção a ser avaliada, pois a migração afeta mais do que a pasta principal.
| Ponto de partida | Primeiro framework a ser avaliado | Motivo para verificar |
|---|---|---|
| Servidor ESX existente | ESX Legacy | Preserva dados, eventos, exportações e conhecimento de recursos específicos do ESX quando os requisitos atuais ainda são atendidos. |
| Servidor QBCore existente | QBCore | Evita a conversão, a menos que outro framework resolva um requisito documentado que a justifique. |
| Nova instalação voltada ao ecossistema QB | QBCore ou Qbox | Compare as duas receitas oficiais, recursos selecionados, modelo API e compatibilidade exata de terceiros. |
| Equipe QBCore considerando Qbox | Qbox com auditoria de ponte | A ponte QB ajuda muitos recursos, mas exceções documentadas ainda exigem verificações no nível do recurso. |
| Nenhum requisito de framework de roleplay | Recursos Standalone | Standalone descreve um padrão de dependência; confirme se um framework completo é realmente desnecessário. |
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 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.
Oficial do QBCore 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.
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.
| Dimensão | Pergunta | Evidência |
|---|---|---|
| Caminho de instalação | Existe uma receita oficial atual e documentação completa? | Documentos oficiais e repositório de receitas na data revisada. |
| Recursos necessários | Quais banco de dados, biblioteca, inventário e recursos de suporte são selecionados? | Arquivos de receita, manifestos e declarações de dependência. |
| Compatibilidade API | Quais exportações, eventos, objetos e campos de dados os scripts necessários chamam? | Código-fonte do recurso, manifestos e documentação oficial da API. |
| Modelo de dados | Quais identificadores, classificações, contas e relacionamentos devem ser preservados? | Inventário de esquema e mapeamento de migração testado. |
| Operações | A equipe pode atualizar, diagnosticar e reverter a pilha? | Runbooks, backups e uma simulação de recuperação em ambiente de testes. |
| Desempenho | Como a pilha exata se comporta sob ações representativas? | Profiler, resmon e logs de banco de dados de testes controlados repetidos. |
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.
Se o desempenho influencia a escolha, compare compilações controladas em vez de repetir um ranking. Use o mesmo host ou hardware equivalente isolado, artefato FXServer, versão do banco de dados, volume de dados e ações representativas do jogador. Mantenha o conjunto de recursos funcionalmente comparável e declare cada diferença intencional.
Um benchmark de um núcleo com recursos diferentes não isola o framework. Um resultado de um servidor vazio sintético não prova a capacidade de produção. Publique apenas conclusões suportadas pela configuração registrada e evidências brutas.
Abra os guias de framework dedicados para a instalação oficial atual e o limite de compatibilidade. Em seguida, combine os recursos comerciais com a pilha exata escolhida, em vez de tratar um rótulo de categoria ampla como prova final.
Continue com a instalação exata e o limite de compatibilidade para ESX Legacy, QBCore ou o pilha Qbox e Ox.
Cfx.re — frameworks · Fonte: docs.qbox.re · Fonte: qbcore-fivem/qb-core · Fonte: esx-framework/esx_core


JG Scripts



JG Scripts

Jaksam