Automate Post-Process Cleanup Tasks

[airbreather]

After installing STEP Extended through the automated tool but before running it, in order to have a complete and correct setup, the user still has to do all these things:

1. Open Mod Organizer
2. Enabled DynDOLOD Resources
3. Open LOOT through Mod Organizer
4. (if first time) Add the 4 user-defined meta rules from the STEP guide
5. Sort their load order & Apply & Exit LOOT
6. Open Wrye Bash through MO
7. Right-click Bashed Patch, 0.esp
8. Rebuild Patch > OK > Whatever
9. Close Wrye Bash
10. Re-enable WM Trap Fixes.esp
11. Run DSR Patch through MO
12. Patch > Wait
13. Overwrite > Create Mod > DSR Patch 4Extended (or whatever)
14. Run FNIS through MO
15. Check Skeleton Arm Fix
16. Update FNIS Behavior > Exit > Cancel (or whatever)
17. Overwrite > Create Mod > FNIS Output 4Extended (or whatever)
18. Run DynDOLOD TexGen through MO
19. Start > Wait
20. Exit
21. Delete DynDOLOD-temp from the MO overwrite folder.
22. Move the folder into ModOrganizer\mods with a nice name
23. Enable the textures in MO (which means refresh or restart it)
24. Uncheck BirdsHFclean.esp
25. Run DynDOLOD through MO
26. Click Advanced
27. Click Candles
28. Right-click the box > Select All
29. Click Medium
30. OK > Wait
31. Save & Exit > OK
32. Move the folder into ModOrganizer\mods with a nice name
33. Enable the worlds in MO (which means refresh or restart it)
34. Check BirdsHFclean.esp

A significant fraction of these steps (everything except 11-17, 24, and 34) apply to STEP Core as well, though you can probably get away with skipping DynDOLOD setup if you don't tell anyone.

That's a lot of things. Too many things, in my opinion. If we can automate it "behind-the-scenes" without all that clicking around through the applications, then that's the best thing possible, but if not, then it's still reasonable to allow a "pack" to run an AutoIt / AutoHotKey script that goes through everything so that the user can idle their way to a complete setup.

At the very least, we should provide an AutoIt / AutoHotKey script that the user can run themselves so that they're not left completely hanging. That list is way too many steps, even for STEP Core, and it's way too easy to screw it up.

[airbreather]

Hmm... a mostly sequential XML file that just did these things would actually cut out like 80% of the work from a hypothetical AutoIt / AutoHotkey script, and even some of the overall work too:

1. Tweak the modlist to enable DynDOLOD Resources.
2. Slot the new plugins into the load order.
3. Replace the bashed patch with a new embedded one.
4. AHK run the DSR executable using MO (no clicking needed yet), clicking the Patch button when it shows up, and then waiting for javaw.exe to exit.
5. Move the overwrite data into its own mod folder.
6. Tweak the modlist and load order appropriately.
7. AHK run the FNIS executable using MO, check the Skeleton Arm Fix button, click the button, wait for the window to say the thing, click Exit, click Cancel.
8. Move the overwrite data into its own mod folder.
9. Tweak the modlist again.
10. AHK run the DynDOLOD TexGen executable using MO, click the button, wait for the log file to say the thing, then exit properly.
11. Delete the overwrite data.
12. Move the textures into their own mod folder.
13. Tweak the modlist appropriately.
14. Tweak the load order so BirdsHFclean.esp goes away.
15. AHK run the DynDOLOD Worlds executable using MO, click the things, wait for the log file to say the thing, then exit properly.
16. Move the generated data into their own mod folder.
17. Tweak the modlist and load order appropriately.
18. Re-enable BirdsHFclean.esp.

Honestly, the only scary parts of this are the things marked AHK, and it also happens to be the simplest stuff I can imagine automation tools doing: launch a process with these arguments and "click" these controls once the appropriate window pops up.

Directly launching the Mod Organizer application itself would be a little bit spooky because of the non-deterministic messages, but we could INI-tweak those away if we needed to... and we don't need to in the first place because we just rewrite the internal data ourselves.