Roblox Material-Combination Crafting Made Safe
ESCOPO
Generate a robust crafting system for Roblox in which players combine inventory materials to create items defined by recipes. The prompt guides the AI to produce a server-authoritative implementation, avoiding common exploits such as unauthorized item creation, negative values, and repeated RemoteEvent requests.
Ideal for RPGs, simulators, survival games, tycoons, and collection games that already have or plan to have an inventory based on Folder, IntValues, Attributes, or ModuleScript. Before generating the code, the user can provide the real Explorer structure, material names, recipes, existing RemoteEvents, and the inventory format used in the project.
The expected response includes a complete, commented Luau Script ready to paste into ServerScriptService, with recipe configuration, data validation, per-player rate limiting, atomic material consumption, and structured success or error feedback for the client.
Conteudo
Prompt principal
Act as a senior Roblox Luau developer, specialized in secure multiplayer systems, persistent inventories, and server-authoritative architecture. Create a complete material-combination crafting system in a single server Script, ready to be pasted into Roblox Studio. The required TYPE is `Script` (not LocalScript and not ModuleScript). The required location is `ServerScriptService`, with the suggested name `CraftingService.server.lua`. The script must be responsible for the authoritative crafting logic. It must receive requests from the client through a `RemoteEvent` in `ReplicatedStorage`, but never trust quantities, materials, results, or any other data coming from the client. If the configured RemoteEvent does not exist and the context below allows its creation, the script may create it on the server. Do not create a UI or provide client code in this request. Before writing the code, analyze and respect the context of my game below. If any field is `[PREENCHER]`, use a safe convention, clearly marked in comments, and briefly explain the assumption after the code. Preserve names already existing in my project when they are provided. === MY GAME CONTEXT === - Relevant Explorer structure and names: [PASTE HERE] - Player inventory location and format (e.g. Player.Inventory with IntValues; Attributes; Profile/Data module): [PASTE HERE] - Existing RemoteEvent for crafting requests, if any, and its path: [PASTE HERE] - Existing RemoteEvent for client response/update, if any, and its path: [PASTE HERE] - Available materials and exact names used in the inventory: [PASTE HERE] - Craftable items and desired recipes (result, output quantity, and ingredients): [PASTE HERE] - Special limits, such as maximum quantity per request, required level, workstation, gamepass, or currency: [PASTE HERE] - How the client will send the request (e.g. only recipeId and quantity): [PASTE HERE] - Additional rules and existing integrations: [PASTE HERE] === END OF CONTEXT === Implement a recipe table on the server using stable internal IDs, for example `wooden_sword`, separated from the display names shown to the player. Each recipe must define ingredients, output quantity, and, when applicable, optional requirements. The client should send only a recipe identifier and a requested quantity; the server must look up the full recipe composition locally. Never accept an ingredient table, result item name, inventory balance, or price sent by the client. The Script needs to: safely locate each player's inventory; validate the Luau types of all arguments received by the RemoteEvent; reject nonexistent IDs, excessively long strings, non-numeric quantities, NaN, infinity, fractional values, negatives, zero, and values above the configured limit; confirm that the player has all ingredients before changing any value; subtract the ingredients and add the result consistently; prevent negative balances; and prevent a partial failure from leaving the inventory corrupted. Perform a complete pre-validation of capacity and materials before any change. If the inventory format does not support creating a missing item, return an explicit error and document the adaptation point. Add per-player rate limiting using `os.clock()` or an equivalent on the server, with state cleanup in `Players.PlayerRemoving`. Protect calls with `pcall` when there is risk of errors due to missing objects or external integration. The system must respond to the client with a simple and safe payload through a result RemoteEvent, containing `success`, `code`, `recipeId`, `craftedAmount`, and a short message. Do not send the entire inventory unless necessary. Use predictable error codes such as `INVALID_REQUEST`, `INVALID_RECIPE`, `RATE_LIMITED`, `INVENTORY_NOT_READY`, `INSUFFICIENT_MATERIALS`, `INVENTORY_FULL`, and `CRAFT_FAILED`. Include helpful comments in the code explaining: recipe configuration, inventory path, creation/location of the RemoteEvents, request validation, rate limiting, material pre-check, and atomic update. Use current Roblox APIs, `WaitForChild` only when it makes sense and without unnecessary infinite waits. Do not use `loadstring`, DataStore directly for each craft, or client-side security logic. If there is an external saving system in the context, change only the values/objects it already observes or indicate a safe integration point. Your response must contain, in this order: 1) a short section with the assumed architecture and Explorer paths; 2) exactly one markdown code block identified as `lua`, containing the complete Luau Script and no pseudocode, ready to paste into `ServerScriptService`; 3) an objective list of instructions to test in Roblox Studio, including testing with two players in `Test > Start`, sufficient/insufficient materials, invalid recipe, RemoteEvent spam, and confirmation that the client cannot define the craft result. Do not omit essential snippets and do not replace code with ellipses.
