Hello guys,
I wanted to make a rocket. On top of the rocket I placed a sear and some buttons with a click detector.
When I tested the rocket in roblox studio, then the click detectors of the parts worken great.
When I startet with the rocket, then the click detectors worked also fine.
But as faster I got with the rocket as more bugging got the click detectors. When I got slower with the rocket, then the click detectors worked again.
When I was fast with the rocket, then the “click detector mouse image” switched fast between both and the click-mouse-image was not on the part, but near the part. The image moved like 1-2 studs away from the clickdetector part. I was not able to take an image of it, sorry.
After a specific velocity the click-mous-image was completly away. With “click-mouse-image” I mean this here:
Summary: When you reach a specific velocty with an unanchored part with an click detector on it. Then the click detector stops working and it begins to bug around.
Where the bug happens: It happens on fast moving parts with an click detector. When it started happening: It started happening on a specific velocity. Screenshots and videos of the bug:
I was not able to get a picture of the bug. But here is a video: robloxapp-20200619-1543062.wmv (4,2 MB) On the video I am always clicking. If the click detector would work, then the Textlabel (“V10” for example) should change.
Here is the rocket: Rocket.rbxm (58,9 KB)
Steps to reproduce the issue:
Place in Roblox Studio a Basepart.
Place on the BasePart a Seat and a second part with a clickig detector
Weld everthing togheter with WeldConstraint
Make sure everthing is Anchored = false
Add a BodyForce to the BasePart and set it as high as the little self created rocket starts to fly. Make the Force value higher and higher, till you should be able to see the click detector bug.
I hope I gave enough details. If you need more details, then be free to ask!
PS: Sorry if the Video file is a download file
Thanks for the report! Just to be clear, do you mean when the rocket moves quickly, but you are seated on it the click detectors no longer work? Basically are the controls from your point of view stationary? If you set NetworkOwnership to your local client for the rocket, does it work? Network Ownership | Documentation - Roblox Creator Hub
The click detectors do work, but the ClickDetector seems to be further ahead than it’s rendered position especially when moving at high velocities. This has been somewhat of an issue for a very long time, but nobody really discussed it until now, which is this very topic.
It only really makes the problem worse due to the fact that you have total control over it, meaning it’ll always have physics updates instead of relying on network updates. The ClickDetector “hitbox” as you may call it updates before the rendering updates.
Sorry, I was on holidays and I wasn’t online.
I tried to click the button when I was sitting and without. It never worked on fast velocity.
But Network-Ownership I didn’t tried. I will try it. Then I say if it works…
I enabled ShowNetworkOwner and this are the results that I got. I don’t know what the colors means, but I think green is the player, white is the server and red… I don’t know what red is.
When I stand near the rocket:
When I sit on the rocket (with scripts):
It changed nothing… I set with the script the NetworkOwner, this didn’t helped for the not working Button.
I stand for around 1 minute afk and when I switched from desktop back to Roblox Studio, then every part was green. Even a 100 studs unanchored part. This is weird…
Here is one of the scripts that I used for the NetworkOwner:
Script inside
local VehicleSeat = script.Parent
VehicleSeat.Changed:Connect(function(prop)
if prop == "Occupant" then
local humanoid = VehicleSeat.Occupant
if humanoid then
local player = game:GetService("Players"):GetPlayerFromCharacter(humanoid.Parent)
if player then
VehicleSeat:SetNetworkOwner(player)
end
else
VehicleSeat:SetNetworkOwnershipAuto()
end
end
end)
I also found this on the Roblox DevHub. So I don’t know if the Stuff of the ClickDetector is NetworkOwner related… ?
ClickDetector mouse detection updates presumably at the Heartbeat step of each frame, which is this:
This means that ClickDetector mouse detection updates after physics handling. CFrame changes that happen after RenderStepped and physics will cause this issue to happen, as the mouse raycast / detection for any ClickDetectors happens after rendering (which is where camera updates are issued).
This is further indicated by the fact that where my mouse is and where the button is, yet somehow detecting a ClickDetector within the red part despite not having my mouse over it shows that it is an issue.
(The two images above shows a platform moving at 500 and 2000 studs respectively. The detector gets more offset as it goes faster. The platform is moving in the direction of the button from the center of the platform itself.)
That being said, the way that this can be fixed is simply to move the ClickDetector logic to the rendering step of each frame rather than the physics step. For developers who are currently using ClickDetectors and are currently suffering from this issue, perhaps they could remake the ClickDetector until a fix for this is dispatched.
Same, however I’d suggest that you just use a custom system for the time being (it’s not a good idea to rely on Roblox to fix something that hasn’t been fixed in years). You can just make a raycast and highlight on the client side so if the raycast comes within contact of a bigger part (for example a sphere) parented to the part you want to activate then the highlight will highlight the bigger part’s parent and you can fire a remote asking to run code for that part. Alternatively just use inputs or proximity prompts.
I’m assuming the problem is that the physics of the click detector are before the rendering and there may be some network lag which is why the click detector is clickable in the position where it will be and not where it is.
Was going to make my own post but found this old thread before I did. I’m running into this issue right now, with both click detectors as well as raycasting from the mouse location. The client character is inside of a moving vehicle (an airplane) that is updating every heartbeat. I’m trying to allow them to hover over some cabinets to open/close them, but this issue keeps forcing the wrong cabinets (multiple studs to the right of the intended ones) to be triggered. We’d rather not use proximity prompts in this specific case because we’re already using them for many things nearby and there’s a lot of cabinets clustered together.
Tbf, you could theoretically listen for MB1 input and raycast from the camera towards their mouse but apply an offset to the raycast’s origin by the airplane’s AssemblyLinearVelocity which should give you pinpoint accuracy in scenarios where velocity wouldn’t’ve previously been compensated for.
Yes, that’d work, I just don’t think it should be necessary and so would prefer for it to be fixed for convenience, unless there’s some sort of major consequence of them moving the order in which these things are processed in relation to the physics updating.
Edit: Actually, the planes are pivoted so it’s not as simple as accessing the AssemblyLinearVelocity because it remains at (0, 0, 0) the whole time so we have to calculate velocity ourselves, which is simple enough to do but just adds on to the inconvenience of this a little bit.
Also just to clarify since I saw your reply underneath but don’t want to make another post - the velocity is very small. The plane isn’t even in the air - it’s just taxiing very slowly on the ground and the issue is still majorly noticeable at extremely slow speeds.
Yeah, I feel the same way, wrt this being inconvenient, however the offset between physics and input caused by high velocity is w/o a doubt an edge case. There likely is consequences in altering the frame step order.
Additionally, I assume that when Click Detectors were initially implemented, they hadn’t considered the possibility that devs would use them on fast moving assemblies.
