C would still collide with B in this case; this constraint doesn’t affect Collision Groups at all.
So in other words this is a Collision Management Feature for non Scriptures.
Awesome, Now I don’t have to do everything!
Yesterday here’s me thinking that Roblox won’t be getting a new constraint for me to add to my constraint GUI. Today, this releases . This seems awesome though and could really open up new opportunities for things like one way doors and platforms.
This will be very useful for ragdoll, or just messing around with it with stop motion or something, I could imagine. Thanks for the constraint update!
In the car example, what was the setup of the wheels? I feel like the constraint is being used to disable collisions between an entire assembly and the main body of the car.
A welcome update though. I’ll most likely still be using CollisionGroups more than this, but it’ll help immensely in cases where I need to filter collisions without using up CG space.
This seems like it will be very useful, seems like I need to get to work on learning how to fully utilize it.
Thanks for adding this! I didn’t realize how useful it would be until I ran into a problem with vehicles that were made for Roblox’s old physics solver. Now I don’t need to waste collision groups to fix them
This new function will greatly help a project I’m working on
Can we get one of theses in reverse as well?
Such as a part is CanCollide = false, but with say CollisionConstraint (Instead of NoCollisionConstraint) we can have those two parts collide, but every foreign part will not collide?
Sounds a lot like Collision Groups, but this would also be exportable as a model as well as NoCollisionConstraint. Interesting things to think about🤔
Does this constraint use up some of your collision group count? I don’t imagine it would since there could potentially be more than 32 in a game but just checking.
This looks really neat, I’d have to mess around with this sometime, it looks extremely handy to have.
In the car example, the Constraint is still just part-to-part. The car has a large MeshPart along the underside of the car with some problematic collision geometry. The wheel is also just a single part that would scrape against this bottom part. The NoCollisionConstraint is being used to prevent those from colliding and not use a collision group so the car can still be shared on the toolbox.
But you’re right that if you want to have whole assemblies not collide with other parts (prevent cars from hitting stop signs and trees), Collision Groups are a better solution.
No, this acts separately from collision groups.
What’s your constraint GUI? I’d love to hear more!
Interesting indeed… Do you have a specific use case?
This can be very useful for my products, thanks.
This is awesome, I’ve been waiting for this for a while! Thanks!!
We had to disable the portion of this feature that changes the CanCollideWith API. This function is now back to only returning accurate results with respect to the canCollide property and collision groups.
The NoCollisionConstraint is still functional, but using CanCollideWith on two parts connected by a NoCollisionConstraint will return true.
Yes, I have a specific use case.
I attached two base parts to a ball. (One base on top, one base on bottom.)
The ball is programmed to roll towards players, but with the two base parts being CanCollide true, the ball is prevented from moving through the base. (The base needs to be CanCollide true in order to enact the ‘squishy’ feature of the ball.)
That is where a use of the NoCollisionConstraint comes in.
BUT the second issue requires the players to be able to collide with the ball, and not collide with the base parts. (Touching the ball is meant the eat/kill the player.)
Anyway this is all very confusing to understand so to put it in simplest form:
Everything is resolved by setting the two baseparts to CanCollide = false, but the base parts need to be able to collide with eachother to prevent unwanted clipping. This can be achieved with a constraint that allows only them two parts to collide.
Here is a demonstration file.
The Red ball is the solution, but because the two base parts are unable to collide with eachother, the ball clips through the world.
The Green ball is the result of the two base parts set to CanCollide = true, but the ball itself, is set to false. (Resulting in the ball being unable to roll due to the base.)
If I had a CollisionConstraint (Instead of NoCollisionConstraint) I could allow the Red ball to roll across the map, while having a flexible squish to the impact of the terrain.Ball.rbxl (19.8 KB)
Super happy that this feature was released, been waiting for something like this for forever it feels like.
You could set limits on your prismatic (or spring) rather than relying on collisions to stop the two plates from clipping through each other. So your ball is canCollide = true and the two plates are canCollide = false. Limits should also let you set a sort of max and min size for the squishy ball, and be a bit more reliable than collisions.
Would this solve the issue?
EDT: No wait, sorry, that wouldn’t work. I guess I still don’t totally understand. You said the red one would work if the two plates could collide with each other and not anything else, but wouldn’t you need them to collide with the ground to have it stay. Not sure how you could get the ball to roll on the ground but also have the plates collide with the ground to have the “bouncing” behavior work.
Heck, I’m creating the thing and I can’t even understand it. I’m trying to get it to work they way I want as I develop it.
I do suppose your right though, I guess what I’m trying to accomplish is virtually impossible with the methods I’m using…
Heads up everyone! The API change that was disabled has been re-enabled! This also fixed an issue where the NoCollideConstraint would not work with Touch events.
The whole change is now on and should be functioning normally, let me know if it looks like it’s not!