Proximity Prompt Studio Beta

Updates Announcements
,
#83

When used inside of an attachment, is it intended to behave the same as if you parented it to the attachment’s parent part? I have an attachment inside of a part with a proximity prompt inside the attachment, but it’s no different than if I were to parent the proximity prompt to the part. My initial expectation was that it would use the world position of the attachment, and would be very convenient if it did as I don’t always want a prompt to be overlapping the part itself.

I’m aware there’s a property for offset on the screen, though it doesn’t help for 3D offset.

#84

I’m very excited for this. Hope it comes out of beta soon.

3 Likes
#85

I think this is missing 1 level of abstraction. Internally, somehow this is triggering an action when you get within proximity under xyz conditions. This is a helpful functionality beyond just UI prompts. Currently, it seems the “action” in this case is enabling/disabling a gui, and the “condition” is line-of-sight checking. There are many more use cases for doing an action when a player is within proximity under xyz conditions, like triggering some game event (e.g. fire a turret when a player is nearby with the condition that they are from an enemy team).

This can of course be done with other scripting methods like checking distance periodically, or whatever other methods a developer comes up with. But, if this new proximity prompt feature is doing something more efficient than what a developer can write, this ability to trigger an action on proximity entered is important for a developer to be able to tap into.

In this case, the conditions are checking line of sight… can this one be configured? What if we want to use our own raycasting parameters to ignore certain objects, can this service still be used?

Perhaps this can still be used in a hacky way to accomplish more generalized proximity triggering, such as listening for enabled state changed on the UI, but direct support for this would be great. (Unless I am misunderstanding and it already exists! :))

13 Likes
#86

Thanks for the feedback! The 3D position of the attachment is indeed supposed to work. When you move the attachment around, it doesn’t move the prompt? If not, would it be possible for you to send me a message with a rbxl demonstrating the problem?

1 Like
#87

A very good update. This will probably completely phase out invisible hitboxes and distance checks every (n) seconds for me. Thank you a lot :+1:

3 Likes
#88

Is this any much more performant than someone doing a constant magnitude checking script for interaction which is the normal way to achieve this?

I’d imagine it being more efficient to performance of course but I’d like to know how much it could be.

4 Likes
#89

Shoot, just after finalizing my own proximity prompt…

This was a much needed feature. We now don’t need to make super complex code for interactions!

5 Likes
#90

I reopened studio and set it up again but I can’t reproduce it anymore, may have just been a mistake on my end. It uses the position of attachment just fine, thank you.

#91

It shows a keyboard key on the prompt:

image

How will we change the image for mobile?

I’m guessing that something like this (left for PC, right for mobile)

image
image1450×750 127 KB

Does it automatically sense what device you’re on and show the correct one?

1 Like
#92

Yea that’s what’s happening to me too. Just so happens it also occurs in third person too but only when you hold right click and turn your camera to the prompt the same problem happens when you cant move your mouse properly anymore.

robloxapp-20201030-0304192.wmv (3.4 MB)
sorry for the bad quality recorded it in roblox studio where the gameplay screen would be smaller lol

#93

This is one of the big features I’ve been waiting for. A game I’m working on is very interaction heavy and the type of game (which a lot of other people are vested in as well) have also been looking into proximity inputs but have trouble doing so. Native support will make this so much easier to facilitate.

I can also finally get rid of the implementation in my game that uses 3 scripts and OOP, which has on numerous occasions given me a bit of a headache. I’m expecting, if the beta goes well, to do rapid changing to this built-in method. It’s much more expansive, customisable and full of features than what I have now. I’m especially grateful for the amount of event-driven opportunities this presents.

Still doesn’t hold a candle to the DataStore updates we were promised at RDC which will make me explode with joy, but it’s still a great step. Proximity inputs are much loved in a lot of types of games but sometimes are troublesome to get down.

I’ll be waiting for news on how the beta goes and if anyone encounters any exploiter issues before I make the move. It’s seriously critical in confronting my technical debt.

8 Likes
#94

@crypto_mancer i got an infinite yeld on this, i inserted a ProximityPrompt inside my model, this code is supposed to make a humanoid run an animation when the interaction gets triggered:

local hum = script.Parent:WaitForChild("Humanoid")

local anim = hum:LoadAnimation(script:FindFirstChildOfClass("Animation"))

workspace.Steamder.ProximityPrompt.Triggered:Connect(function(player)

anim.Looped = false

anim:Play()

end)

Any way to solve this?

Thank you

1 Like
#95

Thanks for checking out the beta, and thanks for catching this issue! We’ll address this.

1 Like
#96

Here’s a fun hack:

You can probably fashion a jank region system out of this kinda like this suggestion

You could do custom streaming or custom ambience based on the closest part and just not use Triggered for anything.

-- localscript
local Lighting = game:GetService("Lighting")
local ProximityPromptService = game:GetService("ProximityPromptService")

ProximityPromptService.PromptShown:Connect(function(instance)
    local parent = instance.Parent
    
    Lighting.Ambient = parent.Color
    Lighting.OutdoorAmbient = parent.Color
end)

proximityRegionHack.rbxl (25.7 KB)

53 Likes
#98

Thanks for trying out the feature! I can’t be sure what is causing this issue. Is this script definitely a sibling of an object called “Humanoid”? Can you put prints in to determine which line it’s yielding forever on?

#100

this’ll make things much easier

I don’t understand the old ways of proximity detection

1 Like
#101

honestly never expected any updates like this to roblox that tend to be scripted by the developer,
I made a system similar to this that I’m using in multiple games and it looks like I’ll probably need to port over to this eventually as it seems identical in functionality but will obviously have better support

#102

Oh, sorry i solved it, i tried writing and deleting things :sweat_smile:

This is the new code:

local hum = script.Parent.Parent:WaitForChild("Humanoid")

local anim = hum:LoadAnimation(script:FindFirstChildOfClass("Animation"))

workspace.Steamder.ProximityPrompt.Triggered:Connect(function()

anim.Looped = false --the animation still being looped

anim:Play()

end)

But now the animation is being looped, idk why, but it is supposed to happen? @crypto_mancer

Also, i found a small error, in the image, look closer at the wheel, its image its cutted
Dia

5 Likes
#103

Found an Issue, feel free to test this yourself. If the brick with proximity prompt is in the lighting or starter player scripts, (pretty much anywhere that’s not the workspace BESIDES Server Storage) the Prompt still shows.

image
image1223×508 392 KB

The Task Brick in Lighting has a Proximity Prompt in it.

3 Likes
#104

This is actually very possible from using ProximityService like GollyGreg mentions above. Here’s a quick example of it that I got set up in a couple of minutes.

https://streamable.com/aygokn

For this example, I put a ProximityService instance in each collectible part, and set its Style property to Custom, so that no Gui pops up. I also set the MaxActivationDistance to 5.

-- LocalScript
local ProximityPromptService = game:GetService("ProximityPromptService")
ProximityPromptService.PromptShown:Connect(function(instance)
	local parent = instance.Parent

	if parent.Name == "Collectible" then
		parent:Destroy()
		print("Collected!")
	end
end)

As you mentioned, it’s slightly hacky as it listens for the changed state, but honestly it works pretty great :happy2:

5 Likes