Safe Roblox Death, Respawn, and Item Drop System

# www.prompthubai.com.br
# Encontre prompts, agentes e workflows testados para vender, programar e automatizar com IA em português.

# Safe Roblox Death, Respawn, and Item Drop System

## Cabecalho
- Tipo: Conteudo
- Categoria: Games
- Modulos: 0
- Agentes: 0

## Escopo
Generate a robust death system for Roblox in which the server detects player elimination, selects eligible items from the inventory, creates physical drops in the world, and handles respawn safely. The prompt includes protection against duplication, repeated deaths, manual character resets, and automatic cleanup of abandoned drops.

Ideal for survival, RPG, PvP, extraction, dungeon crawler, and inventory-based Tool experiences. Before generating the code, simply provide your project structure — folder names, Tools, attributes, RemoteEvents, and item retention rules — to receive a complete, commented Luau Script ready to be inserted into Roblox Studio.

## Prompt Principal
Act as a senior Roblox Luau developer, specialized in server-authoritative multiplayer systems, inventory, physics-based drops, and anti-exploit security. Create a complete death, respawn, and item-drop-on-death system, strictly adapted to the context of my project that I will provide below.

Before writing the code, interpret the data provided in “MY GAME CONTEXT”. If any essential data is missing, do not stop the response with questions: assume a safe convention, clearly state the assumptions in a short section, and keep all configuration at the top of the script so I can easily change it.

MY GAME CONTEXT (I will fill in):
- Location of the player’s persistent items/Tools: [e.g.: Backpack, Inventory folder inside Player, existing DataStore, etc.]
- Where equipped items are stored: [e.g.: Character, Backpack]
- Which items can drop: [e.g.: Tools with attribute DropOnDeath=true, all except protected list]
- Items that can never drop: [names, CollectionService tags, or attributes]
- Quantity rule: [drop everything, percentage, maximum of X items, random draw]
- Workspace folder name for drops: [e.g.: WorldDrops]
- How the dropped item should appear: [physical Tool, pickup Model, Part with ProximityPrompt, existing system]
- Existing RemoteEvents/RemoteFunctions and their paths: [if any]
- Custom inventory system/existing API: [functions or ModuleScripts, if any]
- Time until respawn: [seconds]
- Time until a drop disappears: [seconds]
- Special rules: [e.g.: keep starter item, do not drop in SafeZone, PvP, teams, currency]

SCRIPT TYPE AND LOCATION: generate a single server Script to be placed in ServerScriptService, with a suggested name such as DeathRespawnDropService. The code must work centrally for all players. Do not use a LocalScript to decide death, remove items, grant rewards, transfer inventory, or validate pickup. If my context requires RemoteEvents, use only the RemoteEvents already provided; if they do not exist, explain in the installation section exactly which instances to create, their types, and where to place them, but keep the critical logic exclusively on the server.

MANDATORY FUNCTIONAL REQUIREMENTS:
1. Detect PlayerAdded and CharacterAdded, locate Humanoid with safe WaitForChild, and connect Humanoid.Died without creating duplicate connections after respawns.
2. On death, run the routine only once per character, even if there are multiple events, manual reset, concurrent scripts, or rapid Character changes. Use a server-side lock per player/character and perform reliable cleanup of it.
3. Collect only items allowed by the configurable rules. Handle Tools in Character and Backpack without duplicating the same object. Never clone or destroy items before clearly defining the transfer strategy for the drop.
4. Create drops in Workspace in the configured folder, ensuring it exists on the server. Position them near the death position with controlled random spread, optional raycast to find the ground, and a safe fallback when HumanoidRootPart does not exist.
5. Every drop must have secure server-side identification: an attribute or values with the original owner’s UserId, item name/identifier, creation time, and pickup state. Implement an optional owner protection period, configurable at the top.
6. Implement physical pickup preferably with a server-validated ProximityPrompt. When triggered, validate: player exists, character is alive, real distance to the drop, drop state, protection window, and inventory capacity/rules. Never trust data sent by the client for item, quantity, damage, currency, or pickup permission.
7. On pickup, transfer the item atomically and race-condition-safe: mark the drop as reserved/picked up before transfer, restore the state if an error occurs, and destroy the drop only after success. Avoid duplication from multiple players triggering the Prompt simultaneously.
8. Program automatic cleanup of expired drops using Debris or task.delay with state checks. Clean up connections and temporary data in PlayerRemoving and when the object is destroyed.
9. Configure respawn using the standard Players/LoadCharacter behavior, without dangerous loops. Respect CharacterAutoLoads when applicable and leave a commented option for manual respawn only if my context requests it.
10. Do not implement a new DataStore, currency system, or custom damage unless I have specified them. Do not use loadstring, HttpService, require from external assets, obfuscated code, or external dependencies.

CODE QUALITY:
- Deliver complete, executable, commented Luau code inside a single markdown ```lua block.
- Use services obtained by GetService, Luau types when they improve safety, clear names, configuration constants at the top, and pcall where an API/inventory failure cannot bring down the routine.
- Preserve compatibility with standard Roblox Studio. Do not invent nonexistent APIs.
- If items are Tools, explain and implement the necessary conversion/storage so they can be picked up safely. If it is necessary to clone a pickup visual, make the separation explicit between the visual and the real item instance stored exclusively on the server.

RESPONSE STRUCTURE:
1. “Assumptions and compatibility”: short list of decisions made based on the context.
2. “Explorer installation”: exact Script path, required folders/objects, and expected attributes/tags.
3. The single block with the complete Luau code.
4. “How to test in Roblox Studio”: objective steps using Test > Start Server and multiple Players, including tests for death, respawn, simultaneous pickup, owner protection, expiration, reset, and client exploit attempts.

Prioritize security, inventory consistency, and duplication prevention over visual effects. Do not respond with pseudocode, incomplete snippets, or an explanation without the complete Script.