{"id":159060,"date":"2024-09-28T13:32:40","date_gmt":"2024-09-28T11:32:40","guid":{"rendered":"https:\/\/hifivem.com\/?p=159060"},"modified":"2026-08-15T19:30:00","modified_gmt":"2026-08-15T17:30:00","slug":"uso-simultaneo-esx-qbcore","status":"publish","type":"post","link":"https:\/\/rpcrate.com\/pt\/simultaneous-use-esx-qbcore\/","title":{"rendered":"Uso simult\u00e2neo de ESX e QBCore: por que n\u00e3o \u00e9 vi\u00e1vel"},"content":{"rendered":"

Resposta direta:<\/strong> N\u00e3o 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\u00e1rio, callbacks e eventos de forma diferente. Sem uma ponte constru\u00edda para um prop\u00f3sito espec\u00edfico e uma fonte de verdade declarada, o estado duplicado se torna inseguro e dif\u00edcil de recuperar.<\/p>\n

Por que dois cores entram em conflito<\/h2>\n
\n\n\n\n\n\n\n\n\n\n
Dom\u00ednio<\/th>\nRisco com duas autoridades<\/th>\nControle necess\u00e1rio<\/th>\n<\/tr>\n<\/thead>\n
Identidade<\/th>\nUm jogador pode receber registros ESX e QBCore n\u00e3o relacionados.<\/td>\nUma identidade can\u00f4nica e mapeamento expl\u00edcito.<\/td>\n<\/tr>\n
Dinheiro e empregos<\/th>\nAtualiza\u00e7\u00f5es podem divergir ou ser aplicadas duas vezes.<\/td>\nUm \u00fanico respons\u00e1vel pelas grava\u00e7\u00f5es e regras de convers\u00e3o testadas.<\/td>\n<\/tr>\n
Invent\u00e1rio<\/th>\nItens, metadados e sem\u00e2ntica de armazenamento diferem.<\/td>\nUma autoridade de invent\u00e1rio; adaptadores na fronteira.<\/td>\n<\/tr>\n
Eventos e callbacks<\/th>\nA\u00e7\u00f5es de gameplay semelhantes podem acionar manipuladores de framework n\u00e3o relacionados.<\/td>\nAdaptadores com namespace e revisados em vez de espelhamento global.<\/td>\n<\/tr>\n
Depend\u00eancias<\/th>\nUm recurso pode detectar o core errado ou usar uma API n\u00e3o suportada.<\/td>\nTestes exatos de depend\u00eancia e ordem de inicializa\u00e7\u00e3o.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

O que \u00e9 vi\u00e1vel<\/h2>\n

Um servidor pode executar um adaptador de compatibilidade para um recurso espec\u00edfico quando o adaptador tem um contrato restrito e um framework permanece autoritativo. Qbox, por exemplo, documenta uma ponte QB e seus limites. Isso \u00e9 diferente de executar duas economias e modelos de jogador completos lado a lado.<\/p>\n

Lista de verifica\u00e7\u00e3o de decis\u00e3o<\/h2>\n
    \n
  1. Nomeie o core autoritativo para identidade, empregos, dinheiro e invent\u00e1rio.<\/li>\n
  2. Liste os recursos legados exatos que bloqueiam a migra\u00e7\u00e3o.<\/li>\n
  3. Prefira substituir ou portar cada recurso; use bridge apenas quando o contrato for documentado e test\u00e1vel.<\/li>\n
  4. Teste chamadas n\u00e3o autorizadas, reconex\u00f5es, reinicializa\u00e7\u00f5es e falhas parciais de depend\u00eancia.<\/li>\n
  5. Se ambos os cores precisarem escrever no mesmo dom\u00ednio, pare e redesenhe antes da produ\u00e7\u00e3o.<\/li>\n<\/ol>\n

    Escopo e limita\u00e7\u00f5es<\/h2>\n

    N\u00e3o h\u00e1 uma resposta universal para cada fork ou adaptador personalizado. Uma bridge cuidadosamente projetada pode traduzir uma superf\u00edcie API limitada, mas deve declarar propriedade, comportamento de falha e regras de persist\u00eancia. N\u00e3o interprete \u201ccompat\u00edvel com QB\u201d como prova de compatibilidade total QBCore em outro framework.<\/p>\n

    Fontes prim\u00e1rias<\/h2>\n