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
4 Likes
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.
3 Likes
I see, and this is still the problem if you set network ownership to the player on the rocket?
1 Like
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.
3 Likes
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…
Hi, I tested a bit and this are my results:
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 (without script):
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… ?
1 Like
Has this bug involving Click Detectors on high moving parts been resolved yet?
Because I am very sure it still exsists.
1 Like
I never was able to solve the problem. I think it still exists…
It does still exist, proximity prompts with the click feature seems like the only alternative right now.
1 Like
It has nothing to do with network ownership.
My guess is that ClickDetectors are being updated in the wrong step in the engine’s Task Scheduler. And yes, the issue is still present.
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.
2 Likes
Would love Roblox to resolve this problem ASAP because this is a main problem in my game, where the vehicle cannot be tapped when moving.
3 Likes
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.
It would be great if this got fixed, its been an issue forever.
1 Like
Yeah figured it out with proximity prompts. Not completely satisfied though.
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.
1 Like
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.
1 Like
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.
I’m bumping this post because it is really annoying that the roblox engineers still haven’t addressed this issue, this bug can also be seen with the recently added physical draggers that do not take into account fast moving objects.