Changing input types creates a new Prompt Gui

Bug Reports Engine Bugs
,
1

I’m setting up custom prompt gui’s and noticed that if I change input type, it ends up clearing the old one and creating a completely new one?

Expected behavior

The UI should just adapt to the most recent input type. There’s no need to delete and recreate the entire UI just for a single image change.

1 Like
2

This seems to be an issue with how ProximityPromptService handles the PromptShown event. It triggers once again when, as you reported, changing input types.

local function onLoad()
	ProximityPromptService.PromptShown:Connect(function(prompt, inputType)
		print(inputType)
		if prompt.Style == Enum.ProximityPromptStyle.Default then
			return
		end
		local gui = getScreenGui()

		local cleanupFunction = createPrompt(prompt, inputType, gui)

		-- Wait for either the prompt being hidden or destroyed
		local yield = Instance.new("BindableEvent")
		local con = prompt.PromptHidden:Connect(function()
			yield:Fire()
		end)
		local con2 = prompt.Destroying:Connect(function()
			yield:Fire()
		end)
		yield.Event:Wait()
		con:Disconnect()
		con2:Disconnect()

		cleanupFunction()
	end)
end

onLoad()

Interestingly enough this also creates an unused-past-usage BindableEvent. Cumbersome!

3 Likes
3

Hello, thanks for the report!

This is intentional behavior.
The way to customize a ProximityPrompt is to listen to the ProximityPrompt.PromptShown and ProximityPrompt.PromptHidden events to show/hide your prompt with the appropriate input type. When input changes, this will in fact clear the old one and create a new one.

There is no API to allow an existing prompt UI to modify from, say, keyboard input to gamepad input. If such an API did exist, it would need to be something like this:

ProximityPrompt.InputTypeChanging

In addition to writing the initial code to create the UI, developers would need to handle every switch between all input types. This introduces additional complexity and would be a burden on developers customizing UI, which could lead to errors.

We believe the additional complexity here is not worth the minimal performance gain.

Let us know if there is anything else needed.

4

Little off-topic, but think you could take a look at this age-old report on the same feature?

1 Like
5

From my testing though, changing any property to the ProximityPrompt doesn’t create a new UI. So you still have to listen for these changes to update your custom UI appropriately anyway?