Initial ModConfigurationDataFeed implementation

[djsime1]

Addressing #11, still heavily work-in-progress.

This PR introduces two new components: ModConfigurationDataFeed and ModConfigurationValueSync. Together along with the new FeedBuilder and ModConfigurationFeedBuilder utility classes, this lays the groundwork for users being able to configure mods in-game without the needing to rely on another mod to do so. Additionally, it will allow mods to optionally build their own configuration data feeds, while also providing an automatic configuration feed builder for mods that do not implement their own. In addition to managing mod configurations, the new DataFeed will also let users easily view and copy logs & exceptions in-game.

Things that still need to happen before this is ready to get merged:

• Document all public methods & members (XML)
• Document new classes (Wiki)
  • FeedBuilder
  • Logger
  • ModConfigurationDataFeed
  • ModConfigurationFeedBuilder
  • ModConfigurationValueSync
  • ResoniteMod.BuildConfigurationFeed
  • AutoRegisterConfigKeyAttribute.Group
• Finalize FeedBuilder extension methods and names
• Add support for GroupingAttribute and possibly CategoryAttribute to ModConfigurationFeedBuilder
• Add support for ordered/enumerable types to ModConfigurationFeedBuilder
• Create DataFeed item templates for each engine primitive type
• Add support for ModConfigurationDataFeed being usable in a RootCategoryView
• Complete ModConfigurationValueSync component

There's probably a few more TODO items I couldn't think about listing, but that's the bulk of my assignment. I've intentionally disabled maintainer edits so long as this PR is a draft. Comments and feedback welcome!

[EIA485]

really interesting pr. im somewhat unclear on why this needs to be part of the mod loader as opposed to being a standalone mod that interacts with the mod loader's api

[Nytra]

If you're adding components, why not just use a SettingComponent instead of patching an extra screen to the dash? That would benefit from being able to work with the SettingsDataFeed instead of a whole new feed.

[djsime1]

@Nytra

If you're adding components, why not just use a SettingComponent instead of patching an extra screen to the dash? That would benefit from being able to work with the SettingsDataFeed instead of a whole new feed.

When I started this endeavor I wasn't familiar with how the Settings menu and feed worked, I didn't realize there was a whole structured system behind it; I just thought making a new DataFeed component would be easier than trying to patch the SettingsDataFeed Enumerate method. With that being said and the familiarity I've gained by referencing it for this implementation, I organized the main DataFeed method so that it could be turned into its own category within SettingsDataFeed instead with minimal effort. From what I understand, Cyro is working on making it more straightforward for plugins to do just that. Right now though, the settings facet only has the bare minimum of item templates necessary to cover each type of setting, nor does it have a way to utilize a DataFeed's search parameter (something which I've been accounting for in this implementation). So until those goals are met, and a template is made for every engine primitive type (an undertaking I'm already working on myself), I'll be sticking with a custom feed component and custom facet/dash screen.

I appreciate the feedback though, and if you want to discuss more details we can chat about it in the Discord discussion thread.

[Nytra]

I have added a setting component in a plugin here if you would like to take a look https://github.com/Nytra/Project-Obsidian/blob/main/ProjectObsidian/Settings/MIDI_Settings.cs

[djsime1]

@EIA485

really interesting pr. im somewhat unclear on why this needs to be part of the mod loader as opposed to being a standalone mod that interacts with the mod loader's api

Part of the reason I think this should be a native part of RML instead of its own mod (Like ResoniteModSettings) is because it can define a standard that just works™ for all mods. A standalone mod would not be able to add components, and would instead have to rely on a bunch of hacky patches to the SettingsDataFeed (cough cough MonkeyLoader) and RML itself to achieve the same features in the form of a DataFeed. UIBuilders and completely custom screens are not desirable either due to their lack of standardization, and could be more prone to breaking between updates. Even thenso, if that settings manager mod allowed other mods to define their own configuration feed enumeration methods, it would just have less visibility and thus less utilization.

[Banane9]

Your PR also undoes some of the changes from the Type Update 👀

[djsime1]

@Banane9

Your PR also undoes some of the changes from the Type Update 👀

RML kept hiding the Component types from Resonite, so I temporarily reverted the commit so I could use the config options that stop RML from hiding types. The revert commit will be dropped before I open this for merging.

[EIA485]

@djsime1

Part of the reason I think this should be a native part of RML instead of its own mod (Like ResoniteModSettings) is because it can define a standard that just works™

the thinking was that the mod loader's config api would be the standard interface people could interact with in different ways like creating ui mods n such.

this being a separate mod makes maintaining things easier.
from an rml perspective: its less stuff to break. a simpler/smaller code base for contributors to be familiar with
from your perspective: any time you want to make a change you dont need to get it upstreamed
from the user/contributor perspective: more modularity. a user can pick and chose different versions of things and use them together. a developer can edit rml or the DataFeed integration without needing to compile the other/use a specific version of the other

ive not been around much for awhile but id say generally if the other ui mod has an api many mods use we should upstream a version of that api so other ui mods can also easily render any of that information.