Uso simultâneo de ESX e QBCore: por que não é viável

Resposta direta: Não execute ESX e QBCore como dois cores autoritativos para os mesmos jogadores. Ambos podem tecnicamente iniciar como recursos FiveM, mas eles modelam identidade, empregos, dinheiro, inventário, callbacks e eventos de forma diferente. Sem uma ponte construída para um propósito específico e uma fonte de verdade declarada, o estado duplicado se torna inseguro e difícil de recuperar.

Por que dois cores entram em conflito

Domínio	Risco com duas autoridades	Controle necessário
Identidade	Um jogador pode receber registros ESX e QBCore não relacionados.	Uma identidade canônica e mapeamento explícito.
Dinheiro e empregos	Atualizações podem divergir ou ser aplicadas duas vezes.	Um único responsável pelas gravações e regras de conversão testadas.
Inventário	Itens, metadados e semântica de armazenamento diferem.	Uma autoridade de inventário; adaptadores na fronteira.
Eventos e callbacks	Ações de gameplay semelhantes podem acionar manipuladores de framework não relacionados.	Adaptadores com namespace e revisados em vez de espelhamento global.
Dependências	Um recurso pode detectar o core errado ou usar uma API não suportada.	Testes exatos de dependência e ordem de inicialização.

O que é viável

Um servidor pode executar um adaptador de compatibilidade para um recurso específico quando o adaptador tem um contrato restrito e um framework permanece autoritativo. Qbox, por exemplo, documenta uma ponte QB e seus limites. Isso é diferente de executar duas economias e modelos de jogador completos lado a lado.

Lista de verificação de decisão

1. Nomeie o core autoritativo para identidade, empregos, dinheiro e inventário.
2. Liste os recursos legados exatos que bloqueiam a migração.
3. Prefira substituir ou portar cada recurso; use bridge apenas quando o contrato for documentado e testável.
4. Teste chamadas não autorizadas, reconexões, reinicializações e falhas parciais de dependência.
5. Se ambos os cores precisarem escrever no mesmo domínio, pare e redesenhe antes da produção.

Escopo e limitações

Não há uma resposta universal para cada fork ou adaptador personalizado. Uma bridge cuidadosamente projetada pode traduzir uma superfície API limitada, mas deve declarar propriedade, comportamento de falha e regras de persistência. Não interprete “compatível com QB” como prova de compatibilidade total QBCore em outro framework.

Fontes primárias

• Cfx.re: Frameworks
• ESX: repositório oficial esx_core
• QBCore: repositório oficial qb-core
• Qbox: documentação oficial

• Qbox FAQ: Limites de compatibilidade QBCore
• Qbox qbx_core bridge convars