Advanced Tool Durability and Breakage System
ESCOPO
Generate a robust durability implementation for Tools, weapons, pickaxes, axes, and other usable items in Roblox. The system controls wear from use, blocks broken tools, applies visual states, and exposes a secure architecture for repairs and integration with existing combat or gathering systems.
The prompt was designed for professional projects that need to avoid exploits: every durability change, breakage, reward, and repair is validated on the server. It also guides the model to adapt the code to the real structure of your Explorer, existing RemoteEvents, and the specific rules of your game.
Ideal for developers who want complete, commented Luau code ready to paste into Roblox Studio, with clear installation instructions, multiplayer testing, and integration points for inventory, DataStore, and UI.
Conteudo
Prompt principal
Act as a senior Roblox developer, specializing in Luau, client-server architecture, Tools, persistence, and anti-exploit security. Create a complete, modular, server-authoritative durability and breakage system for Tools in my Roblox game, adapted to the context I will provide below. Before writing the code, consider the context of my project. If any essential data is missing, ask at most 5 objective questions; otherwise, assume sensible values, state those assumptions, and proceed. Context to be filled in by me: - Tools/items involved and their names: [PASTE HERE] - Where the Tools live (StarterPack, ServerStorage, ReplicatedStorage, custom inventory, etc.): [PASTE HERE] - Relevant Explorer structure: [PASTE HERE] - Existing RemoteEvents/RemoteFunctions and location: [PASTE HERE] - System that consumes the tool (combat, mining, tree cutting, fishing, etc.): [PASTE HERE] - Current event or point at which a valid use/a hit is confirmed on the server: [PASTE HERE] - Is there inventory, currency, crafting, repair NPC, or DataStore? Describe: [PASTE HERE] - Desired rules for wear, breakage, repair, and destruction/replacement of the Tool: [PASTE HERE] - Version/structure of attributes already used in the Tools, if any: [PASTE HERE] Deliver the solution as an architecture with two mandatory components and any extra components only if they are truly necessary: 1. A ModuleScript named `DurabilityService`, located at `ServerScriptService/Modules/DurabilityService` (or explicitly adapt the path if my structure requires it). It must centralize all rules for initialization, lookup, durability consumption, breakage, repair, and state synchronization. 2. A `Script` named `DurabilityServer`, located at `ServerScriptService/DurabilityServer`, responsible for connecting the module to server-confirmed use events, Players, Backpack, and Character. If it is essential to display durability in a UI, also create a clearly separated `LocalScript`, indicating that it should live in `StarterPlayer/StarterPlayerScripts`, and use only safe replicated data, such as Tool Attributes. The LocalScript can never decide, reduce, restore, or validate durability. Do not create new RemoteEvents if the ones provided in the context already solve the integration; if you need to create one, explain the name, type, location in `ReplicatedStorage/Remotes`, and validate every server call strictly. Mandatory technical requirements: - Use Attributes on the Tools, preferably `Durability`, `MaxDurability`, `IsBroken` and, if useful, `ItemId`/`DurabilityVersion`. Initialize missing values with configurable defaults by item type, without overwriting valid values loaded from inventory/DataStore. - Wear may only occur after a server-confirmed action: for example, damage actually applied to a valid target, a ore node actually collected, or a tree actually hit. Do not subtract durability on click, animation, or local input without confirmation. - Implement `InitializeTool`, `CanUseTool`, `ConsumeDurability`, `BreakTool`, `RepairTool`, and `GetDurabilityState` in the module, with Luau typing when appropriate, defensive validations, and clear returns. - On breakage, block use of the Tool on the server, interrupt pending actions when applicable, and apply a safe optional visible state (for example, name with `[BROKEN]` prefix, Attribute, and non-destructive visual change). Preserve the broken Tool by default unless the provided rule requires destruction or replacement with scrap. - Handle Tools moved between Backpack and Character, player respawn, accidental duplicate connections, and instance removal/destruction. The system must not create memory leaks or multiple listeners for the same Tool. - If repair exists via RemoteEvent, the server must validate Player, Tool, ownership of the Tool (Backpack/Character), distance to station/NPC when applicable, cost, currency, and limits. Never accept from the client values such as repair amount, cost, target item, damage, reward, or balance as absolute truth. - Do not allow negative durability, repair above `MaxDurability`, a Tool without valid `MaxDurability`, or manipulation of instances outside the player. Use `math.clamp` and type/class checks when needed. - Explain exact integration points with my combat/gathering system: show where to call `DurabilityService:ConsumeDurability(tool, amount, context)` only after server-side success confirmation. - Do not use nonexistent APIs, pseudocode, legacy `wait()`, or external dependencies. Prefer `task`, `GetAttribute`, `SetAttribute`, `CollectionService` only if it brings real benefit, and services obtained via `game:GetService`. Required response format: 1. Start with a brief list of assumptions and the installation tree in the Explorer. 2. Provide ALL complete files, each in its own markdown block with the exact `lua` identifier, preceded by the exact path and type. Do not omit sections with comments like "continue here" or "add your logic". 3. Comment the code in a useful way, explaining security and integration decisions, without excessive comments on every line. 4. After the code, include an "Integration" section with concrete call examples in my current system. 5. End with a section "How to test in Roblox Studio", covering testing with Start Server + Players, normal wear, breakage, exploit attempts via RemoteEvent, respawn, switching between Backpack/Character, and repair. The response must be functional, complete Luau code, ready to paste into Roblox Studio and compatible with the rules and names provided in the context.
