Integrate mod settings directly via DataFeeds

[XDelta]

Would be good to integrate provided it isn't super fragile. Would mean that settings control would be in game without requiring an additional mod and would always be available.

Current known limitations include that resonite doesn't provide templates for every* type that mods currently use ie color/colorX, float4, uri, probably others The ability to add settings also is limited to being added by components without directly adding on the collection directly while settings categories appear to be addable directly by plugins.

[XDelta]

With the upcoming change to how plugins and types work, using a component for handling settings is becoming a more viable option without needing more fragile patches.

[djsime1]

FWIW I've started an implementation of a configuration DataFeed myself @ https://github.com/djsime1/ResoniteModLoader/tree/dash-screen. Once it's in a somewhat stable state, I'll open a draft PR, so the finer details can be worked out. There are a few caveats to making this work, such as marking the assembly DataModelAssemblyType as UserspaceCore instead of Optional, and removing the FROOXENGINE_WEAVED flag so that virtual sync member methods are generated for the component. Additionally, in my branch I (temporarily) reverted 1b060a1 to restore the hidelatetypes config option so RML would stop hiding the component type from the engine. This will have to be worked into a better solution too.

As for the UI, there are a few options I've considered. At the time of writing, my branch literally steals the item mapper templates from the default Settings facet, but as you mention this is far from ideal since it lacks templates for a lot of engine primitive types. @BlueCyro is also working on this it seems, but instead of exposing a new component, it would be part of the game's existing settings feed.

I'm actually already looking into a proper implementation of mod settings into the real settings without needing to do a bunch of hacky patches. So far it's going good, I just need to iron out some stuff source

So uh, I guess keep your eyes peeled. I've done like 50% of the gruntwork of figuring out how the settings work properly, the other 50% is just making it functional and not messy Maybe coming soon™ to an RML near you source

Now of course with this being a DataFeed, the UI is the most flexible part. Instead of relying on templates from the settings facet, generic/placeholder templates could be procedurally generated with UIBuilder and MemberEditor's, a-la how MonkeyLoader shims unsupported type templates into its injected settings feed on-the-fly. These templates would be supported by hand-made templates based on the settings templates, which would get loaded from a cloud record sort of like how the settings facet/screen already is. Of course, that's not a dependency I'd necessarily like to add, but there may also be potential for allowing users to set a "favorite" mod configuration datafeed similar to how SpecialItemsLib handles this.

[djsime1]

As part of this new DataFeed, mods should be able to define their own configuration enumeration method. This shoudl be a 1-1 passthrough of the original call arugments (with the beginning of the path removed for portability sake) so mods have full control over how their feed is built and organized, which also gives them the ability to utilize sub-categories. Later down the line, it might also be worthwile looking into extending some common DataFeedItem's so the UI is better-suited for mods (ie, extending DataFeedValueField\<T> to include validation, and a way to reset a configuration key to its default value).

Besides showing basic mod info and providing an interface to alter configurations, this would be a good place to include an in-game log/exception viewer, which will be helpful for users and mod devlopers alike. This can also house mod initialization exceptions so users can be informed if a mod doesn't get loaded due to an exception during its initialization.

[BlueCyro]

As part of this new DataFeed, mods should be able to define their own configuration enumeration method. This shoudl be a 1-1 passthrough of the original call arugments (with the beginning of the path removed for portability sake) so mods have full control over how their feed is built and organized, which also gives them the ability to utilize sub-categories. Later down the line, it might also be worthwile looking into extending some common DataFeedItem's so the UI is better-suited for mods (ie, extending DataFeedValueField\<T> to include validation, and a way to reset a configuration key to its default value).

Besides showing basic mod info and providing an interface to alter configurations, this would be a good place to include an in-game log/exception viewer, which will be helpful for users and mod devlopers alike. This can also house mod initialization exceptions so users can be informed if a mod doesn't get loaded due to an exception during its initialization.

I think in order for long-term support of mods being able to define their own feeds, the old settings system should probably be deprecated in favor of just having mods define their own configuration components for user space. The game's already done the work for us so we should avoid duplicating it.

If we want a clean implementation, the current mod config system should transition to the new setting system as a whole and eventually be phased out so that we don't have two setting systems glued together

[XDelta]

Making the modloader handle most of the construction for settings and datafeeds so individual mods don't need to do much themselves would be good. Needing each mod to implement and define their own feeds sounds like it would be a bunch of extra work for the mod developer.

[djsime1]

I should have clarified in my previous comment - Mods can implement a configuration feed enumeration method if they want, otherwise the feed will use its own internal config generation. The option is there for mods if they want to utilize groups and sub-categories to organize their settings, whereas the default generator will spit out one straight page.

To make the process of generating DataFeedItem's easier, I whipped up a FeedBuilder utility library to drastically reduce the amount of boilerplate needed to work with feed items. This can be used by mods as well.