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.
Guia de decisão rápida
| 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. |
O que um framework FiveM faz
Cfx.re descreve frameworks como fundações que facilitam a construção de recursos de servidor. Um framework de roleplay geralmente estabelece padrões compartilhados para dados de jogadores e personagens, trabalhos, itens, dinheiro, comandos, permissões e comunicação entre recursos. Os recursos exatos visíveis para os jogadores dependem da receita completa e dos recursos instalados, não apenas do nome do framework principal.
Essa distinção evita uma comparação enganosa. Sistemas de inventário, moradia, telefones, bancos ou veículos podem ser recursos separados e podem ser substituídos. Uma marca de seleção ao lado de um nome de framework não prova qual implementação, versão ou integração um servidor de produção executará.
ESX Legacy
ESX Legacy é um framework de roleplay de código aberto com seu núcleo atual publicado pela organização oficial ESX. O tutorial oficial para novos servidores usa o modelo txAdmin do ESX Legacy. A instalação manual documenta oxmysql, spawnmanager, importação de banco de dados, recursos principais e adicionais, exclusões e ordem de inicialização.
ESX é a primeira opção a ser avaliada quando um servidor existente já possui dados de jogador, recursos e procedimentos de equipe específicos do ESX. Essa é uma observação de risco de migração, não uma alegação de participação de mercado. Para uma nova construção, inspecione a receita atual e verifique se cada produto necessário suporta a versão exata do ESX, inventário, biblioteca de banco de dados, exportações e eventos.
QBCore
O qb-core oficial do QBCore disponibiliza um Core Object com funções, dados de jogadores, dados compartilhados, configurações e comandos. As definições compartilhadas incluem empregos, gangues, itens e veículos. A instalação oficial para Windows usa a receita popular QBCore Framework no txAdmin, que implanta um banco de dados e um conjunto mais amplo de recursos, além da pasta do core.
QBCore pode ser uma opção para uma nova instalação ou uma instalação existente no ecossistema QB quando suas APIs documentadas e seus recursos compatíveis atendem aos requisitos do servidor. Não presuma que todo recurso com o rótulo QBCore seja compatível com todas as versões do core ou com qualquer inventário substituto. Registre os exports, as dependências, o SQL e a ordem de inicialização necessários para a configuração exata.
Qbox
A introdução oficial do Qbox registra que o Qbox começou em 2022 a partir do QBCore e agora tem suas próprias APIs e recursos principais. O Qbox mantém uma ponte de compatibilidade QB para muitos recursos QBCore bem escritos. Sua documentação também nomeia exceções, incluindo recursos que dependem de acesso direto ao banco de dados, arquivos principais internos ou comportamento não suportado.
A instalação oficial do Qbox usa uma receita popular do QBox em txAdmin. Para uma migração do QBCore, o guia de conversão abrange diferenças de configuração, níveis numéricos de cargos e gangues, conversão de inventário e banco de dados e substituição incremental da API. O Qbox é, portanto, uma escolha deliberada de framework com uma auditoria de compatibilidade, não simplesmente uma mudança que faz com que todos os scripts QBCore funcionem inalterados.
Dimensões de comparação que você pode verificar
| 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. |
Lista de verificação de decisão
- Liste os recursos necessários do jogador. Nomeie os requisitos exatos de empregos, economia, inventário, moradia, telefone, veículo, administração e integração.
- Faça um inventário das dependências existentes. Registre as versões da estrutura, manifestos, tabelas de banco de dados, exportações, eventos e alterações personalizadas do núcleo.
- Mapeie a compatibilidade dos recursos. Para cada recurso necessário, confirme a estrutura e a versão que ele realmente suporta, incluindo pontes e sistemas de substituição.
- Verifique o conhecimento da equipe. Inclua as APIs, linguagens, modelo de banco de dados e ferramentas operacionais que os mantenedores podem diagnosticar.
- Estime a migração a partir de evidências. Conte os domínios de dados e integrações reais; não use uma tabela genérica de horas ou custos.
- Construa uma pilha de teste representativa. Use a receita oficial, recursos selecionados e uma cópia sanitizada de dados realistas.
- Defina a aceitação e o rollback. Decida o que deve funcionar e como restaurar os arquivos e o banco de dados consistentes anteriores.
A migração afeta todo o modelo do servidor
A mudança de frameworks pode envolver identidades, personagens, dinheiro, empregos, gangues, inventário, veículos, garagens, moradias, telefones, bancos, contas de organizações, permissões e eventos personalizados. As relações de dados importam: criar um novo identificador de personagem sem mapear todos os registros relacionados pode orfanar ativos ou permissões.
Não execute um snippet de conversão SQL genérico contra a produção. Comece com um inventário de esquema e recursos, projete uma conversão idempotente contra uma cópia de teste, valide as contagens e relações de registros e ensaie o rollback. Scripts específicos de framework podem precisar de uma ponte oficial, um modo multi-framework documentado ou alterações de código. Scripts ESX não são automaticamente portáteis para QBCore ou Qbox, e a ponte Qbox QB não é universal.
Como comparar sua própria pilha
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.
- Aqueça cada servidor consistentemente e capture o comportamento ocioso.
- Repita as mesmas ações de carregamento de personagem, inventário, trabalho, veículo e economia.
- Colete evidências do profiler FiveM ou resmon, além de consultas lentas do banco de dados e métricas do sistema.
- Execute várias amostras e relate distribuições ou intervalos, não um único melhor número.
- Inspecione erros, correção de dados e comportamento de reconexão junto com o tempo.
- Mantenha a configuração e os logs brutos para que outro revisor possa reproduzir a conclusão.
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.
Recomendação prática
- Escolha ESX quando os recursos atuais do ESX, dados e conhecimento da equipe melhor satisfazem os requisitos e a migração não tem benefício comprovado.
- Escolha QBCore quando a receita oficial do QB e o ecossistema documentado se encaixam em uma nova construção ou em um servidor QB existente.
- Escolha Qbox quando a equipe deseja deliberadamente a receita e as APIs atuais do Qbox e pode concluir uma auditoria da ponte QB ou da migração.
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.
Guias detalhados do framework
Continue com as instruções exatas de instalação e os limites de compatibilidade de ESX Legacy, QBCore ou da stack Qbox e Ox.
Documentação de referência
Cfx.re — frameworks · Fonte: docs.qbox.re · Fonte: qbcore-fivem/qb-core · Fonte: esx-framework/esx_core