feat!: Reworked EXILEDs SSSS Wrapper to use PlayerSync instead of SyncOnJoin and add a new property: Priority #472
Conversation
Merge EXILED
Update branch
the whole point of this
|
Okay it's looks good but there Breaking Change but it's shouldn't be impossible to remove the breaking change by putting some Obsolete Attribute and keeping previous code functional |
|
Once I’m done with school I’ll make a non-breaking version, though I plan to rework a LOT of stuff, can we talk on vc at some point to discuss what the end goal for our SSS wrapper should be? (What would be the best features to have, etc…) @louis1706 |
I don't really know a lot about SSSS didn't have used it a single time so i am not the best for talking about them |
|
see #482 for a non-breaking version that does this, but arguably better |
2 participants
Description
I removed SyncOnJoin as it's kind of stupid, why would you send SSSS data to only a few players if you can't even differentiate whether or not certain players get certain settings. (To reiterate, you can either send ALL SSSS data to a player, or NO SSSS data to a player). I replaced this with a new property of SettingBase, PlayerSync, which is a Predicate same as SyncOnJoin, but it's per-setting. I reworked all generic SSS sending code to check that Predicate when sending. So when you did SettingBase.SendToAll(); previously, everybody would get every registered setting. Now when you run that same method, players that satisfy that Predicate get sent the setting. I haven't tampered with anything that sends an IEnumerable as I understand devs might need to send only certain settings. I also added a new property, priority, that is used to sort all SettingBases when something like SettingBase.SendToAll(); is called, this is useful as previously, to get your SSS stuff higher up in a list of setting, you'd have to up your PluginPriority to register your settings before another person. Now devs could add Priorities to every setting in their configs so server owners and organize their ServerSpecificSettings page however they see fit.
What is the current behavior? (You can also link to an open issue here)
EXILEDs SSSS wrapper is just base game re-textured. We have no extra features
What is the new behavior? (if this is a feature change)
SettingBase.SyncOnJoin is gone, replaced by a non-static version that's checked every time SettingBase.SendToPlayer(); is called. Another property was added that is used to sort settings when sending them.
Does this PR introduce a breaking change? (What changes might users need to make in their application due to this PR?)
Yes, the constructor for all settings is now changed. On top of this, SettingBase.SyncOnJoin is gone.
Other information:
I know half of this code is probably garbage compared to EXILEDs standards, but considering we've gone months without something useful being added to SSS, this is at least A step forward. Please, feel free to make any criticisms or suggestions, this PR is more to start moving things forward rather than rework SSS. I bet some of you reading thing could probably do what I did without making any breaking changes (just obsoletes), but considering nobody has even attempted this to my knowledge, I was more or less forced to make this PR. This might break a lot of plugins, but if it was implemented, we'd have a whole new degree of freedom for SSS.
Extra info: SettingBase.Header is kinda goofy, we could/should probably remove it or rework it.
Types of changes
Submission checklist
Patches (if there are any changes related to Harmony patches)
Other