Each part would have a bitmask as in:
A: 0101
B: 1100
A Collision between two parts acts as if both were CanCollide=false if the bitwise and of A and B is nonzero (both masks have at least a single bit that is 1 in both masks)
This could be added on top of the existing cancollide feature as in
CanCollide=true/false
CollisionGroupA=true/false
CollisionGroupB=true/false
where the CanCollide property overrides the collision group/mask system if its false
etc.
Or it could be added as more cancollide params
CanCollide=true/false
CanCollide1=true/false
CanCollide2=true/false
where CanCollide would act as a single bit of the mask.
Both would be backwards compatible.
Possible usages:
-Making games becomes easier for nonscripters, because this lets you do some logic that normally is done using scripts.
-Doors that only let some things through
-A Sea could share a collision mask bit with boats, so noobs can just check a checkbox on a car and they have a boat that can drive on the sea while everything else sinks. Unless they use terrain. But terrain is limited.
-Personally I have a tree with branches and leaves, and id like the branches to not collide with the leaves when theyre detached, but i still want them to collide with everything else. Because branches in real life dont really collide with leaves but go through, but do collide with harder surfaces.
-You could make some kind of smoke/liquid out of spheres that collides with other smoke and the environment but doesnt collide with players and mobile items
-You need this to make more complicated mechanical things easily (if roblox wants to go in that direction in the first place…)
-You can build a big physical object to lets say keep a train on the tracks, without anyone knowing it exists since they cant touch it or see it if its transparent.
Its not really a must but even a 1-2 bit mask would allow some interesting things to be made. As well as make stuff behave better (so i can make my branches not collide with leaves and a train stay on the tracks using an invisible support thingy that can go through the ground but still collides with tracks)
So like the Jenga map off of Halo Reach (wow old game now) where there are supporters at the bottom that hold up the Jenga props in the air as if CanCollide = true but when players try to walk on the they fall through as if CanCollide were off?
Collision groups does not interact well with free models / other collaboration. That’s probably why it hasn’t been added yet. It takes very careful planning to use collision groups correctly, something that most Roblox users don’t have. And then you’ll end up with “Why are all my collisions all screwed up??” from newer users.
Unfortunately, it’s not as simple as you’re making it out to be. There’s a lot of room for “silent errors” that show up much later when using collision groups.
For instance, suppose that you’re making some game and you have a vehicle, that uses collision groups A and B to make sure that a couple parts of the vehicle do not internally collide (a common use for collision groups). Now, later, you copy-paste that vehicle into another level. You have some other stuff in the level that’s also been copy-pasted from other sources. How do you verify that all collisions actually work correctly? You can easily end up with your vehicle suddenly snagging on some effects from another thing where it shouldn’t because it’s collision groups accidentally collide with those collision groups.
Overall it does take careful planning on the user-side to use collision groups no matter how they’re implemented.
I dont see free model compatibility as a problem. Free models are compatible with each other only as long as the interactions have been defined by roblox. CanCollide is one such thing with a well defined purpose.
If the free model interacts with the outside world through scripts, it will probably break something. If the free model interacts with the outside world through collision groups, it will probably break something.
If you want to make them compatible, the free models must be configurable (tell it what collision groups to use) or you must manually go and poke around the scripts. You already need to do this.
Collision groups wont cause problems with free models if the place is normalish and the free models behave well.
They will be a problem if the place heavily utilizes them and has all sorts of free models that interact with each other and the environment, but that never worked too well anyways.
If roblox did assign clear purposes to the different collision groups, it would allow free models to be compatible in the rare cases they actually used collision groups. I dont know, a background collision group and a foreground collision group?
In that case it would be easier to add Model.PrivateCollisions or a new class “CollisionModel” extending “Model”.
All parts in that model would ONLY (be able to) collide with each other (if .CanCollide is true).
Of course,as they still can be welded (using JointInstances or surfaces) to other parts, they just act normal.
If you have a car in this model (or Model.PrivateCollisions set to true) it would drive trough everything.
(Well, just make sure your ground you’re driving on also is part of the model)
Another addition on that, especially with that street-case above would be:
If 2 of such models are in each other, as with the following hierarchy:
-- Model A
----- Part A
----- Model B
-------- Part B
----- Model C
-------- Part C
→ Part B wouldn’t be able to collide with Part C
→ Part B/C would be able to collide with Part A
That way it would be (much) easier to define collision groups, and link them to each other.
The idea of assigning a “collision id/bitmask” isn’t really… welcome
[quote] In that case it would be easier to add Model.PrivateCollisions or a new class “CollisionModel” extending “Model”.
All parts in that model would ONLY (be able to) collide with each other (if .CanCollide is true).
Of course,as they still can be welded (using JointInstances or surfaces) to other parts, they just act normal.
If you have a car in this model (or Model.PrivateCollisions set to true) it would drive trough everything.
(Well, just make sure your ground you’re driving on also is part of the model)
Another addition on that, especially with that street-case above would be:
If 2 of such models are in each other, as with the following hierarchy:
-- Model A
----- Part A
----- Model B
-------- Part B
----- Model C
-------- Part C
→ Part B wouldn’t be able to collide with Part C
→ Part B/C would be able to collide with Part A
That way it would be (much) easier to define collision groups, and link them to each other.
The idea of assigning a “collision id/bitmask” isn’t really… welcome [/quote]
The problem with this one is that parts can only have on parent, and currently the way you organize parts does not affect how they behave physically. If it did affect their behavior, it would no longer be possible to use models to organize parts in whatever way makes the most sense.
Of course it wouldnt be an actual bitmask, but instead a checkbox for each bit, which isnt too difficult to use since it basically does the same thing as CanCollide and CanCollide is a checkbox too.
