Cross-Place Teleport with Secure Data Persistence

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

# Cross-Place Teleport with Secure Data Persistence

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

## Escopo
This prompt creates an advanced teleport system between places within the same Roblox experience, with secure preservation of data such as coins, inventory, progress, team, and session state. It guides the AI to integrate the code into the existing architecture of your game without assuming fixed names for folders, remotes, or modules.

The requested output is a ready-to-paste Luau server Script for Roblox Studio, with persistence via DataStoreService, temporary metadata via TeleportData, and safeguards against exploitation attempts. It also includes failure handling, request limits, recovery in the destination place, and a practical test plan for a published environment.

It is intended for developers who have experiences with lobbies, maps, dungeons, matches, separate worlds, or any flow that moves players between multiple places within the same Roblox universe.

## Prompt Principal
Act as a senior Roblox Luau developer, specialized in multiplayer architecture, DataStoreService, and TeleportService. Create a teleport system between places within the same Roblox experience that preserves player data reliably, securely, and in a production-compatible way. Before generating the code, use the technical context I provide below as the source of truth.

My game context (I will fill in or adjust before sending):
- Destination PlaceId: [PASTE_THE_DESTINATION_PLACE_ID]
- Name/location of the RemoteEvent used to request teleport, if one already exists: [E.G.: ReplicatedStorage.Remotes.RequestTeleport]
- Name/location of a RemoteEvent for visual feedback to the client, if one already exists: [OPTIONAL]
- Current data system: [E.G.: ModuleScript ServerScriptService.Services.PlayerDataService / custom DataStore / leaderstats / none]
- Existing functions to read and save data: [E.G.: GetProfile(player), SaveProfile(player), LoadProfile(player)]
- Structure of the data to preserve: [E.G.: Coins, Gems, Inventory, Level, QuestProgress, SelectedClass]
- Teleport access rules: [E.G.: only when touching a portal; requires level 10; everyone can use it]
- Relevant objects in Explorer and their paths: [PASTE HERE]
- Are there multiple destinations? [YES/NO; describe IDs, names, and rules]
- Desired behavior at the destination: [E.G.: spawn at a SpawnLocation named DungeonSpawn]

Generate ONE complete server Script in Luau, ready to paste into ServerScriptService, with a suggested name such as CrossPlaceTeleportService.server.lua. If my context already has a central data module, integrate with it through a clearly identified adapter layer at the beginning of the script, without duplicating the DataStore or silently replacing the existing system. If there is no data system, implement a minimal persistence layer with DataStoreService, using a key based on UserId and a serializable data schema.

The script must implement these technical requirements:
1. Run exclusively on the server. The client may only request a teleport intent via RemoteEvent; the server must validate player, allowed destination, match state, cooldown, requirements, and proximity/access condition when applicable. Never accept coins, inventory, damage, permissions, arbitrary PlaceId, or data to save from the client.
2. Use TeleportService:TeleportAsync() on the server and TeleportOptions:SetTeleportData() to transport only minimal metadata, such as snapshot version, random requestId, logical destination, and timestamp. Do not send the full inventory or sensitive data in TeleportData. Explain in comments that TeleportData does not replace persistence in DataStore.
3. Before teleporting, obtain a clean snapshot of the data on the server, validate its types, remove non-serializable values (Instances, functions, userdata, and cyclic references), and save it atomically with DataStoreService:UpdateAsync(). Include retries with limited backoff for transient failures, pcall, and diagnostic messages via warn(). Do not make infinite loops or exceed DataStore limits.
4. Save control fields in the record, including schemaVersion, updatedAt, saveVersion, and a transaction/requestId identifier. In the destination place, use Player:GetJoinData() to read TeleportData, validate type, timestamp, requestId, and expected origin PlaceId. Then load the persisted data by UserId from DataStore or through the existing data adapter; the DataStore must be the source of truth, and TeleportData is only for correlation and flow.
5. Protect against duplication or regression of data caused by repeated attempts, teleport failure, or duplicate arrival. Use saveVersion/requestId in a documented way, never overwrite a newer record with an older snapshot, and make it clear in comments which guarantees are possible and which depend on the existing data service.
6. Handle TeleportService.TeleportInitFailed, save failures, and player leaving during the process. Implement a per-player lock to prevent multiple concurrent teleports, configurable cooldown, connection cleanup, and state restoration if the teleport is not initiated. Do not teleport if the required save fails.
7. If there is a RemoteEvent in the context, connect it with OnServerEvent and apply per-player rate limiting. If there is not, leave a well-documented public/local function, such as RequestTeleport(player, destinationKey), and show exactly how another server Script should call it. Do not create a LocalScript as the main solution.
8. Use task.wait, task.spawn, and modern APIs when appropriate; avoid deprecated APIs. Include configuration centralized at the top of the file, explanatory comments in Brazilian Portuguese, and defensive validation of all Roblox service return values.

First provide a brief list of assumptions made and possible points I should adjust based on the provided context. Then provide the FULL code in a single markdown block identified as ```lua. Do not omit any sections with phrases like "rest of the code", "implement here", or pseudocode. If an integration depends on a function that does not exist in my context, create a functional adapter interface and mark only the mapping points with clear comments.

After the code, write objective instructions for installation in Explorer, configuration of PlaceId and RemoteEvent, API Services/DataStore permissions in Roblox Studio, publishing both places in the same universe, and a test plan. Include success tests, DataStore failure, RemoteEvent spam, duplicate teleport, player leaving during save, and validation of data recovery in the destination place. Keep the entire response in Brazilian Portuguese.