O que é e por que funciona (quando configurado certo)
Um combat log em servidores de GTA RP é, basicamente, um registro em tempo real de tudo que envolve combate dentro do jogo: trocas de tiro, dano recebido, uso de armas, mortes e, em alguns casos, interações punitivas entre jogadores. Ele serve para duas coisas principais. A primeira é transparência — o jogador consegue provar que foi atingido legítimamente ou que não iniciou um confronto. A segunda é moderação — a equipe administra recursos disso para investigar griefing, powergaming e situações que fogem do controle manual. A lógica por trás disso é simples. O servidor executa um script que monitora eventos do FiveM (ou similar), captura dados específicos e os grava em uma tabela do banco de dados. Cada linha contém timestamp, ID do agressor, ID da vítima, tipo de dano, arma usada, local aproximado e, quando aplicável, o IDs de entrada/saída da vehicle envolvida. O painel visual nada mais é do que uma query ordenada por data com filtros básicos.
Como configurar combat log gta rp do jeito que não gera problema depois
Eu tenho uma dica que parece óbvia mas quase ninguém aplica corretamente na primeira rodada de deployment: comece pela frequência de flush do banco, não pelo script de captura. Em servidores com movimento constante, cada hit individual gera uma INSERT. Em média, um servidor com 30-40 players ativos em picos pode disparar entre 200 e 800 inserts por minuto só de combat log, dependendo da qualidade do código. Se o script usar queries isoladas em vez de batch, o MySQL começa a engasgar em 15-20 minutos de uso contínuo e o lag de resource fica perceptível. O workaround que eu uso consiste em acumular eventos em uma tabela memory/tmp do framework (ESX, QBCore ou Standalone) e fazer um flush em lote a cada 30 segundos. No código, você armazena os registros em uma table temporária e, quando o timer dispara, executa um único INSERT multi-row. Isso reduz a carga do banco de 300-600 queries por minuto para algo em torno de 2 queries por flush. A diferença no TPS do servidor é de cerca de 0.5 a 1.5 de fps stabilizado nos recursos de database.
Depois dessa otimização, o resto é montar o painel. Eu recomendo começar com estas colunas obrigatórias e não pular nenhuma: Data e hora — sempre no formato UTC+0 para evitar confusão com fuso horário quando há staff de diferentes regiões. Use o campo 'created_at' do banco e converta no painel, nunca confie no relógio do cliente.
ID do jogador — não use nome. Nomes mudam. IDs são fixos. Mantenha userId e, se possível, socialId para evitar duplicação quando alguém troca de nome. Tipo de evento — categorize em shoot, melee, vehicle_impact, explosion, heal, revive, arrest, death. Isso permite filtrar rapidamente por padrão de abuso. Um jogador que aparece repetidamente em 'shoot' como atacante com dano acima da média em janelas de 5 minutos é um indicador muito mais útil do que olhardela em death count.
ID da arma — a classe de arma importa menos do que o hash dela. Registre o hash (WEAPON_PISTOL, WEAPON_ASSAULTRIFLE, etc.) e o dano aplicado. Isso evita ambiguidade entre variantes e permite calcular DPS médio por arma. Local X/Y/Z — coordenadas aproximadas ajudam a reconstruir cenários. Mas você precisa tratar isso com cuidado, porque coordenadas em movimento rápido podem ter delta significativo entre o momento do dano e o registro. Eu costumo adicionar um campo 'source_vehicle_id' quando aplicável para desambiguar.
Status do alvo — whether o alvo estava conscious, downed, ou dead no momento do impacto. Isso é crucial para distinguir legítimo RP de de mecânicas. Para o painel em si, eu prefiro uma stack simples: PHP backend com MySQL direto, interface em vanilla JS ou Alpine.js, e um filtro lateral com data range, jogador (por ID ou partial name), tipo de evento e resultado (alvo vivo/morto). O resultado deve exibir até 50 linhas por página, com paginação via GET parameters para facilitar bookmarking de investigações específicas.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Um detalhe técnico que pouca gente leva a sério: você precisa de um sistema de retenção automática. Eu vejo muitos servidores deixarem o log crescer indefinidamente até que queries simples de 'SELECT * FROM combat_log WHERE date > X' levem 8 segundos para rodar. Configure um job diário que archive registros com mais de 30 dias em uma tabela 'combat_log_archive' ou exporte para CSV e deleta da tabela principal. Isso mantém as queries de investigação rápidas (geralmente abaixo de 200ms mesmo com milhares de linhas).
Pegadinhas que ninguém conta
A primeira: combat log não captura intenção, captura ação. Se um jogador atira em outro que está com 1 HP e morre, o log mostra damage_dealt = 99. Mas a narrativa pode ser completamente diferente — um hit intencional de execução versus um ricochete acidental. Por isso, o log é ferramenta de apoio, não veredito. Sempre cruze com camera logs ou depoimentos quando a situação for ambígua. A segunda pegadinha é mais insidiosa. Alguns scripts de combat log contam dano por tick de frame, o que significa que armes de alta cadência (minigun, SMG) geram milhares de linhas de log em segundos. Isso não só infla o volume de dados como pode distorcer métricas se você usar 'número de entradas' como proxy de 'gravidade'. Sempre normalize por dano total e time window, não por contagem de linhas.
Outro problema comum: a sincronia entre o log de combate e o log de chat/ação. Quando um chega, o moderador precisa alternar entre três painéis diferentes (combat, chat, action). Se o seu sistema permite cross-referencing por timestamp e userId dentro de uma única interface, o tempo de investigação cai de 10-15 minutos para 2-3 minutos na maioria dos casos.
O que esse sistema não resolve
Combat log não substitui presença ativa de staff. Ele amplia a capacidade de resposta, mas não elimina a necessidade de monitoramento humano. Situações de roleplay complexo — como provocações antes do combate, ameaças verbais, ou contexto social — ficam fora do escopo do log. Um jogador pode ter zero entradas de 'shoot' como atacante e ainda assim estar perpetrando griefing psicológico via chat. Também é importante notar que logs dependem da qualidade do script que os gera. Se o recurso de combat log tiver bugs de debounce ou de validação de dano, ele pode registrar hits que tecnicamente não aconteceram no jogo (por exemplo, dano calculado no client e confirmado tarde demais no server). Sempre valide uma amostra dos registros contra observação direta nas primeiras semanas de implantação.
Se o seu servidor tem volume baixo — menos de 15 players simultâneos — o custo-benefício de um sistema completo de combat log pode não justificar o investimento inicial. Nesse caso, um log simplificado em texto com eventos de death e major injury, arquivado em Discord ou Google Sheets, pode ser suficiente e muito mais rápido de implementar. Para quem quer começar com algo funcional, existem resources no GitHub e no forum oficial do FiveM que implementam combat logging básico. A maioria usa a framework do QBCore ou ESX como base. Procure por pacotes que incluam batch insert, retenção automática e painel web integrado. Evite soluções que fazam uma query por evento sem buffering — elas vão degradar a performance do servidor em menos de uma hora de uso.
O ponto central é que combat log gta rp é infraestrutura, não solução mágica. Ele funciona bem quando bem calibrado, mas exige manutenção contínua e interpretação humana. Configurar direito desde o início economiza horas de dor de cabeça depois.
