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?
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.
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)
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.
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!
