AnyOldName3
commented
3 years ago The stuff gets saved, so that's something. The specifics of the stuff are that it's:
- A list of plugins the OMOD would have automatically activated in OBMM. This isn't necessarily the same as the list of plugins that got installed as OMODs can opt-out of activating some.
- A list of the plugins the OMOD opted-out of activating.
- A list of the BSAs the plugin would have activated. In OBMM, this was done by adding it to the list in the INI but that's bad, so I don't do that here.
- The INI edits.
For both kinds of plugins, currently the installer's post-install callback tells the user whether each plugin would have been active and offers to activate it (with a yes and no to all option so it's not too irritating). For BSAs, there's a popup that displays a list and suggests some ways of making the BSA load. For the INI edits, these aren't delayed until the post-install callback and the user is asked for each one, then they're applied directly to the profile INI. Specifically in the case of INI edits, we need to keep some kind of popup as the DarNified UI installer announces that OBMM will display a popup and to press Yes to all, so if we don't, we'll get bug reports about the popup being broken.
Ideally, we could basically run the post-install callback as a context-menu plugin on mods with OMODs installed, but obviously that's not a thing yet. Also, the BSA loading will hopefully be doable later if MO2 ever gets BSA management again, and INIs could be done via INI tweaks if they come back (hopefully in a less arcane way than in MO1).
Another idea is using the diagnosis plugin interface. If a user has OMODs active in the current profile, but they've not had their stuff applied to it, that could be displayed as a problem, and applying the stuff could be the guided fix. However, it's not clear how we'd actually detect that things hadn't been applied. If we actually go through every entry and check it's in the state the highest priority OMOD-based mod that affects it wants it to be, then it might be slow, and also would have annoying false positives if the user intentionally didn't apply one of the entries. Alternatively, we could keep track of which profiles a given OMOD had had its stuff applied to, but there are ways of tricking it into giving false negatives. For example, if a profile is renamed or copied, there'll be a profile with a new name, but that already has the stuff applied.
This should probably be saved somehow and recovered when the profile is changed. Something needs to happen so the user isn't nagged every time they switch profiles, though.