This repository was archived by the owner on Jul 8, 2025. It is now read-only.
feat: Non-breaking SSS rework #49
Closed
Conversation
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
Prepare branch
Only bad thing about this is the fact that the constructor for most settings is now ambiguous unless you specified every input. (not breaking tho 💰 💰 💰 💰 )
Removed default values from obsolete constructors, making the Ambiguous constructor reference error impossible. Added a SubGroups property to SettingGroup to handle recursive groups of settings. SubGroups defaults to null but I made sure to check it in them methods that call it. Notably SettingGroup::GetAllSettings(); that recursively gets all the SettingBase contained within it. I added checks for recursive stuff and an error for it. I also added SettingGroup::GetViewableSettingsOrdered(Player) that gets all the settings viewable by a specified player as well as ordered by priority etc...
some last minute tweaks including fixing the List<> renting I was doing
Legit realized my recursive check didn't work last night right before I went to bed 😭 This ought to fix it though
…Settings, Add an IReadOnlyCollection of Groups if a plugin-maker manually removes a ServerSpecificSettingsBase from ServerSpecificSettingsSync.DefinedSettings, it's on them to handle who gets what settings, otherwise making this check simply reduces points of failure
Forgor to check predicate :(
yknow, I really though that checking DefinedSettings for the setting bases before sending them was a good idea, but SOMEHOW SettingBase::Base doesn't return the value stored in ServerSpecificSettingSync.DefinedSettings!?!?!? 😭 Anyways, removed that, added a specified group for the obsolete methods to register into, then made all SettingBase non-group register/unregister method reference that group. Only way this breaks is if some goofy goobers plugin unregisters all settings, clients would see stuff created via group method, but that's why we obsolete stuff, it doesn't affect pre-change behavior so as long as devs have a few brain cells (crazy request ik) we should be good
as far as I can tell this shouldn't mess with the recursive check but make it more accurate. But now you can have multiple of the same group in SubGroups if you'd like (without them being recursive ofc)
Just turn on the femur breaker lil bro
Merge dev to my thing
github-actions
bot
added
API
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
2 participants
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.
Description
Describe the changes
SSS PR IS BACK BABY WOOOOOOOOOO 🤑 🤑 🔥 🔥 💹 📈 🗣️ 🗣️ 🗣️
Added SettingGroup class to hold multiple SettingBase to be grouped together when displayed, as well as adding to said SettingGroups: Viewers (a predicate to determine who can see the SettingGroup on SettingBase.SendToPlayer()) Priority (an integer to use to sort the SettingGroups in SendToPlayer) and SubGroups (Other SettingGroups that may wish to be attached to the original SettingGroup)
What is the current behavior? (You can also link to an open issue here)
EXILED's SSS implementation is mid, no player specific settings, no priority for groups of settings, etc...
What is the new behavior? (if this is a feature change)
See "Describe the changes"
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
No
Other information:
This has been tested a lot by me personally, but if anybody has ideas for new features, feel free to comment about em.
Types of changes
Submission checklist
Patches (if there are any changes related to Harmony patches)
Other