Sistema Avançado de Durabilidade e Quebra de Ferramentas
ESCOPO
Gere uma implementação robusta de durabilidade para Tools, armas, picaretas, machados e outros itens utilizáveis no Roblox. O sistema controla desgaste por uso, bloqueia ferramentas quebradas, aplica estados visuais e expõe uma arquitetura segura para reparos e integração com sistemas de combate ou coleta já existentes.
O prompt foi estruturado para projetos profissionais que precisam evitar exploits: toda alteração de durabilidade, quebra, recompensa e reparo é validada no servidor. Ele também orienta o modelo a adaptar o código à estrutura real do seu Explorer, aos RemoteEvents existentes e às regras específicas do seu jogo.
Ideal para desenvolvedores que desejam código Luau completo, comentado e pronto para colar no Roblox Studio, com instruções claras de instalação, testes multiplayer e pontos de integração para inventário, DataStore e interface.
Conteudo
Prompt principal
Atue como um desenvolvedor Roblox sênior, especialista em Luau, arquitetura cliente-servidor, ferramentas (Tools), persistência e segurança anti-exploit. Crie um sistema completo, modular e servidor-autoritativo de durabilidade e quebra para Tools do meu jogo Roblox, adaptado ao contexto que fornecerei abaixo. Antes de escrever o código, considere o contexto do meu projeto. Se algum dado essencial estiver ausente, faça no máximo 5 perguntas objetivas; caso contrário, assuma valores sensatos, declare essas suposições e prossiga. Contexto a ser preenchido por mim: - Ferramentas/itens envolvidos e seus nomes: [COLE AQUI] - Onde as Tools ficam (StarterPack, ServerStorage, ReplicatedStorage, inventário próprio etc.): [COLE AQUI] - Estrutura relevante do Explorer: [COLE AQUI] - RemoteEvents/RemoteFunctions já existentes e localização: [COLE AQUI] - Sistema que consome a ferramenta (combate, mineração, corte de árvores, pesca etc.): [COLE AQUI] - Evento ou ponto atual em que um uso válido/um acerto é confirmado no servidor: [COLE AQUI] - Existe inventário, moedas, crafting, NPC de reparo ou DataStore? Descreva: [COLE AQUI] - Regras desejadas de desgaste, quebra, reparo e destruição/substituição da Tool: [COLE AQUI] - Versão/estrutura de atributos já usados nas Tools, se houver: [COLE AQUI] Entregue a solução como uma arquitetura de dois componentes obrigatórios e quaisquer componentes extras apenas se forem realmente necessários: 1. Um ModuleScript chamado `DurabilityService`, localizado em `ServerScriptService/Modules/DurabilityService` (ou adapte explicitamente o caminho se a minha estrutura exigir). Ele deve centralizar toda regra de inicialização, consulta, consumo de durabilidade, quebra, reparo e sincronização de estado. 2. Um `Script` chamado `DurabilityServer`, localizado em `ServerScriptService/DurabilityServer`, responsável por conectar o módulo aos eventos de uso confirmados pelo servidor, Players, Backpack e Character. Se for indispensável exibir durabilidade em uma interface, crie também um `LocalScript` claramente separado, indicando que ele deve ficar em `StarterPlayer/StarterPlayerScripts`, e use apenas dados replicados seguros, como Attributes da Tool. O LocalScript nunca pode decidir, reduzir, restaurar ou validar durabilidade. Não crie RemoteEvents novos se os fornecidos no contexto já resolverem a integração; se precisar criar algum, explique o nome, o tipo, a localização em `ReplicatedStorage/Remotes` e valide rigorosamente toda chamada no servidor. Requisitos técnicos obrigatórios: - Use Attributes nas Tools, preferencialmente `Durability`, `MaxDurability`, `IsBroken` e, se útil, `ItemId`/`DurabilityVersion`. Inicialize valores ausentes com defaults configuráveis por tipo de item, sem sobrescrever valores válidos carregados por inventário/DataStore. - O desgaste só pode ocorrer após uma ação confirmada pelo servidor: por exemplo, dano realmente aplicado a alvo válido, nó de minério efetivamente coletado ou árvore efetivamente atingida. Não desconte durabilidade em clique, animação ou input local sem confirmação. - Implemente `InitializeTool`, `CanUseTool`, `ConsumeDurability`, `BreakTool`, `RepairTool` e `GetDurabilityState` no módulo, com tipagem Luau quando apropriado, validações defensivas e retornos claros. - Ao quebrar, bloqueie o uso da Tool no servidor, interrompa ações pendentes quando aplicável e aplique um estado visível opcional seguro (por exemplo, nome com prefixo `[QUEBRADA]`, Attribute e alteração visual não destrutiva). Preserve a Tool quebrada por padrão, salvo se a regra informada exigir destruição ou substituição por sucata. - Trate Tools transferidas entre Backpack e Character, respawn do jogador, duplicações acidentais de conexões e remoção/destruição da instância. O sistema não deve criar memory leaks nem múltiplos listeners para a mesma Tool. - Caso exista reparo via RemoteEvent, o servidor deve validar Player, Tool, propriedade da Tool (Backpack/Character), distância de estação/NPC quando aplicável, custo, moeda e limites. Nunca aceite do cliente valores como quantidade de reparo, custo, item alvo, dano, recompensa ou saldo como verdade absoluta. - Não permita durabilidade negativa, reparo acima de `MaxDurability`, Tool sem `MaxDurability` válido, nem manipulação de instâncias fora do jogador. Use `math.clamp` e verificações de tipo/classe quando necessário. - Explique pontos de integração exatos com meu sistema de combate/coleta: mostre onde chamar `DurabilityService:ConsumeDurability(tool, amount, context)` somente depois da confirmação de sucesso no servidor. - Não use APIs inexistentes, pseudocódigo, `wait()` legado ou dependências externas. Prefira `task`, `GetAttribute`, `SetAttribute`, `CollectionService` apenas se trouxer benefício real e serviços obtidos por `game:GetService`. Formato obrigatório da resposta: 1. Comece com uma breve lista de suposições e a árvore de instalação no Explorer. 2. Forneça TODOS os arquivos completos, cada um em seu próprio bloco markdown com identificador `lua`, precedido pelo caminho e tipo exatos. Não omita trechos com comentários como "continue aqui" ou "adicione sua lógica". 3. Comente o código de forma útil, explicando decisões de segurança e integração, sem comentários excessivos em cada linha. 4. Depois do código, inclua uma seção "Integração" com exemplos concretos de chamada no meu sistema atual. 5. Finalize com uma seção "Como testar no Roblox Studio", cobrindo teste com Start Server + Players, desgaste normal, quebra, tentativa de exploit por RemoteEvent, respawn, troca entre Backpack/Character e reparo. A resposta deve ser código Luau funcional, completo, pronto para colar no Roblox Studio e compatível com as regras e nomes fornecidos no contexto.
