I got a message:
WARNING:GAMESYS: The collision group ‘autofire’ could not be used since the maximum group count has been reached (16).
Can I to increase this number (max group count) or not?
1 Like
Unfortunately no. From the docs:
Group
The name of the collison group the object should belong to. You can have 16 different groups and you name them as you see fit for your application/game. For example “players”, “bullets”, “enemies” and “world”.
The groups are part of a bitmask for fast processing, and as such it’s not an easy thing to expand it to more bits.
2 Likes
I would like to ask if you are planning to increase it someday or not at all? Just to be sure if I need to redesign things or wait?
The situation hasn’t really changed.
It don’t think this is something we’ll prioritise anytime soon.
And to be honest, 16 groups are quite a lot.
What are you using using them for, perhaps we can suggest other ways of solving it?
1 Like
Ok, so I tried to prepare different triggers to cause different reactions. So I prepared many game objects with collision objects with different groups and then checked for message.other_group in scripts that should interact with each of those collision “trigger” objects.
Now I need to resolve it in other way, because I reached out this limitations with my groups. I think that making one group for all of this collisions that should trigger some diverse actions, but differentiate them with some game object’s property and send message from the collided trigger object with its type, instead of handling it only by the object that collides into this trigger. Or do you think about other approach?
I usually use a script property for this, with a hashed name that you can check just like a physics group. You can have as many different names as you want, and in the long run I think it is easier to manage than a lot of physics groups. (you don’t have to update all of your collision objects every time you add a new one, etc.)
If you need one object to be in multiple groups then this won’t work. In that case I would make a small lua module to store the list of groups for each object. Just a table keyed by object ID with a list of groups. Each object can add their list to the module on init and remove it on final, and any other object can simply get the target object’s ID and get it’s group list from the module.
I tend to avoid back-and-forth messages. Each message has a performance cost that is higher than calling a function or accessing a table. Also they don’t happen immediately, and can theoretically spill over into the next frame if you have too many of them.
3 Likes
And if I could ask, how do you correctly create a script property that is a hash? Because I am always using msg.url() for this.
1 Like
Like this:
go.property("foo", hash("bar")) -- or just hash("") for the hash of an empty string
2 Likes
Thank you very much! 
I stumbled on this as well. Have a lot of boxes for my world collision. Guess I am not using that right? What is a good way to create collision for your world without stumbling into this?
Simply read the replies to this thread. Workarounds were explained.
I had missed that tilesources could have collision in it. so I had created 50+ collision boxes in a collision object to map the tiles in a collection.
Fixing the tilesource with collision solved it for me.
2 Likes