Cuberite Forum

<- worktycho responded to your post.

I got another idea for the permission group system. What about a permission blacklist? The server first checks if the permission is in that list and if it is then cPlayer:HasPermission returns false. If it isn't in the blacklist then it continues doing what it was doing before.

I'm perfectly fine accepting a performance increase of halving the time necessary. But going from 10 seconds to under a second? That seems too far-fetched.

Found the issue with the original code, SQLite would dump each operation to disk, which was slowing things down. After wrapping the entire migration into a transaction, the whole thing works under a second, too. Maybe my work computer has a much faster disk access (doubtful, doesn't look it).

I have no idea what you're proposing. But everytime there's a whitelist and a blacklist together, there's the problem of items that are on neither list - are they allowed or not?

Well for example you want a group that has all the WorldEdit permissions but you don't them to be able to load craftscripts. You simply put "worldedit.*" in the normal permissions and then put "worldedit.scripting.execute" in the blacklist.

That actually makes sense and a pretty good use-case. The blacklist would work as a pre-filter, having higher priority than the whitelist.
Will the BFUA (BFU-Admins ) be smart enough to understand such a system?

We could try implementing a small tutorial button in the webadmin page

(08-13-2014, 09:18 PM)xoft Wrote: [ -> ]That actually makes sense and a pretty good use-case. The blacklist would work as a pre-filter, having higher priority than the whitelist.
Will the BFUA (BFU-Admins ) be smart enough to understand such a system?

Everyone that comes from Bukkit or Spigot and is using there Permissions System or a Bukkit/Spigot plugin like "GroupManager" or "PEX" will understand, how to use a white and blacklist in MCServer.

Very well then, I shall implement that.

I decided not to implement it just yet, I first want to get the UUID system all sorted out so that it works, and only then add new features. I put this idea into the issue tracker, so that it isn't lost:
https://github.com/mc-server/MCServer/issues/1331

I've just found out quite a huge problem with the ranks handling - there is a possibility for a mismatch for player UUIDs when the server is offline - some methods use the player's UUID, which is the offline one, others don't have access to the UUID (because they don't have the cPlayer object available) so they use the cMojangAPI class to look up the UUID, and they work with the online UUIDs. I'll need to fix this somehow, probably mostly in the Core.