anyoldname3 / modorganizer-installer_omod Goto Github PK

OMODs can set the relative load order for pairs content files, and this is available to us via LoadOrderSet. This is used in CM Partners. Currently we don't do anything with this data other than yell at the user that they've found an OMOD feature we've not seen in the wild before, despite me having downloaded CM Partners in 2021 when I was doing some work on this.

It's not a huge deal as LOOT should have this data in its masterlist.

Cause is erri120/OMODFramework#31 interfering with per-mod temp paths. If Erril accepts, fixed upstream by erri120/OMODFramework#32. Will need to bump OMODFramework.Scripting if that gets merged.

https://www.nexusmods.com/oblivion/mods/4922

Required by https://www.nexusmods.com/oblivion/mods/8773

It's fixed in a branch, so needs cherry-picking.

Currently, all installer_omod popups except the readme are application-modal. Custom WinForms widgets created by C# OMODs, like DarNified UI, are thread-modal. The readme is non-modal. This imposes the following problems:

• When a DarNified UI popup is displayed, the whole of the MO2 UI is still responsive. Presumably, things can get broken if someone presses buttons.
• When a DarNified UI popup is displayed, clicking on any other part of MO2 will bring MO2 on top of the popup. This could be misinterpreted as the installation having finished, then the user might interact with the main window and break things as described above.
• When any non-DarNified UI popup is displayed, the readme becomes unresponsive. We want the readme to respond in case the user needs to read it to see what the options they're being shown do or they want to read it while extraction is happening.

#3 changes the RtfPopup to a QMainWindow instead of QDialog. This separates it from the main window's window hierarchy so it's not locked out. The issues then become:

• The same DarNified UI issues as above.
• Whenever any non-DarNified UI popup appears, it will bring focus to itself and the (disabled) main window will be shown on top of the readme popup. It can be brought back on top, though.

For the DarNified UI popups, I don't know if we can do anything. We need to run the install script on a separate thread otherwise the extraction process will lock up the UI and we can't have a progress bar, and we have no control over the windows it creates. The only thing I can think of is having a Mod Organizer is locked while OMOD installer is running popup akin to when an application is running via the VFS, but I don't know if that would fight our other popups.

Qt's modality documentation isn't super-clear as I don't think they anticipated the readme popup use case. I believe that non-modal does what it sounds like, application-modal steals input from all Qt-managed windows in the application, and window-modal steals input from:

• any window found by recursing up the Qt widget hierarchy into parents.
• any window whose parent is one of those windows.
  If I'm right, that means parents, (great-)grandparents and (great-)(aunts|uncles), but not cousins. This might mean that we can get the readme popup to display how we want by making its direct parent a dummy window so it counts as a cousin, and setting the other popups to be window-modal. I'm not sure, though. The documentation for modality refers to the concept of a window hierarchy, but every other bit of Qt documentation refers to widget hierarchy.

It might just be simpler to pass the generated HTML for the readme to the browser so it's totally out of MO2's hands.

If building from the command line, e.g. via Umbrella or mob, the Nuget packages won't get installed until either:

• msbuild -t:restore is run on the generated .sln.
• It's been built at least once through the Visual Studio GUI.

There's not really anything that can be done about this until https://gitlab.kitware.com/cmake/cmake/-/issues/20646 is resolved. Maybe some MO2 devs could nag them to implement it.

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.

As demonstrated by https://github.com/AnyOldName3/modorganizer-installer_omod/tree/initialise-once, it's possible to reuse the same OMODFrameworkWrapper for multiple OMOD installations instead of constructing and tearing down a fresh one each time. For stuff like the OMODFrameworkSettings, which is static, it better matches the natural lifetime of the state we're setting.

Annoyingly:

• This needs doing in multiple chunks as lots of MO2 hasn't started when it calls IPlugin::init. This has been worked around in the branch.
• There's no notification when the profile-specific INI files setting is changed, so the ini path OMODFramework uses can become out of sync. This hasn't been fixed, so the branch hasn't been merged.

The first popup DarNified UI generates is filled with images and is supposed to look like this:

As it was written before display scaling was a thing, it scales badly:

Basically, the images are displayed with one image pixel per device pixel, but the window is sized and things are positioned with the sizes multiplied. It still works, but isn't especially pretty.

• There's an embedded URL. Sometimes this is an ancient Nexus URL which a still-valid mod ID can be extracted from.
• There's a mod description and a readme that could be set as the mod's Nexus description if there was an API to do that without directly editing meta.ini.
• There's some boring stuff, but it could be used if there was ever a way to display a tooltip or preview when a download was hovered over.

https://www.nexusmods.com/oblivion/mods/28223 Doesn't work (tired the Animations Installer OMOD inside the 7z) with a System.ArgumentOutOfRangeException.