-
Notifications
You must be signed in to change notification settings - Fork 0
Check Methods
The goal of the framework is to help plugin developers perform restriction checks without each plugin having to implement and update its own processes for handling Restriction Plugin API queries.
Currently, this framework is new and under development. The following restriction systems are already supported:
- WorldGuard (version 7.x.x)
- PlotSquared (version 7.x.x)
Note
More will follow in the future.
This framework supports a different approach to checking building rights: A restriction check by send a fake-event call to the server.
Querying all rights plugins is currently inperformant and not completely correct due to the different scenarios (e.g. custom WorldGuard flags like allow-break-blocks of RedWorldGuardFlags or custom features via add-ons for BentoBox). At the end, we are interested in whether the player is allowed to build / interact at the corresponding location or not. So, it's possible to use a test event to check whether the player is allowed to build at the target locations.
Judging by the latest tests, this check works well to verify the permission of the player for the specified location with the target Action-Type. The new check may be more correct for some cases, as it simply reflects the test result and does not refer to the theoretical processes of the individual restriction plugins.
I would like to point out that I am primarily looking for the best and safest option. In this case, it also seems to be the simplest solution. Provided it works equally well with all supported plugins. ▪ RedstoneFuture
Unlike an API query, the event call cannot perform “silent queries.” The event is fired as it would be in the case of normal player behavior. As a result, depending on the restriction plugin, the player will also receive a message if they do not have the permissions to build or interact.
For the ActionType INTERACT, the target block must actually be interactable in Minecraft. For the other interaction types, the block doesn't matter and may even be AIR.
Warning
To ensure that the event cancellation is handled correctly, the restriction plugin must never call event.setCancelled(true). This is not the case with the currently supported restriction plugins and should generally be avoided.