LOOT fails to update loadorder when run through MO2 command line

[leontristain]

The problem:

LOOT fails to update loadorder when run through the command line.

Details

I am using MO2 version 2.2.2.1 archive version, downloaded from Nexus SSE page.

I'm trying to automate the running of LOOT by executing it through MO2 on the command line and ran into the following issue.

If I run LOOT through MO2 on the command line, using something akin to <path/to>ModOrganizer.exe -p Default <path/to>LOOT.exe, it would appear to work at first. LOOT would open up and show me my MO2 plugins, and I can sort and apply fine. After I hit the "Apply" button, I can see in the MO2 folder that profiles/Default/plugins.txt got updated with the expected changes. However, once I close LOOT, the changes to plugins.txt gets reverted back to what it used to be.

Whereas, if I open MO2 and run LOOT by manually navigating the GUI, this behavior doesn't happen. After I close LOOT, plugins.txt remains the newly updated list, and loadorder.txt gets updated as expected.

LOOT seems to only care about plugins.txt and seems to be doing the right thing. This looks like an MO2 bug where MO2 is failing to perform some postprocess functionality consistently between the gui-launch case and the cli-launch case.

Please let me know if it seems to be user error on my part or if there's a work around at this time. Thanks!

[isanae]

I can confirm that. I'm not sure whether it's something I broke when I changed the process running and lock overlay stuff or if it was always broken. MO doesn't refresh after starting processes from the command line, so when OrganizerCore is destroyed, it writes the old stuff.

It should be as simple as to change the two setWaitForCompletion() calls in main.cpp to setWaitForCompletion(ProcessRunner::Refresh).

[leontristain]

Wow that was quick. Thanks for the quick response, and glad it doesn't sound hard to fix!

For the time being, I will work around this issue by writing a wrapper around LOOT to run through MO2, so that the wrapper can save out the generated plugins.txt and then apply it back onto the plugins.txt/loadorder.txt as a post process. It feels like a dirty hack but it should work I think. Meanwhile I'll wait patiently for when the fix gets out into the public :)

[Al12rs]

I tested changing those two lines but it doesn't seem to work