Configuração do framework

QBCore e ESX#

Somente determinadas estruturas e campos indexados são compatíveis. Colunas ausentes ou IDs personalizados podem impedir consultas. Resposta vazia não prova banco vazio.

Fluxos personalizados#

Teste personagens, empregos, teleporte e garagens em ambiente de testes. Valide permissões no servidor e aplique exceções restritas por código confiável.

Separar framework e inventário#

Identifique o recurso do estado do jogador: qb-core, qbx_core ou es_extended. Confira inventário e APIs separadamente. O nome do framework não garante todo script bancário externo. Mantenha dependências e não execute cores concorrentes para solucionar erros.

Edite o campo existente: qb para QBCore, qbox para Qbox; são valores, não pastas. auto permite detecção. Confira início e GetStatus em código servidor. A ponte detecta cores ativos separadamente e pode mostrar dependência ainda parada.

-- Edite o campo existente, não toda a tabela.
ts.Framework.framework = "qb"
-- Outros valores compatíveis: "esx", "qbox", "auto", "standalone"

Conferir dados do personagem#

Leituras usam citizenid em QBCore/Qbox e identifier em ESX. O ID temporário do servidor não substitui o identificador persistente. Colunas e índices compatíveis são necessários; estruturas personalizadas podem ser recusadas.

1. Compare um personagem de teste com dinheiro, banco, trabalho e veículo conhecidos.
2. Com ox_inventory, compare um inventário online pequeno. Respeite cortes; não espere stashes ou metadados arbitrários.
3. Em falhas API, confira início e versão. API indisponível significa posse de arma desconhecida, não ausência comprovada.

• Ponte de banco de dados (Tosun Connect)

Testar atividades reais#

A detecção não conhece permissões, localização, preço ou recompensa de cada evento próprio. Seu script deve validar no servidor. Selecionar perfil não corrige eventos inseguros. Confira source e sessão antes da integração.

Standalone/vRP podem usar verificações gerais apropriadas, mas a ponte não promete seus esquemas próprios. Explique limites em vez de substituir tabelas. Reteste após atualizar core, inventário ou trabalhos.

Registre versões de core e inventário. Após reiniciar core reconecte o personagem antes de julgar a API online. Não mude esquema e punição juntos: separar permite diagnóstico e restauração.

• Troca de personagem e reanimação não deixam isenção permanente.
• Casa, garagem e prisão chamam MarkTeleport imediatamente antes do movimento.
• Armas de arena fora do inventário usam AllowWeapon curto de recurso servidor confiável.
• Confira polícia, ferramentas, lojas e recompensas grandes nos logs antes de endurecer punições.

• Exports e confiança
• Segurança oficial de eventos

Interpretar nomes configurados e cores detectados#

A configuração AC e o conector usam rótulos diferentes: QBCore é configurado como qb, mas o bridge informa qbcore. Qbox usa qbox e o recurso qbx_core iniciado. Leia esses nomes no contexto correspondente em vez de adaptá-los a pastas. A configuração automática pode reconhecer vrp ou ox_core e definir um nome, sem criar um adaptador compatível de personagens ou economia para o bridge. Num core não suportado, escolher standalone explicitamente para proteção geral evita entender o nome detectado como integração completa.

1. Confira configs/anticheat_config.lua e o core realmente iniciado; preserve uma escolha consciente e a ordem de dependências.
2. Se as capacidades do painel diferirem, examine cores iniciados e saúde do bridge antes de renomear configurações às cegas.
3. Não inicie qb-core, qbx_core e es_extended juntos só para obter outro rótulo de estado.

Criar testes de aceitação por papéis reais#

Separe testes de jogadores comuns, polícia ou outros empregos e equipe. A equipe pode ter isenções legítimas; execute verificações também com personagem comum. Inclua entrada, escolha de personagem, morte e reanimação, casas, garagens, armas do inventário e recompensas reais dos empregos. Anote destino, objeto ou efeito na conta esperado e log observado. Teste cancelamento e conclusão de menus e atividades. Um início limpo não comprova que inventário modificado, banco ou seletor de personagens utiliza as API esperadas.

1. Repita a mesma série pequena antes e depois de atualizar core ou inventário, mudando um componente por vez.
2. Para falhas, registre versões, recurso chamador e papel do jogador; preserve privacidade de dados identificativos.
3. Reconecte após reinício ou troca de personagem e confirme o fim da isenção temporária, não só o caminho da equipe.

Definir responsabilidades de scripts próprios#

Separe detecção das regras pertencentes aos scripts do jogo. AC não conhece destinatários permitidos de transferências próprias, tetos de recompensa ou donos de casas. Os recursos devem validar jogador, permissão e estado do servidor antes de mudar dinheiro, itens ou posição. Verificações de armas usam API suportadas; API indisponível representa desconhecido, não prova de arma gerada. Se leituras falham por colunas ou índices, investigue compatibilidade separadamente de punições. Não puna jogadores por erro de integração nem substitua adaptador ausente por isenção ampla.

1. Defina um responsável pelo adaptador framework ou inventário e responsáveis claros para cada ação personalizada.
2. Reproduza uma ação permitida e uma permissão rejeitada usando validações do próprio script.
3. Separe proteção AC geral da ponte de banco de dados do painel (Tosun Connect); tabelas próprias precisam de integração revisada.

Ler inventário de armas e detalhe separadamente#

Framework e inventário podem diferir: QBCore gere personagens e dinheiro, ox_inventory itens. Verificação de armas prioriza ox_inventory ativo, depois API compatíveis QBCore/Qbox ou ESX. Detalhe do painel é outra operação. Item visível não comprova mesma fonte, tempo e formato de todas as verificações. Mudar rótulo não sincroniza arsenais próprios.

Loadout ESX e quantidade de inventário por itens são conceitos distintos. nil, erro ou dado inesperado não provam ausência. Confira método e registre entrega, ação normal, provedor e resultado. AllowWeapon revisado pode cobrir armas legítimas do servidor fora do inventário no alcance necessário. Trata-se de compatibilidade, não de promessa de corrigir qualquer defeito de detecção.

Tratar migração além dos nomes de tabelas#

Migrar QBCore e ESX não muda só um nome. O bridge usa players/citizenid no QBCore e users/identifier no ESX. Sessão antiga ou nome visível não identifica personagem migrado. Dinheiro, veículos, inventário e regras podem variar. Não renomeie produção para satisfazer consultas. A migração pertence ao plano do servidor; AC não converte dados ausentes.

Selecione personagem e veículo conhecidos em teste separado. Anote core, identidade persistente, cash/bank e estado online antes de ler. Erro de esquema ou índice não comprova perda. Responsável avalia compatibilidade. A edição de saldos pelo painel vem ligada por padrão; não a use até a aceitação. Para bloqueá-la, use o modo manual: set tosun_db_bridge_manual "1" e set tosun_db_bridge_enabled "1" no server.cfg, sem tosun_db_bridge_money_write. Reteste escolha de personagem e inventário normal. Aceite dados corretos para personagem correto, não apenas resource iniciado.