Log Administrativo Seguro com DataStore para Roblox
ESCOPO
Gere um sistema profissional de auditoria administrativa para Roblox, projetado para registrar ações como banimentos, kicks, teleports, concessão de moedas, alteração de inventário e comandos internos. O script organiza os eventos em lotes serializáveis e os grava com segurança no DataStore.
O prompt exige arquitetura server-side autoritativa, validação rigorosa de permissões e de dados recebidos, proteção contra excesso de requisições e tratamento de falhas do DataStore. Ele também orienta você a informar a estrutura real do seu Explorer, os RemoteEvents existentes e as regras administrativas do seu projeto.
Ideal para desenvolvedores que precisam de rastreabilidade, investigação de abusos e histórico persistente de operações sensíveis em experiências Roblox multiplayer.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox sênior, especialista em Luau, segurança multiplayer e persistência com DataStoreService. Crie um sistema completo de log de ações administrativas persistente em DataStore, pronto para colar no Roblox Studio e adaptado ao contexto do meu jogo fornecido abaixo. Antes de escrever o código, considere este contexto que eu irei preencher. Se algum campo estiver vazio, adote uma convenção segura, declare a premissa objetivamente e mantenha o sistema funcional: - Nome e localização do sistema/comandos administrativos atual no Explorer: [PREENCHER] - RemoteEvents/RemoteFunctions já existentes e respectivos locais: [PREENCHER] - Como o jogo identifica administradores (UserIds, grupo/rank, whitelist, framework próprio etc.): [PREENCHER] - Ações que devem ser auditadas (por exemplo: kick, ban, unban, teleport, givecoins, setlevel, giveitem, mute): [PREENCHER] - Estrutura dos argumentos de cada ação administrativa: [PREENCHER] - Se existe um sistema próprio de moedas, inventário, banimento ou dados de jogadores: [PREENCHER] - Limite desejado de registros por período/segmento, se houver: [PREENCHER] - Nome desejado para o DataStore: [PREENCHER] Gere UM Script servidor completo, do tipo `Script`, para ser colocado em `ServerScriptService`. Ele deve conter uma API interna clara, preferencialmente uma função ou tabela local chamada `LogAdminAction`, para que outros scripts do servidor possam registrar eventos sem depender do cliente. Explique, antes do código e em poucas linhas, como os scripts administrativos existentes devem chamar essa API ou como integrar a chamada no ponto exato em que cada comando é confirmado pelo servidor. Caso uma integração direta entre scripts exija ModuleScript, não altere o pedido principal: entregue o Script funcional e explique uma alternativa segura com BindableEvent ou a conversão opcional para ModuleScript, sem criar dependência obrigatória de código ausente. O sistema deve registrar, no mínimo: identificador único do evento, timestamp UTC em formato Unix, data UTC, UserId e nome do administrador, UserId e nome do alvo quando aplicável, nome padronizado da ação, argumentos higienizados, motivo opcional, servidor/jobId e placeId. Nunca registre informações sensíveis desnecessárias. Crie uma função de sanitização que converta argumentos em valores serializáveis pelo DataStore, limite tamanho de strings, profundidade de tabelas e quantidade de itens, descarte tipos inválidos como Instances, funções e userdata, e evite salvar dados excessivos. Implemente uma estratégia realista para as limitações do DataStore: não faça uma gravação imediata para cada comando. Use uma fila em memória, agrupamento em lotes, intervalo de flush configurável, limite máximo de fila e `pcall` em toda operação de persistência. Organize os logs em chaves segmentadas por data UTC e por segmento/parte, evitando ultrapassar limites de tamanho. Use `UpdateAsync` para reduzir risco de sobrescrever registros concorrentes entre servidores. Inclua tentativas com backoff simples em caso de falha, aviso via `warn`, retenção temporária na fila quando possível e flush no encerramento usando `game:BindToClose`. Não tente garantir persistência absoluta durante shutdown, mas trate o cenário da melhor forma permitida pela plataforma. A segurança é obrigatória. O servidor deve ser autoritativo: nunca aceite do cliente que uma ação ocorreu, quem é administrador, qual valor de moeda foi alterado, qual item foi dado ou qual alvo foi punido. Se o meu fluxo atual usar RemoteEvent ou RemoteFunction, demonstre validação no servidor de permissões, tipo, limites, existência do alvo e regras da ação ANTES de executar a operação e somente DEPOIS de registrá-la. A rotina de log não deve, por si só, conceder privilégios. Inclua rate limit por administrador para impedir spam de logs e proteja o script contra erros causados por dados malformados. Use APIs atuais do Roblox, tipagem Luau quando trouxer clareza, nomes consistentes e comentários úteis em português. Não use `loadstring`, HttpService para persistir logs, DataStore no cliente, nem código pseudo-Luau. Não invente RemoteEvents, caminhos ou frameworks como se existissem; quando precisar de um ponto de integração, marque-o claramente como configuração ou adapte-se aos campos de contexto acima. Sua resposta final deve conter: (1) uma breve lista de premissas adotadas; (2) o código Luau integral, autocontido e comentado, obrigatoriamente dentro de um único bloco markdown ```lua; (3) instruções precisas para criar/posicionar o Script em `ServerScriptService`, habilitar API Services no Studio para testes de DataStore, adaptar a lista de administradores, inserir chamadas de log nos comandos e testar em ambiente publicado/servidor de teste. Não omita trechos essenciais, não entregue apenas exemplos e não divida o código em partes incompletas.
