UI Designer

Updating a UI, and security

Made a better design? You can install it over the old one and keep all your code. This page shows what an install changes, how to update each way, and the rules that stop exploiters from giving themselves free stuff.

Your code lives in the hook scripts#

Keep your game code for a UI in its two hook scripts (or in your own scripts), never inside the runtime or the blueprint:

• <Name>_UIHooks, a LocalScript in StarterPlayer > StarterPlayerScripts: what happens on the player's screen.
• <Name>_ServerHooks, a Script in ServerScriptService: everything that gives, sells, checks or saves.

Every export includes them, written from your design by UI.Blueprint.Integration and tagged with your UI's name (the attributes BloxUIHooks, BloxUIHooksSide and BloxUIHooksHash). The tags let an install tell your edited scripts apart, so it never overwrites a hook script you've edited. Leave the attributes on.

What an install changes#

Update with Send to Studio (easiest)#

1. Export the new design on the website (Getting started).
2. Open your place in Studio and go to the BloxMaps Cloud plugin's UIs tab. Press Refresh.
3. Press Insert next to the new design. If something looks wrong, Ctrl+Z undoes the whole install.
4. Run your Command Bar edits again (product ids, logo text, colours), because the blueprint was replaced.
5. Press Play and test.

Update with a .rbxmx file#

1. Download Add to my game (.rbxmx) for the new design and drop it into Studio. A folder BloxUI_<Name> appears in Workspace.
2. In that folder, delete <Name>_UIHooks and <Name>_ServerHooks. Your own copies are already in the right places.
3. Delete the old ReplicatedStorage.BloxUI_Blueprints.<Name>, then drag the new <Name> StringValue from the folder's BloxUI_Blueprints into ReplicatedStorage.BloxUI_Blueprints.
4. Replace ReplicatedStorage.BloxUI with the folder's BloxUI, so you have the newest runtime.
5. With Extras: replace ServerScriptService > BloxGame and StarterPlayerScripts > BloxGame with the ones in the folder's BloxUI_Extras (keep your own GameSettings if you edited it), and tick Enabled on BloxGame > Main.
6. Delete the rest of the folder (the extra loader and BloxUI_Setup).
7. Run your Command Bar edits again, then press Play.

When the new design has new buttons#

A new design can fire events or sell products the old hook scripts have no handler for. For Remote actions Output tells you, with lines such as no handler for "Rebirth".

• You haven't edited the hook scripts: Send to Studio replaces them with the new design's. Nothing else to do.
• You have: your scripts are kept, so get fresh ones next to them and move your code over.

1. Rename your two hook scripts, for example to NeonStrike_UIHooks_old and NeonStrike_ServerHooks_old, and turn off their Enabled box.
2. On each, delete the BloxUIHooks attribute (Properties window > Attributes). Without it, installs no longer treat them as the UI's scripts.
3. Send the UI to Studio again: fresh hook scripts are added. (Or make them with the Command Bar block in If the scripts are missing.)
4. Copy your code from the old scripts into the matching handlers of the new ones, or ask an AI to (how).
5. Test, then delete the _old scripts.

If the new design has a different name#

The loader builds every UI in BloxUI_Blueprints, so an old and a new UI with different names both show up. To switch to the new one:

1. Stop the old UI from being built: select ReplicatedStorage.BloxUI_Blueprints.<OldName> and set its Enabled attribute to false in the Properties window, or delete it.
2. Your hook scripts wait for the UI by name (UI.Blueprint.waitFor("<OldName>")). Move your code into the new UI's hook scripts, as in When the new design has new buttons.
3. Delete the old hook scripts, so only one UI.Server.start runs.

Security: the client asks, the server decides#

Exploiters can change anything on their own device: LocalScripts, the UI, the values it sends. They can't touch your server scripts. So:

What UI.Server already does for you#

• Prices come from the server's own copy of the blueprint. A player can't change what something costs.
• Buying with coins or gems is refused until the player's data has loaded, then the currency is taken and the item given on the server.
• The BloxUI_Action remote is rate-limited (20 events a second per player) and every message is shape-checked before your handler sees it.
• Server-only events such as Purchase and Bought:<itemId> can't be fired by a client.
• Robux purchases are only marked as done after the grant and the purchase id are saved together, and game passes are checked with Roblox, not with what the client says.
• Spins, cases and rewards are rolled and decided on the server.

What you do in your handlers#

• Check every value a client sends in UI.Server.on handlers: its type, its range, and whether the player is allowed (enough coins, owns the item, cooldown over). The generated stubs start with these checks: keep them.
• Never trust an amount or price from the client. Work it out on the server.
• Never give things from notification events (Purchase, Bought:...). They tell you something already happened.
• Give each Robux purchase once. Remember the purchase id and return true from onReceipt only after the player really has the item (how).

-- WRONG: the client says how many coins to add. An exploiter sends 999999.
UI.Server.on("ClaimCoins", function(player, elementId, payload)
	UI.Server.grant(player, "coins", payload.amount)
end)

-- RIGHT: the server decides the amount and checks the cooldown.
local lastClaim = {}
UI.Server.on("ClaimCoins", function(player, elementId, payload)
	local now = os.time()
	if lastClaim[player] and now - lastClaim[player] < 60 then
		return -- too soon: ignore
	end
	lastClaim[player] = now
	UI.Server.grant(player, "coins", 50)
end)

More examples of checked handlers are in Scripting your UI.