Advanced Custom Tool System with Animation
ESCOPO
This prompt generates a complete custom tools implementation for Roblox, allowing you to equip, unequip, visually toggle the item, and play animations smoothly. It is ideal for weapons, flashlights, gathering items, survival gear, and any Tool with its own logic.
The requested response organizes the system between client and server, using server authority for relevant states and strict validation of RemoteEvents. The prompt also requires handling respawn, connection cleanup, spam prevention, and support for project settings.
Before generating the code, the assistant should consider your game’s context, such as Explorer paths, Tool names, animation IDs, and existing Remotes. This way, you receive scripts ready to paste into Roblox Studio, along with clear installation and testing instructions.
Conteudo
Prompt principal
Act as a senior Roblox developer specialized in Luau, client-server architecture, Tools, character animations, and exploit protection. Create a complete, production-ready system for custom tools with equip, unequip, and animations, adapted to the context of my game provided below. The goal is to implement a custom tool system in which the player can reliably equip and unequip a Tool, with equip animation, idle animation while equipped, and unequip animation when applicable. The system must work correctly with R6 or R15 characters according to the project configuration, respect the Character lifecycle, and not leave duplicate AnimationTracks, events, or states after death, respawn, Tool removal, or rapid equipment switching. Before writing the code, analyze and use this context. If any field is not filled in, assume a safe Roblox structure and briefly explain the assumption before the code: - Rig type used: [R6, R15, or both] - Tool path or Tools path: [e.g., ReplicatedStorage/Tools/Flashlight] - Tool name(s): [fill in] - Does the Tool have a Handle? Which part will be used as the Handle/visual? [fill in] - Animation IDs for equip, idle, and unequip: [fill in] - RemoteEvents/RemoteFunctions already existing and their paths: [fill in] - Where the Tool is given to the player: [StarterPack, server Backpack, store, inventory, etc.] - Specific rules: [cooldown, block switching during action, sounds, duration, animation priority, mobile, gamepad, etc.] - Relevant Explorer structure: [paste real names and paths here] Provide a modular solution with ALL necessary scripts, not just isolated snippets. Explicitly define, before each file, the TYPE of the script and its exact location in the Explorer. The expected minimum architecture is: 1. A ModuleScript in ReplicatedStorage, for example `ReplicatedStorage/Shared/ToolConfig`, to centralize per-tool allowed settings, animation IDs, cooldowns, and shared parameters. 2. A server Script in `ServerScriptService`, responsible for validating requests coming from the client, keeping relevant authoritative states, verifying that the player actually owns/equips the expected Tool, applying rate limiting, and preventing the client from freely providing names, animation IDs, damage values, coins, or inventory. 3. A LocalScript inside the Tool, in `StarterPlayerScripts` or another technically appropriate location for the context provided, responsible for capturing `Tool.Equipped`, `Tool.Unequipped`, swapping/playing AnimationTracks locally, and communicating to the server only the strictly necessary intentions. 4. If it is necessary to create a RemoteEvent, include a server initialization Script that creates it in `ReplicatedStorage/Remotes` in an idempotent way, or adapt the code to the existing Remotes provided in the context. Never assume that a RemoteEvent sent by the client is trustworthy. Implement animations using `Animator:LoadAnimation()` whenever possible, obtaining the Animator from Humanoid or AnimationController in a robust way. Set appropriate priorities, stop previous tracks before starting new ones, handle loading failures, and ensure idle ends on unequip, death, character switch, or Tool destruction. Do not use `wait()`; use `task.wait`, `task.delay`, `os.clock`, and organized connections. Avoid unnecessary infinite loops, memory leaks, and multiple connections on each equip. The Tool should continue using native Backpack/Character behavior whenever possible. If it is necessary to block equip or unequip during an animation, implement this with local presentation state and server confirmation/validation for gameplay rules. Do not implement damage, reward, inventory, or item granting based on data sent by the client. If the system includes a remote equip command, the server must validate Player, Character, living Humanoid, Backpack/Character, allowed Tool in the configuration, and minimum interval between requests. Deliver the response in this order: a brief architecture overview; the recommended Explorer tree; each complete file with its path, type (`Script`, `LocalScript` or `ModuleScript`), and full code; and installation instructions. All code must be inside Markdown blocks in the format ` ```lua `, be valid Luau, commented in Portuguese, and ready to copy and paste without pseudocode, omissions, or placeholders such as “complete here”. Preserve the real names from my context when provided. Finally, include a concise testing checklist for Roblox Studio using Play and Start Server/Start Player: validate equip, unequip, swap spam, respawn, death, Tool removal, switching between two Tools, missing Animator, invalid animations, and attempts to trigger RemoteEvents manually from the client. Also state which warning messages should appear for diagnosis and which values/IDs I should replace if I left context fields blank.
