Repository navigation
(A)sync handling of Menu requirements - #308
Open
petulikan1 wants to merge 1 commit into
Open
petulikan1 wants to merge 1 commit into
petulikan1 wants to merge 1 commit into
Conversation
|
I can second these changes being useful. I can open my menus with 3,000+ placeholders in under a second now, where before it would take 6-8 seconds. There is no notable TPS drop I can see. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Greetings, I'd like to propose of adding this feature - being able to parse menu open requirements in sync.
This feature would allow server owners to change, whether their menu open requirements should be parsed async (default behavior) or with a config option (for each menu)
parse_requirements_asyncset tofalse- sync.The reason for this feature is simple - some menus are built around requirements, and one of these requirements can be (like in our case) a string equals check, where, when before it's evaluated, it goes trough a PlaceholderAPI parse method, to set all the necessary placeholders. In our case, this sets the result of a CheckItem Expansion placeholder, sadly, due to how this expansion works - it doesn't disambiguate whether the code from which it was run from is sync or async. To mitigate these race conditions, we have made our own fork of this expansion and fixed this behavior to strictly force any item interaction on the main thread, to prevent race conditions (as we were experiencing before). Sadly, that created another problem - menus. Due to how our menus work, where we have quite a lot of placeholders, to handle all possible scenarios of all kinds of items, that creates a delay where every single placeholder parse has to be run on the main thread.
That's why I'm proposing of adding this as an optional feature - when server administrators deem necessary for their requirement logic to be run on the main thread, they can simply do so by adding a config option and setting it to false.
Here are examples of running the requirements check in async and sync.
ASYNC
https://youtu.be/wfCdNEcx9hw
SYNC
https://youtu.be/rEXl_sv2zm0
Thank you for reading and for considering this pull request.
(Disclaimer - NO AI was used in writing of the changes, writing of this pull request message, making of the videos -- Everything was done by me - human - petulikan1)
(All my commits are signed by my GPG key)