Can anyone explain this thing? I can't get my head around the concept.

Explain what exactly ?

This part. There are numbers for each permission. How does that work? What is the bit system? How can you figure out permissions? Why is this system chosen? Etcetar

Hmm a lot of questions in 1 sentence:
- Why is this system chosen?
I don't have the faitest idea, but i guess one consideration mught have been that you can store a lot permissions inside a releative small row.
- There are numbers for each permission. How does that work? How can you figure out permissions?
They are defined in your includes/init.php. You can check there for the value of each permission.
- How does that work?
Well already said it is a bit-system. In a bit system (or binary) you only write number as a combination of 0 and 1.
Just a small example:
The decimal number 1 would be a 1 in binary.
The decimal number 2 would be a 10 in binary.
The decimal number 3 would be a 11 in binary.
The decimal number 4 would be a 100 in binary.
The decimal number 5 would be a 101 in binary.
etc... search on the net for more basic info on how to work with binary calculations

If we now use every bit of that binary number to indicate 1 permission, we could build up a number like:
Binary: 1101001 (decimal 105)
We can now store this in database as a decimal 105 in only 3 positions. But we got 7 bits (permissions) we can set or retrieve.
Now we can test this number to see which bits are set, if a bit is set, we consider this a yes permission, otherwise a no.

So permissions 1101001 could decode like (reading the number from right to left, starting with bit 0)
bit 0 == 1, so permission 1 is set
bit 1 == 0, so permission 2 is set
bit 2 == 0, so permission 3 is set
bit 3 == 1, so permission 4 is set
bit 4 == 0, so permission 5 is set
bit 5 == 1, so permission 6 is set
bit 6 == 1, so permission 7 is set

thank you. It does help a bit. I wanted to know this in case of adding a new permission to the system without messing up the existing permissions and scared of conflicting with future permissions vb might assign in the future. I'm scared adding a permission will mess up some code somewhere because of not understanding the system too well.

If I get you correctly, this new usergroup system makes hacking permissions much more questionable for future compatibility. If they are up to 256 and we add one, it isn't like naming a variable $mydwhhackedvariable. You have to go with their numbering and are likely to collide unless you choose a very high number. But do you lose flexibility by choosing a high number?

Well you could use a high number, as long as it is a multiple of 2, thus reducing the risk of a future clash. Best would be to let the user who is installing calculate the next free number himself, but this would still mean there is a risk if a new standard permission is used somewhere in the future that there are already permissions set for this new option in the database (consider S'Admin would be a new permission based on this system, using a number you previously used for a custom "Can use PM", a lot of user would suddenly turn into S.Admin, but this would be worsed case scenario).

A better way is to create a new custom permission group in the init.php. Now you can create a group only for you and your hacks to use, without ever interfering with others. It will take a bit more coding though, but not so much.

Search in your includes/init.php for:
and after that add some lines like:
Then you will have to add the field 'myhackpermissions' to the usergroup table, so the value can be stored (no coding needed for that i think).

Thank you. Do you think the extra field in usergroup might cause performance issues?

No that will not cause performance problems.

It would be different if you wanted to create a new table for storing your own permissions. Tehn you would need extra queries.

what a handy thread, this will come in very handy next week.

Best advice for usergroup permissions:
Don't extend existing bitfields!

Sooner or later this will cause problems.