RemoteEvents in Roblox: client to server and back

Why RemoteEvents exist

Every Roblox game runs as one server plus one client per player. The server is the authority: a new object or a property change only reaches every player when the server makes it. A change made in a LocalScript stays on that one device, with a few exceptions such as the player's own character, whose movement their client controls. So when a click or a key press should change the shared world, the client has to ask the server, and when the server wants one player's screen to react, it has to tell that client. If the split between Script and LocalScript is new to you, read Script vs LocalScript vs ModuleScript first.

Roblox gives you three objects for crossing that boundary:

• RemoteEvent: a one-way message. The sender carries on straight away.
• RemoteFunction: a request that waits for a reply. The caller pauses until the other side returns a value.
• UnreliableRemoteEvent: a one-way message that may be dropped or arrive out of order, in exchange for less network overhead. It suits data that changes constantly.

Clients cannot message each other directly. To pass something from one player to the others, fire it to the server, check it there, and let the server send it on with FireClient or FireAllClients. Roblox's security guidance is that the server acts as a gatekeeper here, never a plain relay.

Where to put your remotes

A remote has to sit where both the server and the clients can see it. The usual place is ReplicatedStorage; Roblox's docs note that Workspace or a Tool can also be right in some cases. ServerStorage and ServerScriptService are server-only, so a LocalScript waiting for a remote there waits forever.

1. In the Explorer, hover over ReplicatedStorage, click the + button and insert a Folder. Name it Remotes.
2. Hover over Remotes, click + and insert a RemoteEvent. Rename it to describe its purpose, for example PaintRequest.
3. Repeat for each remote. This guide uses two RemoteEvents (PaintRequest and Notify) and one RemoteFunction (RedeemCode).

ReplicatedStorage
  Remotes  Folder  new
    PaintRequest  RemoteEvent  new
    Notify  RemoteEvent  new
    RedeemCode  RemoteFunction  new
ServerScriptService
  PaintServer  Script  new
  WelcomeServer  Script  new
  FinishAnnouncer  Script  new
  RedeemServer  Script  new
  RemoteGuard  ModuleScript  new
StarterPlayer
  StarterPlayerScripts
    PaintClient  LocalScript  new
    NotifyClient  LocalScript  new
StarterGui
  CodeGui  ScreenGui  new
    CodeBox  TextBox  new
      RedeemClient  LocalScript  new
Workspace
  Paintable  Folder  new
  FinishLine  Part  new

Scripts in this guide find remotes with WaitForChild. It returns at once when the remote is already there and waits when it is not, for example when a server script creates remotes while the game runs. Use one remote per kind of request: each server handler then checks one shape of arguments, which is far easier to get right than a single remote that does anything.

Pattern 1: client to server, checked by the server

The most common job: the player does something on their screen, and the server decides what happens. Here the player presses Q to pick one of four colours and clicks or taps a part to paint it. Everyone sees the new colour, because the server does the painting.

The client sends two things: which part, and a colour number. It never sends the colour itself, and in other games it should never send a price, a reward or a damage amount. A modified client can send anything, so the server keeps the real data (here, the palette) and treats the arguments as a request to check.

1. In Workspace, insert a Folder named Paintable and put a few anchored Parts in it.
2. Check that ReplicatedStorage.Remotes has a RemoteEvent named PaintRequest.
3. Insert a Script in ServerScriptService named PaintServer, and a LocalScript in StarterPlayer, StarterPlayerScripts named PaintClient, with the code below.

local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local remotes = ReplicatedStorage:WaitForChild("Remotes")
local paintRequest = remotes:WaitForChild("PaintRequest") :: RemoteEvent
local paintable = workspace:WaitForChild("Paintable")

-- The server owns the colours. The client only sends a number that picks one.
local PALETTE = {
	Color3.fromRGB(231, 76, 60),
	Color3.fromRGB(46, 204, 113),
	Color3.fromRGB(52, 152, 219),
	Color3.fromRGB(241, 196, 15),
}
local MAX_DISTANCE = 30 -- studs between the character and the part
local COOLDOWN_SECONDS = 0.25

local lastPaint: { [Player]: number } = {}

-- The first parameter is always the player who fired. Roblox fills it in,
-- so it can be trusted. Everything after it came from the client and cannot.
paintRequest.OnServerEvent:Connect(function(player: Player, part: unknown, colourIndex: unknown)
	-- 1. Type: a real part, not a table pretending to be one
	if typeof(part) ~= "Instance" or not part:IsA("BasePart") then
		return
	end

	-- 2. Range: a whole number from 1 to 4. NaN and infinity fail here too.
	if type(colourIndex) ~= "number" or not math.isfinite(colourIndex) then
		return
	end
	if colourIndex % 1 ~= 0 or colourIndex < 1 or colourIndex > #PALETTE then
		return
	end

	-- 3. Allowed target: only parts in the Paintable folder, nothing else in the game
	if not part:IsDescendantOf(paintable) then
		return
	end

	-- 4. Distance: the player's character must be near the part
	local character = player.Character
	local root = character and character:FindFirstChild("HumanoidRootPart")
	if not (root and root:IsA("BasePart")) then
		return
	end
	if (root.Position - part.Position).Magnitude > MAX_DISTANCE then
		return
	end

	-- 5. Rate limit: one paint per player every quarter of a second
	local now = os.clock()
	local last = lastPaint[player]
	if last and now - last < COOLDOWN_SECONDS then
		return
	end
	lastPaint[player] = now

	part.Color = PALETTE[colourIndex]
end)

Players.PlayerRemoving:Connect(function(player: Player)
	lastPaint[player] = nil
end)

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local UserInputService = game:GetService("UserInputService")

local remotes = ReplicatedStorage:WaitForChild("Remotes")
local paintRequest = remotes:WaitForChild("PaintRequest") :: RemoteEvent
local paintable = workspace:WaitForChild("Paintable")

local COLOUR_COUNT = 4 -- the server holds the actual colours
local selectedColour = 1

-- Only let the ray hit parts inside the Paintable folder
local rayParams = RaycastParams.new()
rayParams.FilterType = Enum.RaycastFilterType.Include
rayParams.FilterDescendantsInstances = { paintable }

UserInputService.InputBegan:Connect(function(input: InputObject, gameProcessed: boolean)
	if gameProcessed then
		return -- the key or click went to the chat or a button
	end

	if input.KeyCode == Enum.KeyCode.Q then
		selectedColour = selectedColour % COLOUR_COUNT + 1
		return
	end

	local isClick = input.UserInputType == Enum.UserInputType.MouseButton1
	local isTap = input.UserInputType == Enum.UserInputType.Touch
	if isClick or isTap then
		local camera = workspace.CurrentCamera
		local ray = camera:ScreenPointToRay(input.Position.X, input.Position.Y)
		local result = workspace:Raycast(ray.Origin, ray.Direction * 500, rayParams)
		if result then
			-- Ask, don't tell: the server decides whether the paint happens
			paintRequest:FireServer(result.Instance, selectedColour)
		end
	end
end)

Pattern 2: server to one client

The server sends a message to one player with FireClient. The first argument is the Player to send it to, and the client's handler receives only the arguments after it. Use this for anything personal: a notification, a reward popup, a sound only that player should hear.

This pair shows a welcome message when a player joins. The LocalScript builds its own small banner, so there is no GUI to set up.

local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local notify = ReplicatedStorage:WaitForChild("Remotes"):WaitForChild("Notify") :: RemoteEvent

local function welcome(player: Player)
	-- The first argument picks which client receives it. Nobody else sees this.
	notify:FireClient(player, `Welcome, {player.DisplayName}! Press Q to change colour.`)
end

Players.PlayerAdded:Connect(welcome)

-- In Studio you can join before this script connects, so greet anyone already here
for _, player in Players:GetPlayers() do
	welcome(player)
end

local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local notify = ReplicatedStorage:WaitForChild("Remotes"):WaitForChild("Notify") :: RemoteEvent
local player = Players.LocalPlayer

-- A small banner at the top of the screen, built in code
local gui = Instance.new("ScreenGui")
gui.Name = "Notifications"
gui.ResetOnSpawn = false
gui.Parent = player:WaitForChild("PlayerGui")

local label = Instance.new("TextLabel")
label.AnchorPoint = Vector2.new(0.5, 0)
label.Position = UDim2.new(0.5, 0, 0, 16)
label.Size = UDim2.fromOffset(420, 44)
label.BackgroundColor3 = Color3.fromRGB(18, 11, 31)
label.TextColor3 = Color3.new(1, 1, 1)
label.TextScaled = true
label.Visible = false
label.Parent = gui

local messageCount = 0

-- No player parameter here: the server already chose who receives it
notify.OnClientEvent:Connect(function(message: string)
	messageCount += 1
	local thisMessage = messageCount
	label.Text = message
	label.Visible = true
	task.delay(4, function()
		if messageCount == thisMessage then -- hide it unless a newer message replaced it
			label.Visible = false
		end
	end)
end)

The client does not need to guard against the server: only server code can fire OnClientEvent. The message: string annotation is for the type checker; it is not a runtime check.

Pattern 3: server to all clients

FireAllClients sends the same message to every connected player. It takes no Player argument, and each client receives it on the same OnClientEvent as before, so the NotifyClient script from Pattern 2 already shows it.

This Script announces to everyone when a player first touches a finish line. Add an anchored Part named FinishLine to Workspace, then add the Script to ServerScriptService.

local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local notify = ReplicatedStorage:WaitForChild("Remotes"):WaitForChild("Notify") :: RemoteEvent
local finishLine = workspace:WaitForChild("FinishLine") :: BasePart

local finished: { [Player]: boolean } = {}

finishLine.Touched:Connect(function(hit: BasePart)
	local character = hit:FindFirstAncestorOfClass("Model")
	local player = character and Players:GetPlayerFromCharacter(character)
	if not player or finished[player] then
		return -- not a player, or already announced
	end
	finished[player] = true

	-- Every connected client runs its OnClientEvent handler with this text
	notify:FireAllClients(`{player.DisplayName} reached the finish!`)
end)

Players.PlayerRemoving:Connect(function(player: Player)
	finished[player] = nil
end)

FireAllClients reaches only the players connected at that moment. Someone who joins a second later never sees the message. That is right for one-off moments, such as an announcement, an explosion effect or a sound, but wrong for state such as a round timer or the current game phase. For state, set an attribute on the server, for example ReplicatedStorage:SetAttribute("TimeLeft", 30), and read it on the client with GetAttribute and GetAttributeChangedSignal("TimeLeft"). Attributes replicate to every client, including players who join later.

RemoteFunction: when the client needs an answer

A RemoteEvent is fire and forget. A RemoteFunction makes the caller wait: InvokeServer pauses the code that called it until the server's OnServerInvoke function returns, then hands back whatever it returned. Use one when the client cannot carry on without the answer, such as "was that code valid?". When you do not need a reply, Roblox recommends a RemoteEvent, because it does not wait.

Example: a box where players type a reward code. The server holds the codes, checks the text, and returns two values: whether it worked, and a message to show.

1. In ReplicatedStorage.Remotes, insert a RemoteFunction named RedeemCode.
2. In StarterGui, insert a ScreenGui named CodeGui, and inside it a TextBox named CodeBox. Size and place it where you like.
3. Add the Script below to ServerScriptService, and the LocalScript inside CodeBox.

local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local redeemCode = ReplicatedStorage:WaitForChild("Remotes"):WaitForChild("RedeemCode") :: RemoteFunction

-- Codes live on the server, where no player can read them
local CODES: { [string]: number } = {
	LAUNCH = 100,
	THANKYOU = 50,
}
local MAX_LENGTH = 20
local COOLDOWN_SECONDS = 2

local usedCodes: { [Player]: { [string]: boolean } } = {}
local lastTry: { [Player]: number } = {}

-- Assign with =. OnServerInvoke is a callback, not an event you Connect to.
redeemCode.OnServerInvoke = function(player: Player, code: unknown): (boolean, string)
	local now = os.clock()
	local last = lastTry[player]
	if last and now - last < COOLDOWN_SECONDS then
		return false, "Wait a moment before trying again"
	end
	lastTry[player] = now

	if type(code) ~= "string" or #code == 0 or #code > MAX_LENGTH then
		return false, "Type a code first"
	end

	local key = string.upper(code)
	local reward = CODES[key]
	if not reward then
		return false, "That code doesn't exist"
	end

	local used = usedCodes[player]
	if not used then
		used = {}
		usedCodes[player] = used
	end
	if used[key] then
		return false, "You already used that code"
	end

	local leaderstats = player:FindFirstChild("leaderstats")
	local coins = leaderstats and leaderstats:FindFirstChild("Coins")
	if not (coins and coins:IsA("IntValue")) then
		return false, "Coins aren't set up in this game yet"
	end

	used[key] = true
	coins.Value += reward
	return true, `Code accepted: +{reward} coins`
end

Players.PlayerRemoving:Connect(function(player: Player)
	usedCodes[player] = nil
	lastTry[player] = nil
end)

local ReplicatedStorage = game:GetService("ReplicatedStorage")

local redeemCode = ReplicatedStorage:WaitForChild("Remotes"):WaitForChild("RedeemCode") :: RemoteFunction
local box = script.Parent :: TextBox

local GREEN = Color3.fromRGB(46, 204, 113)
local RED = Color3.fromRGB(231, 76, 60)

box.FocusLost:Connect(function(enterPressed: boolean)
	local code = box.Text
	if not enterPressed or code == "" then
		return
	end
	box.Text = ""
	box.PlaceholderText = "Checking..."

	-- InvokeServer pauses this function until the server's callback returns.
	-- pcall keeps the LocalScript running if the call fails.
	local ok, accepted, message = pcall(function()
		return redeemCode:InvokeServer(code)
	end)

	if ok and type(message) == "string" then
		box.PlaceholderText = message
		box.PlaceholderColor3 = if accepted == true then GREEN else RED
	else
		box.PlaceholderText = "Something went wrong, try again"
		box.PlaceholderColor3 = RED
	end
end)

Why InvokeClient is risky

A RemoteFunction also works the other way, with InvokeClient on the server and OnClientInvoke on the client. Roblox's documentation lists three serious risks:

• If the client's callback throws an error, the server throws the error too.
• If the player leaves while being invoked, InvokeClient throws an error.
• If the client never returns a value, the server script waits forever.

A modified client controls its own callback, so a cheater can cause the third one on purpose and hold that server thread for as long as they like. To update a player's screen, use FireClient. If the server really needs information from a client, fire a RemoteEvent, have the client reply on another RemoteEvent, and treat a missing reply as a normal case on the server.

Validate every argument on the server

An exploiter can fire any RemoteEvent or invoke any RemoteFunction, as often as they like, with any arguments. The one thing they cannot fake is the first parameter: Roblox fills in the Player who sent it. Everything after that must be checked before the server acts on it. Hiding the remote or checking in the LocalScript does not help, because the cheater controls their own client.

NaN deserves its own warning. It is a number, so type(x) == "number" passes, but every comparison with it is false, so a check like x < 0 or x > 100 lets it straight through. math.isfinite(x) rejects NaN and both infinities.

Know the limit of a distance check. Each client controls the physics of its own character, so an exploiter can move their character next to the target before firing. The check still stops the easy abuse of acting on the whole map from one spot. Keep target parts anchored too: Roblox's security docs note that an exploiter can take network ownership of unanchored parts near them and pull those parts close, which gets round a distance check.

Here are the same checks as a ModuleScript you can reuse in every remote handler.

local Players = game:GetService("Players")

local RemoteGuard = {}

-- A real number between min and max. Rejects NaN and infinity, which pass a
-- plain type(x) == "number" check.
function RemoteGuard.number(value: unknown, min: number, max: number): number?
	if type(value) ~= "number" or not math.isfinite(value) then
		return nil
	end
	if value < min or value > max then
		return nil
	end
	return value
end

-- A whole number between min and max, for counts, indexes and quantities
function RemoteGuard.integer(value: unknown, min: number, max: number): number?
	local n = RemoteGuard.number(value, min, max)
	if n and n % 1 == 0 then
		return n
	end
	return nil
end

-- Text with a length cap. utf8.len returns nil for invalid UTF-8, which data
-- stores reject.
function RemoteGuard.text(value: unknown, maxLength: number): string?
	if type(value) ~= "string" or #value > maxLength or utf8.len(value) == nil then
		return nil
	end
	return value
end

-- An Instance of the expected class, inside the container you allow.
-- A table built to look like an Instance fails the typeof check.
function RemoteGuard.instanceIn(value: unknown, className: string, container: Instance): Instance?
	if typeof(value) ~= "Instance" then
		return nil
	end
	if not value:IsA(className) or not value:IsDescendantOf(container) then
		return nil
	end
	return value
end

-- True when the player's character is within maxDistance studs of position
function RemoteGuard.isNear(player: Player, position: Vector3, maxDistance: number): boolean
	local character = player.Character
	local root = character and character:FindFirstChild("HumanoidRootPart")
	if not (root and root:IsA("BasePart")) then
		return false
	end
	return (root.Position - position).Magnitude <= maxDistance
end

-- A per-player rate limit. Each player may make `burst` calls at once, and
-- earns back `perSecond` calls every second. Returns a function to call
-- before doing the work: it answers true (go ahead) or false (too fast).
function RemoteGuard.limiter(burst: number, perSecond: number): (Player) -> boolean
	local buckets: { [Player]: { tokens: number, updated: number } } = {}

	Players.PlayerRemoving:Connect(function(player: Player)
		buckets[player] = nil
	end)

	return function(player: Player): boolean
		local now = os.clock()
		local bucket = buckets[player]
		if not bucket then
			bucket = { tokens = burst, updated = now }
			buckets[player] = bucket
		end
		bucket.tokens = math.min(burst, bucket.tokens + (now - bucket.updated) * perSecond)
		bucket.updated = now
		if bucket.tokens < 1 then
			return false
		end
		bucket.tokens -= 1
		return true
	end
end

return RemoteGuard

And here is the Pattern 1 handler rewritten with it. Replace the contents of PaintServer:

local ReplicatedStorage = game:GetService("ReplicatedStorage")
local ServerScriptService = game:GetService("ServerScriptService")

-- ":: any" only matters to Luau's strict type checker; it changes nothing at runtime
local RemoteGuard = require(ServerScriptService:WaitForChild("RemoteGuard")) :: any

local paintRequest = ReplicatedStorage:WaitForChild("Remotes"):WaitForChild("PaintRequest") :: RemoteEvent
local paintable = workspace:WaitForChild("Paintable")

local PALETTE = {
	Color3.fromRGB(231, 76, 60),
	Color3.fromRGB(46, 204, 113),
	Color3.fromRGB(52, 152, 219),
	Color3.fromRGB(241, 196, 15),
}
local canPaint = RemoteGuard.limiter(4, 4) -- a burst of 4, then 4 a second

paintRequest.OnServerEvent:Connect(function(player: Player, partArg: unknown, colourArg: unknown)
	local part = RemoteGuard.instanceIn(partArg, "BasePart", paintable) :: BasePart?
	local colourIndex = RemoteGuard.integer(colourArg, 1, #PALETTE) :: number?
	if not part or not colourIndex then
		return
	end
	if not RemoteGuard.isNear(player, part.Position, 30) or not canPaint(player) then
		return
	end
	part.Color = PALETTE[colourIndex]
end)

What you can and can't send

You can pass numbers, strings, booleans, Roblox types such as Vector3, CFrame, Color3 and Enum items, Instances that both sides can see, and tables of those. Some values change or disappear on the way:

A good habit is to send identifiers rather than objects or values: the name of an item, the index of a choice, a part the server can look up and check. The server then works from its own data.

Why a RemoteFunction returns nil

If InvokeServer gives you nil, work through these in order:

1. A path with no return value. Every way out of OnServerInvoke must return something. A bare return in an early check sends back nil.
2. A return inside a nested function. A return inside pcall(function() ... end), a :Connect handler or task.spawn only leaves that inner function. Capture the result, for example local ok, data = pcall(...), then return data from the callback itself.
3. A value that cannot cross. A function, or an Instance the client cannot see (anything in ServerStorage, for example), arrives as nil. With instance streaming on, a part the server has just created may not have reached the client yet when the function returns.
4. Another script set the callback. Only the last assignment to OnServerInvoke runs. Search your scripts for the remote's name.

If the call never returns at all, no script has set OnServerInvoke yet (Roblox queues the calls until one does), or the callback is stuck, for example on a WaitForChild for something that never appears.

UnreliableRemoteEvent: for constant, throwaway updates

An UnreliableRemoteEvent has the same methods and events as a RemoteEvent: FireServer, FireClient, FireAllClients, OnServerEvent and OnClientEvent. The difference is that Roblox guarantees neither delivery nor order. A message can be dropped, without being resent, when:

• it is lost in transit, or waits too long on a congested network
• its payload is larger than 1,000 bytes
• a client fires faster than the rate limit (the excess is dropped, not delayed)
• no handler is connected when it arrives (it is discarded, not queued)

Messages can also arrive out of order, and they have no ordering relationship with your RemoteEvents or RemoteFunctions. Use one when only the newest value matters and the next update is a fraction of a second away: where a player is aiming, the position of a cosmetic effect, a value that changes every frame. If order matters, put a sequence number or timestamp in each message and ignore anything older than the last one you handled.

Never use one for something that must happen exactly once, such as a purchase, damage, a reward or a round starting. And validate its arguments on the server exactly as you would for a RemoteEvent.

Delivery order and rate limits

Roblox's delivery guarantees apply to one connection in one direction: the server to one client, or one client to the server.

• RemoteEvents are reliable and ordered. Lost messages are resent while the recipient stays connected, and messages arrive in the order you fired them, even across different RemoteEvents. If the server fires A, then B, then A to a player, that player receives A, B, A.
• Order is about when handlers start. If a handler yields, for example with task.wait or WaitForChild, the next message can start being handled before the first one finishes.
• RemoteFunctions and RemoteEvents are not ordered against each other. If your code depends on strict order, send related messages through the same remote type, or add your own sequence number.
• Property and attribute changes are not ordered against remotes. If the server changes a property and then fires a remote, the client may see either first. Listen for the change itself, for example with GetPropertyChangedSignal, rather than assuming it has arrived.
• No handler yet. RemoteEvent messages queue until a handler connects. The queue has limits: once it is full, further messages are discarded and Output shows a Remote event invocation discarded error.
• A player who leaves loses any messages that had not reached them yet.

Rate limit. RemoteEvent and UnreliableRemoteEvent messages from a client to the server are throttled at about 500 requests per second per client, as documented on 30 September 2026. The limit is shared by every remote of the same type, so splitting one busy remote into ten does not raise it. Past the limit, RemoteEvent messages are processed later and keep their order, while UnreliableRemoteEvent messages are dropped. The engine limit does nothing to stop one player firing your remote 50 times a second, so every handler that changes something still needs its own per-player limit.

RemoteEvent, RemoteFunction, UnreliableRemoteEvent or attribute?

For a full example of RemoteFunctions and validation working together on something players pay for, see how to make a shop GUI.

Common errors and fixes

Most remote problems show up in the Output window (open it from the Window menu or the Script tab). Check it first, then match the symptom below. The script errors guide covers the general error messages in more depth.

Build it with RoCode

You can also have RoCode set this up in the place you have open. RoCode is an AI agent that works through a Roblox Studio plugin, so it creates the remotes and scripts in your Explorer rather than giving you code to paste.

RoCode does not start playtests. Press Play yourself and try to break the checks, for example by painting from across the map. If something errors, Check Output can read the Server and Client lines from your last playtest. How RoCode connects to Studio.

Questions

Sources and further reading

• Roblox Creator Docs: Remote events and callbacks. FireServer, FireClient, InvokeServer, InvokeClient risks, argument limitations and delivery guarantees
• Roblox Creator Docs: Securing the client-server boundary. Validation layers, NaN, rate limiting, client-to-client relays
• Roblox Creator Docs: Security and cheat mitigation tactics. What a modified client can do, and server authority
• Roblox Creator Docs: Network ownership, movement validation, and physics. Why a client controls its own character, and the limits of distance checks
• Roblox Engine API: RemoteEvent. Throttling limit and the invocation discarded error
• Roblox Engine API: RemoteFunction. OnServerInvoke, InvokeClient warnings and streaming precautions
• Roblox Engine API: UnreliableRemoteEvent. The 1,000-byte payload limit
• Roblox Creator Docs: Properties and attributes. Replication order between property changes and remote events

How the code was checked: every script on this page passes Luau's strict type checker against Roblox's API definitions (luau-lsp, 30 September 2026). A type check catches misspelt APIs and wrong types, not game logic, so play-test in Studio before you publish.