Não existe um vencedor universal oficial entre ESX, QBCore e Qbox. Escolha o framework cuja receita atual, APIs e recursos compatíveis correspondam aos recursos necessários do seu servidor, dados existentes e habilidades da equipe. Se você já opera uma stack estável específica de um framework, permanecer nesse ecossistema geralmente é a primeira opção a ser avaliada, pois a migração afeta mais do que a pasta principal.
Guia rápido de decisão
| Ponto de partida | Primeiro framework a avaliar | Motivo para verificar |
|---|---|---|
| Servidor ESX existente | ESX Legacy | Preserva dados, eventos, exports e conhecimento de recursos específicos do ESX quando os requisitos atuais ainda são atendidos. |
| Servidor QBCore existente | QBCore | Evita conversão a menos que outro framework resolva um requisito documentado que a justifique. |
| Nova build orientada a QB | QBCore ou Qbox | Compare as duas receitas oficiais, recursos selecionados, modelo de API e compatibilidade exata com terceiros. |
| Equipe QBCore considerando Qbox | Qbox com auditoria de bridge | A bridge 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
A 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, empregos, itens, dinheiro, comandos, permissões e comunicação entre recursos. Os recursos exatos visíveis aos 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 de novo servidor usa o template txAdmin do ESX Legacy. A instalação manual documenta oxmysql, spawnmanager, importação de banco de dados, recursos principais e complementares, 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 afirmação de participação de mercado. Para uma nova build, 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, exports e eventos.
QBCore
Oficial do QBCore qb-core expõe um Core Object com funções, dados do jogador, dados compartilhados, configuração e comandos. As definições compartilhadas incluem empregos, gangues, itens e veículos. A instalação oficial do Windows usa a receita popular do QBCore Framework no txAdmin, e a receita implanta um banco de dados e um conjunto de recursos mais amplo, em vez de apenas a pasta core.
QBCore é um candidato para uma nova ou existente construção do ecossistema QB quando suas APIs documentadas e recursos compatíveis cobrem os requisitos do servidor. Não infira que todo recurso com o rótulo QBCore suporta toda versão do core ou inventário de substituição. Registre as exports, dependências, SQL e ordem de inicialização necessárias para a pilha 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 centrais. O Qbox mantém uma ponte de compatibilidade QB para muitos recursos QBCore escritos corretamente. Sua documentação também nomeia exceções, incluindo recursos que dependem de acesso direto ao banco de dados, arquivos internos do core ou comportamento não suportado.
A instalação oficial do Qbox usa uma receita popular do QBox no txAdmin. Para uma migração do QBCore, o guia de conversão cobre diferenças de configuração, cargos numéricos e níveis de gangues, conversão de inventário e banco de dados, e substituição incremental de API. O Qbox é, portanto, uma escolha deliberada de framework com uma auditoria de compatibilidade, não simplesmente uma troca que faz com que todo script QBCore funcione inalterado.
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? | Documentação oficial e repositório de receitas na data revisada. |
| Recursos necessários | Qual banco de dados, biblioteca, inventário e recursos de suporte são selecionados? | Arquivos de receita, manifestos e declarações de dependência. |
| Compatibilidade de API | Quais exports, eventos, objetos e campos de dados os scripts necessários chamam? | Fonte do recurso, manifestos e documentação oficial da API. |
| Modelo de dados | Quais identificadores, níveis, 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 um exercício de recuperação em etapas. |
| 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.
- Inventariar dependências existentes. Registrar versões de framework, manifests, tabelas de banco de dados, exports, eventos e alterações personalizadas no core.
- Mapear suporte de recursos. Para cada recurso necessário, confirme o framework e a versão que ele realmente suporta, incluindo bridges e sistemas de substituição.
- Verificar o conhecimento da equipe. Incluir as APIs, linguagens, modelo de banco de dados e ferramentas operacionais que os mantenedores podem diagnosticar.
- Estimar migração com base em evidências. Contar os domínios de dados reais e integrações; não use uma tabela genérica de horas ou custos.
- Construir uma pilha de teste representativa. Use a receita oficial, recursos selecionados e uma cópia saneada de dados realistas.
- Definir aceitação e rollback. Decidir o que deve funcionar e como restaurar os arquivos e banco de dados consistentes anteriores.
A migração afeta todo o modelo do servidor
Mudar de framework pode envolver identidades, personagens, dinheiro, empregos, gangues, inventário, veículos, garagens, moradias, telefones, banco, contas de sociedade, permissões e eventos personalizados. Os relacionamentos de dados são importantes: criar um novo identificador de personagem sem mapear todos os registros relacionados pode orfanar ativos ou permissões.
Não execute um snippet SQL de conversão genérica em produção. Comece com um inventário de esquema e recursos, projete uma conversão idempotente em uma cópia de teste, valide contagens de registros e relacionamentos e ensaie o rollback. Scripts específicos de framework podem precisar de uma bridge oficial, um modo multi-framework documentado ou alterações de código. Scripts ESX não são automaticamente portáveis para QBCore ou Qbox, e a bridge QB do Qbox não é universal.
Como fazer benchmark da sua própria stack
Se o desempenho influenciar a escolha, compare builds controladas em vez de repetir um ranking. Use o mesmo host ou hardware equivalente isolado, artifact do FXServer, versão do banco de dados, volume de dados e ações de jogador representativas. Mantenha o conjunto de recursos funcionalmente comparável e declare toda diferença intencional.
- Aquecer cada servidor consistentemente e capturar o comportamento ocioso.
- Repetir as mesmas ações de carregamento de personagem, inventário, emprego, veículo e economia.
- Coletar evidências do profiler do FiveM ou resmon, além de consultas lentas do banco de dados e métricas do sistema.
- Executar múltiplas amostras e relatar distribuições ou intervalos, não um único número melhor.
- Inspecionar erros, correção dos dados e comportamento de reconexão juntamente com o tempo.
- Manter a configuração e logs brutos para que outro revisor possa reproduzir a conclusão.
Um benchmark de um core com recursos diferentes não isola o framework. Um resultado de um servidor sintético vazio não prova capacidade de produção. Publique apenas conclusões apoiadas pela configuração registrada e evidências brutas.
Recomendação prática
- Escolha ESX quando os recursos ESX atuais, dados e conhecimento da equipe melhor atendem aos requisitos e a migração não tem benefício comprovado.
- Escolha QBCore quando a receita oficial QB e o ecossistema documentado se encaixam em uma nova build ou em um servidor QB existente.
- Escolha Qbox quando a equipe deliberadamente deseja a receita e as APIs atuais do Qbox e pode concluir uma auditoria de ponte ou migração do QB.
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 de framework
Continue com a instalação exata e o limite de compatibilidade para ESX Legacy, QBCore ou a pilha Qbox e Ox.
