Prompts and effects

The default Roblox prompt is replaced by a BillboardGui of your choosing. Four styles ship, and holding it fills a progress bar.

The four types

Type1 = { template = "uxrDoorCustomPrompt1", fill = "vertical", spin = true },
Type2 = { template = "uxrDoorCustomPrompt2", fill = "vertical" },
Type3 = { template = "uxrDoorCustomPrompt3", fill = "horizontal" },
Type4 = { template = "uxrDoorCustomPrompt4", fill = "vertical" },

Type1 also rotates its BorderFrame five degrees and back when the hold completes, which is the spin flag.

The four BillboardGui templates live under uxrDoorCustomPrompts in the shipped uxrDoorGui. Restyle them freely, and keep the instance names above: each is looked up individually and a missing one is skipped rather than erroring.

Choosing a type

DefaultUIType = "Type1",

The key display

The label adapts to what the player is using:

The prompt instance in the world owns the keybind, so change KeyboardKeyCode there rather than in config.

The hold

The hold duration comes from the ProximityPrompt instance's own HoldDuration, not from config. Set it in Studio, per prompt.

Releasing early tweens the bar back to zero over 0.2 seconds rather than snapping it, so a half-press reads as a half-press.

A completed hold is guarded by 0.2 seconds, so the door cannot be double-triggered by one press.

Sizing

PromptScale = 1,

Billboards are sized as a fraction of screen height rather than a fixed pixel size, so they look the same on a phone and on a 4K monitor:

factor = clamp(viewportHeight / 1080, 0.8, 1.25) * PromptScale

The clamp keeps small screens from getting unusably tiny prompts and large screens from getting comically large ones. PromptScale multiplies the result: 1.2 for bigger prompts, 0.85 for smaller.

Resizing the window recalculates it live.

The label

A door prompt reads OPEN DOOR when the door is closed and CLOSE DOOR when it is open, updating live as the door's state changes for anybody, not only for you.

The terminal prompt uses its own ActionText, falling back to ACCESS.

The highlight

Looking at a door adds a white Highlight drawn on top of geometry, fading in over 0.3 seconds and out again when you look away.

Highlight = { fillTransparency = 0.8, outlineTransparency = 0.3, color = Color3.fromRGB(255, 255, 255) },

Those values match what the client uses, but the client does not read them: the fill, outline and colour are fixed at 0.8, 0.3 and white. Editing this table has no effect.

The uxrHighlight tag is defined in Settings.Tags and is likewise unused: the highlight is applied to the whole door model.

The beam

A Beam named uxrDoorBeam placed inside a door's HandlePart links the door to the player while the prompt is showing. The client attaches its far end to your HumanoidRootPart and detaches it when the prompt hides.

Doors with no such beam simply have none. The per-door beam field and Settings.Beam.enabled are not read: the beam exists exactly when you built one.

Give the Beam its own Attachment0 inside the handle. The system supplies only Attachment1.

Mobile

On a touch device an on-screen button is created while a prompt is showing, and removed when it hides. Pressing it starts the hold; releasing it cancels; holding it long enough completes.

The touch path uses a timer rather than the prompt's own trigger, so the fill bar and the action stay in step on a phone.

Refusal reasons

Requests that fail return a reason:

The shipped client does not surface these as text. The lights and sounds are the player's feedback. The reasons are there for you to build a notification on if your game wants one.