When the default RibbonTool’s Select, Scale, Rotate, and Move are used a large performance drop is noticeable in Roblox studio when the cursor is hovering over dense groups of parts. This Studio breaking bug seems to be directly connected to the CanQuery property of Parts. An issue only Roblox engineers can address.
Skip to ‘Cause & Reproduction’ for a theory on the cause of this issue & repo.
Example:
In the clip below you will notice that with the tool selected, there is no performance issue while the cursor is not hovering over the models. However performance drops significantly when the cursor is hovered over dense models.
Steps I have already taken to address the issue.
The usual questions asked by bug report handlers.
I Uninstalled & Reinstalled Roblox Studio.
I reset my Studio settings to Default.
I copied the models in a different game/baseplate (The clip shown). And tested on new models.
I tried lowering my graphics settings.
I Disabled future lighting and tested again.
I tested on a different device.
I disabled my Plugins.
I tested my device’s performance.
I can run the game fine with the graphics up in Play.
The game runs fine when the aforementioned tools are not selected in Studio. Proof:
Cause Theory & Reproduction.
Cause & Reproduction.
Based on the behavior of the performance drop. I have noticed a direct correlation with the use of CanQuery Property in parts.
TO REPRODUCE: Create a dense model and disable CanQuery on all of its parts.
Hover cursor above the front face of RED parts (CanQuery Enabled) You will notice no lag.
Hover cursor above the front face of the BLUE parts (CanQuery Disabled) You will notice a significant performance drop.
Settings/Notes:
-There are 6 models in each row. Each containing 64 parts.
-Compatibility lighting is enabled.
-GlobalShadows disabled.
-CastShadow disabled in parts.
-CanCollide disabled in the parts.
-Massless Enabled
-Anchored is true.
-This is a scaled down version. The effect is multiplied for any large projects or builds.
Not to knock the engineers responsible for creating this feature. But when the parts are all set to CanQuery disabled. The performance is extremely degraded and unmanageable when hovering groups of parts with the cursor.
When all parts have CanQuery Enabled, The issue does not occur.
Concluding note:
I hope this information is satisfactory. This issue needs to be addressed as soon as possible. My games using CanQuery disabled are now un-editable in Roblox studio.
I can confirm it, I tried it with my own servers and I just nearly crashed my roblox because of this. The video i attached shows what is going on.
The Task Scheduler is quite literally screaming for help when I change CanQuery on ALL parts to false.
We will have a change to imporve CanQuery disabled performance in studio next week.
For now the best option is to temporarily enable CanQuery for parts in Studio. You can have a script that re-disables CanQuery at runtime if you need it for gameplay purposes.
I have been experiencing this studio bug in a large city game I’ve been developing and spent majority of my day trying to figure out the cause. Through trial and error I eventually discovered this same bug:
Having CanQuery set to false on a large number of parts will make developing in studio nearly impossible because of the huge amount of lag and stuttering that occurs when hovering over models/parts. The more parts that have CanQuery set to false, the worse the issue becomes. The CanQuery property exists to improve performance in-game but ironically decreases performance in studio.
Edit: Nevermind, I just noticed the Roblox team is already aware of the problem haha
I just recently noticed issues selecting parts too. Sometimes when I alt+click to select a single part inside a model, it will select a completely different part behind the model (past the part I’m trying to select). Started noticing this yesterday around when this change was made.
Yea the new selection bug is a bit more prevalent. I’m disabling the performance fix.
Remember, if you are facing Studio performance issues due to CanQuery parts in your place, you can workaround by having a script re-enable CanQuery and tag all the parts. Then another script can disable CanQuery on all the tagged parts at runntime.
Once the fix is enabled again you can put it all back.
For any non-programmers out there, here’s the code I’m using to disable/re-enable this temporary fix.
Fix performance (In studio command line):
local CS = game:GetService("CollectionService")
for _,D in pairs(game.Workspace:GetDescendants()) do
if D:IsA("BasePart") and not D.CanQuery then
D.CanQuery = true
CS:AddTag(D,"CanQueryFalse")
end
end
Add back CanQuery false (In server script or command line once issue is fixed):
local CS = game:GetService("CollectionService")
for _,Item in pairs(CS:GetTagged("CanQueryFalse")) do
if Item:IsA("BasePart") then
Item.CanQuery = false
CS:RemoveTag(Item,"CanQueryFalse")
end
end
The performance fix has been updated and enabled again. Studio performance with lots of CanQuery=false parts should be significantly improved, nor should you run into selection issues.
You can revert your Part properties back to how they were before. Let me know if there’s still issues.
This change appears to have completely screwed with selecting and moving stuff unfortunately. I’ve attached a video of it happening.
The object I mess with is a model with a woodplank part and a meshpart frame. The woodplank part has CanQuery turned off and it will occasionally completely sink input so it doesn’t even register as an option to select it and clicking won’t select the part behind it. I’m pretty sure I’ve even somehow selected something on the other side of a part.
I’ve tried restarting studio multiple times and it doesn’t solve the issue. However, opening a new baseplate and pasting one of my affected house models into it doesn’t seem to have the issue so it almost seems place specific? If you need a copy of the affected place I can send it over DMs.