This may cause some issues related to exploiting for shooting games, as instead of having to manipulate metatables and stuff like that to achieve wallbang, now all a exploiter has to do is set canquery to false on walls
4 Likes
Well, that’s your fault for relying on the client in the first place.
9 Likes
Roblox has been killing it with these updates as of late.
4 Likes
but I see nothing…
Instead of hiding the property entirely, I think it should be greyed out (read only state) instead so people know it exists, then you can unlock the property when CanCollide is false.
This should probably be a setting though since some users might be annoyed to see a property they don’t use often
16 Likes
im not talking about my own game, i’m talking about games like arsenal
2 Likes
This will be really helpful. I had a game with a lot of locked parts and it was difficult to work on, as you had to position the camera in odd ways to click on parts that weren’t locked.
2 Likes
It seems like I have found a bug with the CanQuery property in places with Team Create enabled, whenever I disable CanQuery it works and I can play test and it works there but if I exit the team create session and go back in the CanQuery magically re enables itself (I was the only one in the team create session when this happens).
CanQuery also doesn’t work in the Roblox application (not sure if its only enabled in studio or its a bug)
5 Likes
This is a great addition that I would definitely suggest taking advantage of. When raycasting for weapons or lighting effects, I would always have to create a blacklist table for various random things that I don’t want the raycast to interact with such as invisible blocks. Being able to check a box for a base part makes it so much more convenient for workflow. Love the feature!
2 Likes
I love performance improvements. I originally had to check if parts had CanCollide enabled and then I’d add them to a blacklist and with this it’s practically killing a thousand birds with one stone because looping through workspace everytime a player fires a bullet to perform these checks was horrible on performance.
Anyways I’m curious, if CanCollide, CanTouch, and CanQuery are all disabled, how much performance is being saved? Is it worth it to go through all parts that don’t need any collision at all and disable all three of them?
Also I can’t find a solid answer to something else collision related;
- Is there a benefit to setting CollisionFidelity to Box even if CanCollide/CanTouch/CanQuery is already disabled? Or is that a waste of time?
Definitely needed, good idea!
Additional Feedback:
It was already suggested but can the CanQuery option just be greyed out instead of completely disappearing from the properties tab?
3 Likes
hit detection is worse on the server, iirc?
1 Like
So if CanQuery is false raycast will ignore it?
1 Like
Not only raycasts, but things like region3, getpartsinpart, etc…
3 Likes
That is perfect, so we do not have to make ignore list anymore.
2 Likes
The server in general should never trust what the client does or says and game critical code (i.e anything that can affect other players) should never be run on the client if possible or at the very least be validated on the server.
3 Likes
This is a super cool update, but I’m not sure why CanQuery requires CanCollide to be off?
I know this is a rather unusual usecase, but a while back, I tried developing an isometric deathmatch game, but I ran into a problem where invisible walls (primarily used to keep players inside of indoor spaces without obscuring vision) would still be hit by raycasts from weapons, causing players to shoot towards the camera instead of towards their target. It would be very useful to be able to disable spatial query methods while still retaining player collision.
11 Likes
Have you tried creating an ignore list when raycasting?
https://developer.roblox.com/en-us/api-reference/function/WorldRoot/Raycast
3 Likes
Pretty cool update. Very useful for raycast.
1 Like
I believe it saves on loading times, since all the collision data the client needs to download for that mesh is a simple box
1 Like
I agree with this reply.
Currently I have a Coin Generator that covers a map, currently it’s too hard to determine which Part is a floor, and which is a roof. It would be very beneficial for me and builders to disable CanQuery without disabling CanCollide because obviously I don’t want players jumping out of / falling into buildings through the roof.
I also want / need RayCast to ignore my invisible map barricades.
Limiting our ability to use this new property by tying it to a different one is bad design, CanQuery is less usable in it’s current state.
Have you tried it before because It’s a pain to use and I wouldn’t recommend it to anyone.
Especially for @fighterbuilder’s use case. They have to constantly add new BaseParts into workspace which the IgnoreList you suggested doesn’t update (Immutable) and will cause problems and complications. By simply allowing us to use CanQuery without any restrictions would be a lot easier and starter friendly.
Here’s the hacky code I have to use to get achieve what I want for my game
local WorldRootIgnoreLists = {}
local function getIgnoredPartsForWorldRoot(worldroot: WorldRoot)
if not WorldRootIgnoreLists[worldroot] then
local IgnoredParts = {}
for _, descendant: Instance in ipairs(worldroot:GetDescendants()) do
if descendant:IsA("BasePart") then
local BasePart: BasePart = descendant
if not BasePart.CanCollide or BasePart.Transparency == 1 then
if not CollectionService:HasTag(BasePart, "Raycast_WHITELIST") then
table.insert(IgnoredParts, BasePart)
end
end
end
end
WorldRootIgnoreLists[worldroot] = IgnoredParts
end
return WorldRootIgnoreLists[worldroot]
end
local function handleIgnoredPartsForWorldRoot(worldroot: WorldRoot)
if not WorldRootIgnoreLists[worldroot] then
local IgnoredParts = {}
for _, descendant: Instance in ipairs(worldroot:GetDescendants()) do
if descendant:IsA("BasePart") then
local BasePart: BasePart = descendant
if not BasePart.CanCollide or BasePart.Transparency == 1 then
if not CollectionService:HasTag(BasePart, "Raycast_WHITELIST") then
table.insert(IgnoredParts, BasePart)
end
end
end
end
worldroot.DescendantAdded:Connect(function(AddedDescendant: Instance)
if AddedDescendant:IsA("BasePart") then
local BasePart: BasePart = AddedDescendant
if not BasePart.CanCollide or BasePart.Transparency == 1 then
if not CollectionService:HasTag(BasePart, "Raycast_WHITELIST") then
table.insert(IgnoredParts, BasePart)
end
end
end
end)
worldroot.DescendantRemoving:Connect(function(RemovedDescendant: Instance)
if RemovedDescendant:IsA("BasePart") then
local BasePart: BasePart = RemovedDescendant
table.remove(IgnoredParts, table.find(IgnoredParts, BasePart))
end
end)
WorldRootIgnoreLists[worldroot] = IgnoredParts
end
end
function raycastUtil.Raycast(worldroot: WorldRoot, Origin: Vector3, Direction: Vector3): RaycastResult?
raycastParams.FilterDescendantsInstances = getIgnoredPartsForWorldRoot(worldroot)
return worldroot:Raycast(Origin, Direction, raycastParams)
end
5 Likes
Hey @kleptonaut, I am unsure on whether this is a recent issue, but I have noticed raycasts being inacurate for my game; they intersect with objects they should otherwise be unable to.
I am unsure on whether you are apart of the Bug-Support group, but I have sent a PM to them elaborating on the issue: https://devforum.roblox.com/t/raycasts-are-inaccurate-intersecting-objects-they-should-be-unable-to/1453850
1 Like