Multiverse-Core

Multiverse-Core

6M Downloads

[Bug]: Lazy loading of permissions causes mv.bypass.gamemode.* not to work.

Remodactyl opened this issue · 5 comments

commented

/mv version -p output

https://paste.gg/0f14b8bc98dc4ad0b735614998539bdd

Server logs

Contains classified information

Server Version

This server is running Paper version git-Paper-521 (MC: 1.19.4) (Implementing API version 1.19.4-R0.1-SNAPSHOT) (Git: bcec5b1)\nYou are 29 version(s) behind\nDownload the new version at: https://papermc.io/downloads/paper\nPrevious version: git-Paper-502 (MC: 1.19.4)

Bug Description

We use lazy loading for our permission system because our network makes use of great numbers of permissions.
This is to prevent lag-spikes on large numbers of players joining and not something we can readily change.
This, however, causes multiverse to not be able to read the mv.bypass.gamemode.* permission in time for the player-join event and in turn causes our staff to always join the server in inconvenient gamemodes upon relogging, (switching worlds afterwards while staying online works fine!)

The permissions.yml file is unfortunately not an option with our system so we are looking for a way to disable the gamemode enforcement check in our worlds by default, either for certain groups, operators, or if need be, in general as we have other methods of enforcing gamemodes.
I understand there used to be such options in multiverse but they were understandably removed in favor of the player permissions method.

I have already confirmed MultiverseCore is the plugin that is altering our gamemodes through its debug output.
What methods do you recommend that would work with our lazy-loaded permissions, and if there are none, would you still be open to adding a per-world enforcegamemode: true/false parameter to the worlds.yml configs?

Steps to reproduce

N/A.
We use our own custom permission system and this issue is unlikely to affect many other users or your developers.

Agreements

  • I have searched for and ensured there isn't already an open or resolved issue(s) regarding this.
  • I was able to reproduce my issue on a freshly setup and up-to-date server with the latest version of Multiverse plugins with no other plugins and with no kinds of other server or client mods.
commented

Unless this is a general issue (as it seems not to be) I think your best bet would be to fork the project. I don’t think adding config options is a direction we as a team want to go

commented

I have already made my own jar for this plugin with the IsOp() check added into that method, though I definitely think this is a limitation to keep in mind.
If the decision is not to add such an override in config, we can mark this post as closed, but eventually there will likely be other people with the same problem. It's very possible some have already experienced the same issue, but not known how to debug it.

commented

Are there any public plugins that use your permission system? If there’s no way to reproduce this then it’ll be difficult to try and build a workaround

commented

Permission plugin should load the player's permission before the playJoinEvent. Good permissions plugin like luckperms can do it and it has been use by large servers. Maybe look into how luckperms plugin handles their caching and loading from db.

commented

There are not, it is custom built by our network devs, hence the reason I'm suggesting a default way to disable the gamemode bypass check under certain circumstances (such as Op, or config).
In searching for the issue I've come across many posts asking for the same feature to be added back, but unsuccessfully as this would be deemed redundant. We now have a use-case in which it would genuinely serve a purpose, which is to cover rare edge cases like these.
We used to have our permissions loaded in before the world join event, without lazy loading, but this generated a lot of unnecessary strain during big events with lots of players, so if we have to make that choice we will sooner stick with building our own version of MultiverseCore upon updating. I suppose at this point this can be considered a feature request! =)