[FIXED]bPermissions breaks PlayerJoinEvent and PlayerLoginEvent permission functionality

After much testing and work, I have reached the conclusion that bPermissions breaks the ability to perform accurate permission checks upon PlayerJoinEvent and PlayerLoginEvent.

While testing some permissions based features in my plugin Ban On Death, I was facing a weird occurance where permission checks weren't working, even if I gave myself the permission via command moments before joining. After all this, I decided that I must be using the wrong event, and need to change both my event and priority. After PlayerJoinEvent with the Priority of Highest didn't work, I decided to check the source code of bPermissions, and figure out exactly what I need to listen for. Then, I stumbled upon this:
https://github.com/codename-B/bPerm...rmissions/imp/SuperPermissionHandler.java#L97
This means that permissions are set up 1 tick AFTER PlayerLoginEvent, which also removes the functionality of permissions checking in PlayerJoinEvent*. Therefore, in order to use permissions with bPermissions, you need to schedule a runnable to run 2 ticks after the event, in order to ensure that the player has been given permission.

Although I'm sure this was implemented to reduce the impacts of setting up permissions when players join, it has serious negative effects, and effectively breaks plugins such as Ban On Death. I suggest that until codename_B changes this, plugin developers be aware of this, and either change their plugin to fix this or inform users of this plugin that their plugin isn't compatible with bPermissions.


* I have confirmed that both are called within the same tick in the CB code.

 

The most likely reason is that maybe permissions can't be registered before the player actually logs in, and since the event gets called before the player actually logs in he has to wait a tick.

Of course, there could be another reason entirely, but I can assure you that one of those reasons is not to mess with other plugins. Also, it's a little rude to call out an author like this, and could to considered spam to post what seems to be a rant about a specific plugin in the plugin development section of the forums when it has almost nothing to do with development (there are other ways to contact an author than tagging them in a rant).

But to try and keep this relevant to development, my recommendation would be to make some type of a file that saves the banned player so that you will be able to prevent the player from even logging in, and you won't depend on another plugin to accomplish a task.

 

I posted this not to call out another author, but to bring up a valid issue relevant to developers. Anyone using bPermissions to test their plugins will come across weird errors, and developers also may receive reports of issues where there really shouldn't be any. This is a serious issue, and people need to be made aware of it.

Other permissions plugins don't need this delay to setup permissions. Two good examples are Privileges and PEX(despite it's faults).

As for the issue on Ban On Death, I use permissions to determine which tier a player is in, which is relevant to displaying the correct message, as well as giving them the proper amount of lives. Without the permissions, it defaults to the default tier, which then causes players to get the default number of lives, even if they're a donator who should be getting 1,000 lives.

This post also isn't spam, I asked mbaxter before posting this. Once again, it comes down to informing the Bukkit Community that not all plugins are compatible with bPermissions.

 

evilmidget38 I don't actually do that anymore, I did that in 2.9.17 as a trial thing, to see about performance improvements.
It's been gone for a version.

I will admit, it's entirely my fault for not pushing the latest changes to github.

 

Thanks for addressing and changing this. If it's been fixed, a mod can lock the thread maybe?

 

You could edit your title to like "[FIXED]" or something?

 

Sure.