vortexposer

Yeah, or possibly the path beginning in a root subfolder. Might not matter but my custom install path is C:\Vortex\\ vs C:\<folder>\Vortex\\

Is your other PC using a similar custom install path for Vortex? .NET seems to have an issue finding or accessing E:\\ModInstallerIPC.exe

Had similar issues a while back and it ended up being a non-typical .NET error - which redownloading off of official Vortex page enabled me to fix/repair. How you tried that? I had to reinstall and then boot again for it to display the repair option - https://www.nexusmods.com/site/mods/1

Try to capture a specific example of one of these external changes that doesn't add up and log as much detail as possible. As you previously mentioned, there's fairly low chance of it being critical Vortex bug vs something else, simple or complex. Which can hopefully be reasoned out and worked around - as I have yet to meet an external change that can't be resolved.

Maybe drop a pic or 2 to demonstrate the damage done.

Oof. I think I can visualize what kind of situation you're describing... and know that pain all too well but without getting into details - I've never found an efficient way to recover from an orphaned Staging folder (which has lost the install/metadata connectivity) - except to be mindful to not break, again. All I can add is; I've learned to build each profile that's important to me into their own draft collection, so I can always revert Staging folder to an uninstalled state and automate their entire restoration. Currently, I'm sitting here dropping 5578 archive into a new fallout new vegas set up... but thankfully, I've got 7 highly curated drafts ready to install stuff, once they're added

Okay, I see it now... If I take 3 non-conflicting folders (sorted by deploy order), they deploy 0/1/2 alphanumerically and then if I introduce an artificial file conflict for 2 to "load after" 0 - it'll readjust "deploy order", overriding defaults sort assignment. Guess I never bothered to pay attention to that detail (or sort by deploy order priority), which led me to ignore the correlation to conflict resolution rather than simply being arbitrarily linked to the defaults state alphanumeric sort. Also interesting that install status plays a part in where the UI display shifts it too. Thank goodness for collapsible custom category because I'd go insane trying to sort by anything else. *Actually, I can't figure out what sorts by default to determine initial deploy order. No wonder I ignored

Yeah, is plausible that my cognitive dissonance resolution had a cyclic error moment in regard to conflict and deployment because I generally don't consider conflicts as part of the equation when I deploy, since Unless you're a mod type conflict

I guess I must not understand the context of what the term "deployment order" is meant to represent in Vortex for an end user - besides what order its deploying files to game folder in, which is irrelevant to its LO. The main issue I've seen is users thinking that deploy order is somehow indicative to MO "priority index".

DynDOLOD?

Unpack outside of fomm to confirm archive isn't broken and then maybe just manually import extracted content to a custom fomm folder.

Really? How does deploy order matter when at the end of the process, what is there is there and what loses isn't? Like, I get the loose file vs bsa reasoning but in terms of where one or the other is in deploy order, how would its specific indices matter? This might make me rethink the significance of using deploy after rules, which until now I thought only applied to Ini Tweaks (BGS). Also, hi Tannin! Hope you're doing well

Correct. Once conflicts are resolved (in mods tab), their "deploy order" makes no difference whatsoever. There's really no point in keeping the column enabled either (disable/enable columns in upper right cog). Although generally irrelevant for most users; the only practical use for deployment order that I've ever seen (in BGS games) is when making one Ini Tweak deploy after another Ini Tweak that don't share the same name (not in direct conflict), where both edit the same ini values = deploy after rule enforces the value changes in the override Ini Tweak file.

I forgot to come back to this thread and report but eventually mine got fixed by rerunning the listed .NET 6.1+ link in required files off Vortex page. Can only speculate as to what broke it (unofficial copy of MO2) but .NET registered as needing repaired and issue went away for good.

Does the Apply button get grayed out after confirming new downloads folder path?