NML2

[l-2-j]

A list of changes that would be neat to have whenever a breaking change is done:

• Move the mod info to standard attributes
• Add a mod description attribute? People seem to want this.
• Expose a convenient helper getter for a mod specific HarmonyInstance in NeosMod (which could be lazily initialized on first access)
• Unloading/reloading of mods (could always unpatch said harmony instance)
• Determine if any mod actually uses the semver configs, axe it if it's unused.
• Move the IncompatibleConfigurationHandlingOption method into the builder. It's just chilling all alone in the NeosMod class now.
• Just generally cleanup everything
• Properly handle nulls.
• Remove deprecated APIs
• Investigate if switching to dotnet6 would be beneficial
• do a sweep of mandatory/optional parameters for various APIs and make sure it all makes sense
• split mod config key name into separate fields for serialized name and display name
  • serialized name would be what's used in the json
  • display name can be shown in config managers
  • could be done via the form of a general metadata system with a few "known" keys or sumthing
• Config validators
  • For example min/max support for numeric configs. People probably want to use this to make sliders.
  • Perhaps checking a combination of conflicting configs to ensure they're not enabled at once?
• let applications skip potentially expensive string building for debug logs if debug isn't even enabled
  • Could be done via a Func<string> that handles building the text
  • Could be done via simply exposing an IsDebugEnabled() method
• migrate from Newtonsoft.Json to System.Text.Json to fix the normal and headless clients needing distinct builds

@zkxs has also added stuff to this

[zkxs]

• Remove deprecated APIs
• dotnet6 targeting?
• better null safety
• do a sweep of optional metadata and make some of it mandatory

Edit: Merging into the top comment to keep things organized

[EIA485]

i have a mod that use's stemvr configs. dont think we should axe it.

[rampa3]

Idea based from reading the PR #52 - How about adding default on option, that will spawn warning dialog if user uses non-manifest mods, and block these, just as a safety measure for new users to modding. Since we have the manifest, we could just have NML auto-fetch it into a folder and check stuff against it, to make modding more safe...

[l-2-j]

I don't like the idea of doing anything networked without explicit consent from the user. I could maybe see that being useful if it wasn't the default, and if say there's an installer for NML made, it would ask a "choose yes/no" kinda thing where it then sets that config option. But I don't think the loader itself should default to restricting things and using the network.

[JackTheFoxOtter]

You could also make it so NML will actually download / cache the manifest, but only on explicit permission grant. So it could ask on first boot if the user wants to download / update the manifest automatically, make that a setting that can be changed at any time and also add the option to explicitly update the manifest through a UI button. Also it should give the user the option to choose what will happen for mods that aren't in the manifest. Automatic / Default blocking probably isn't the best way to go about this. It should also be a setting the user configures. (I'm thinking something like "Disable", "Show Warning", "Prevent Loading" for handling non-recognized mods).

[l-2-j]

Issue with that is that I feel like adding actual UI buttons I feel like is out of scope for NML itself. I had to fight an uphill battle to even get splash integration to NML ;'P

[rampa3]

Issue with that is that I feel like adding actual UI buttons I feel like is out of scope for NML itself. I had to fight an uphill battle to even get splash integration to NML ;'P

Couldn't we somehow hijack the method for web request dialogs and use that changed a smidge?

[l-2-j]

Couldn't we somehow hijack the method for web request dialogs and use that changed a smidge?

NML loads before most of Neos loads, so there's no guarantee that that'd work. We'd also need to freeze loading mods before an action is taken, thusly whenever Neos gets updated and that code gets renamed for example, or the behavior changes, it would lead to NML being broken.