-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Leaderboard deactivator no longer works #68
Comments
This is likely a regression from when I rewrote the command system, I'll take a look at this soon and get it back to whatever the old behavior was. |
Reviewing the previous command commits, it doesn't look like the behavior has changed, but I agree it probably isn't a good idea for the command to be making a direct database query like that every time, even if it is on a different thread. The setting in the config.yml to disable the leaderboard only applies to the placeholders through PAPI for the leaderboard, and doesn't affect the actual leaderboard command at all. |
I see. I may have misinterpreted its previous function then. That said, could there be a feature that permits the deactivation of its registry? We've had some administrators accidentally register the command and, despite revoking privileges, have failed to adequately/fully remove it and accidental events are still executed. |
Just disallowing the permission |
It doesn’t appear the configuration option was renamed or modified; however, disabling the leaderboard function no longer returns that the leaderboard is disabled. Subsequently, returning the leaderboard too many times can result in a database crash due to too many requests. I suspect that the leaderboard retrieval system needs to be rewritten. There isn’t much to log, as the database issue corresponds with there being a large amount of entries or users in the database.
The text was updated successfully, but these errors were encountered: