Sistema Avançado de Ferramentas Customizadas com Animação
ESCOPO
Este prompt gera uma implementação completa de ferramentas customizadas para Roblox, permitindo equipar, desequipar, alternar visualmente o item e reproduzir animações de forma fluida. Ele é ideal para armas, lanternas, itens de coleta, equipamentos de sobrevivência e qualquer Tool com lógica própria.
A resposta solicitada organiza o sistema entre cliente e servidor, usando autoridade no servidor para estados relevantes e validação rigorosa de RemoteEvents. O prompt também exige tratamento de respawn, limpeza de conexões, prevenção de spam e suporte a configurações do projeto.
Antes de gerar o código, o assistente deverá considerar o contexto do seu jogo, como caminhos no Explorer, nomes de Tools, IDs de animação e Remotes já existentes. Assim, você recebe scripts prontos para colar no Roblox Studio, acompanhados de instruções claras de instalação e testes.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox sênior especializado em Luau, arquitetura cliente-servidor, Tools, animações de personagem e segurança contra exploits. Crie um sistema completo e pronto para produção de ferramentas customizadas com equip, unequip e animações, adaptado ao contexto do meu jogo informado abaixo. O objetivo é implementar um sistema de ferramentas customizadas em que o jogador possa equipar e desequipar uma Tool de maneira confiável, com animação de equipar, animação idle enquanto equipada e animação de desequipar quando aplicável. O sistema deve funcionar corretamente com personagens R6 ou R15 conforme a configuração do projeto, respeitar o ciclo de vida do Character e não deixar AnimationTracks, eventos ou estados duplicados após morte, respawn, remoção da Tool ou troca rápida de equipamento. Antes de escrever o código, analise e use este contexto. Se algum campo não for preenchido, assuma uma estrutura Roblox segura e explique rapidamente a suposição antes do código: - Tipo de rig utilizado: [R6, R15 ou ambos] - Caminho da Tool ou Tools: [ex.: ReplicatedStorage/Tools/Lanterna] - Nome(s) da(s) Tool(s): [preencher] - A Tool possui Handle? Qual peça será usada como Handle/visual? [preencher] - IDs das animações de equip, idle e unequip: [preencher] - RemoteEvents/RemoteFunctions já existentes e seus caminhos: [preencher] - Onde a Tool é entregue ao jogador: [StarterPack, Backpack por servidor, loja, inventário etc.] - Regras específicas: [cooldown, bloquear troca durante ação, sons, duração, prioridade de animação, mobile, gamepad etc.] - Estrutura relevante do Explorer: [cole aqui nomes e caminhos reais] Forneça uma solução modular com TODOS os scripts necessários, e não apenas trechos isolados. Defina explicitamente, antes de cada arquivo, o TIPO do script e seu local exato no Explorer. A arquitetura mínima esperada é: 1. Um ModuleScript em ReplicatedStorage, por exemplo `ReplicatedStorage/Shared/ToolConfig`, para concentrar configurações permitidas por ferramenta, IDs de animação, cooldowns e parâmetros compartilhados. 2. Um Script de servidor em `ServerScriptService`, responsável por validar pedidos vindos do cliente, manter estados autoritativos relevantes, verificar se o jogador realmente possui/equipou a Tool esperada, aplicar rate limit e impedir que o cliente forneça nomes, IDs de animação, valores de dano, moedas ou inventário livremente. 3. Um LocalScript dentro da Tool, em `StarterPlayerScripts` ou em outro local tecnicamente apropriado para o contexto informado, encarregado de capturar `Tool.Equipped`, `Tool.Unequipped`, trocar/reproduzir AnimationTracks localmente e comunicar ao servidor apenas intenções estritamente necessárias. 4. Caso seja preciso criar um RemoteEvent, inclua um Script de inicialização no servidor que o crie em `ReplicatedStorage/Remotes` de forma idempotente, ou adapte o código aos Remotes existentes informados no contexto. Nunca presuma que um RemoteEvent enviado pelo cliente é confiável. Implemente animações usando `Animator:LoadAnimation()` sempre que possível, obtendo o Animator de Humanoid ou AnimationController de modo robusto. Configure prioridades adequadas, interrompa tracks anteriores antes de iniciar novas, trate falha de carregamento e garanta que a idle seja encerrada ao desequipar, morrer, trocar de personagem ou destruir a Tool. Não use `wait()`; use `task.wait`, `task.delay`, `os.clock` e conexões organizadas. Evite loops infinitos desnecessários, memory leaks e múltiplas conexões em cada equip. A Tool deve continuar usando o comportamento nativo de Backpack/Character quando possível. Se for necessário bloquear equip ou desequip durante uma animação, implemente isso com estado local para apresentação e confirmação/validação no servidor para regras de gameplay. Não implemente dano, recompensa, inventário ou concessão de itens baseada em dados enviados pelo cliente. Caso o sistema inclua um comando remoto de equip, o servidor deve validar Player, Character, Humanoid vivo, Backpack/Character, Tool permitida na configuração e intervalo mínimo entre requisições. Entregue a resposta nesta ordem: uma breve visão da arquitetura; a árvore de Explorer recomendada; cada arquivo completo com seu caminho, tipo (`Script`, `LocalScript` ou `ModuleScript`) e código integral; e instruções de instalação. Todo código deve estar dentro de blocos Markdown no formato ` ```lua `, ser Luau válido, comentado em português e pronto para copiar e colar sem pseudocódigo, omissões ou marcadores como “complete aqui”. Preserve os nomes reais do meu contexto quando fornecidos. Por fim, inclua um roteiro objetivo para testar no Roblox Studio usando Play e Start Server/Start Player: validar equip, unequip, spam de troca, respawn, morte, remoção da Tool, troca entre duas Tools, ausência de Animator, animações inválidas e tentativas de acionar RemoteEvents manualmente pelo cliente. Informe também quais mensagens de warning devem aparecer para diagnóstico e quais valores/IDs devo substituir caso eu tenha deixado campos do contexto em branco.
