Vortex keeps purging when I download and install a mod

[deathlyhill9]

On 6/6/2024 at 11:12 AM, TennesseeTuxedo said:

Did my final 10 minutes of Vortex purging last night, this time intentional by pressing the "Purge Mods" button in preparation for my move to MO2 which was much quicker than I thought it would be since you can just use the Vortex folders with your downloads and mods already in them.  Thank you @AugustaCalidia and @showler for the links for that.  It only took a couple hours and I am FREE!

I already miss the tighter integration with Nexus but when I downloaded and installed a mod in MO2 in seconds vs 12 minutes+ with Vortex (10 min purge scourge +2 min deploy time), that made up for all, it was so satisfying I was practically giddy.

I had a wonderful experience with Vortex and FO4 (although I understand this purge scourge may have metastasized to other games managed with Vortex), which is why I was so bullish with it for Starfield.  But Starfield Vortex experience has been miserable and I have lost many gaming hours wrestling with these various issues that seem to be getting worse.  This last problem of tacking 10 minutes of purging onto already bloated processes was the 3 ton brick that broke the camel's already sprained back.  But I am in a better place thanks to the community here.

Peace and enjoy Starfield all!

Yeah imma about to switch to mo2 cuz the purging thing breaks my skyrim stuff more than anything least till I know this issue is fixed 

[i9800]

Is it possible to just disable "forced auto" part in purging with small patch, leaving notification about needed purge, like it has already done with deployment? It'll be enough to conviniently using Vortex untill full patch arrives. Even without full patch it will be okay, actually.

For now, it's become nearly unbearable to use vortex with this extremely annoying "purging cycle".

Edited June 10 by i9800

[Doppelkammertoaster]

I had the same issues today and I have a guess what is causing it.

Vortex seems to be only able to 'know' dependencies, if the mods are published here. If you download them from somewhere else, unzip and zip them again, and don't have a fomod, it doesn't know. It will show you conflicts, as usual though.

For me it seemed to be caused by a mod changing SKSE (SKSE 64 2.02.06 for GOG 1.6.1179). The minute I decide the rule to solve the conflict it began to purge again. I assume, it is because Vortex doesn't know the dependencies or has issues with 'external' mods.

How the conflict is resolved doesn't matter, the purging happens either way. It's the first time seeing it. I recommend deleting mods that you added before it happened or manually look for the one that changes SKSE files.

AND, yeah, that needs to be fixed ASAP. Vortex has no issue with mods from Nexus doing this bs.

Edited June 18 by Doppelkammertoaster

[alranteesi]

Still Purging loop annoying even with the last update for Vortex

[Pickysaurus]

This issue is 100% caused by a bad mod setup, but you can now disable the alerts/auto-purge under "Settings -> Workarounds - > Cross-ModType Conflict Detection". This will potentially cause issues with your mods and you will likely see the "External changes" dialogue for the files that were causing this conflict in the first place. 

[CommunistNinja]

13 hours ago, Pickysaurus said:

This issue is 100% caused by a bad mod setup, but you can now disable the alerts/auto-purge under "Settings -> Workarounds - > Cross-ModType Conflict Detection". This will potentially cause issues with your mods and you will likely see the "External changes" dialogue for the files that were causing this conflict in the first place. 

"A bad mod setup" is a vague thing to say. What exactly is a "bad mod setup" that would cause this purge-loop? What is a "cross-modtype" conflict? 

I've literally got a save with like 25 days on it, still playing with a modlist from nearly a year ago, but it's only been doing this purging cycle for the past few weeks.

[Pickysaurus]

The issue has been explained a few times in this thread. 

There are two main mod types for Bethesda games, one that deploys files to the game root and one that deploys files to the data folder.

You have (somehow) got a mod in your loadout that is deploying to the game root but it includes a file that is ALSO being deployed to the data folder directly by a different mod. 

If you show the "Mod type" column and look for anything that isn't default/blank you'll dramatically narrow down the possible causes.

[TennesseeTuxedo]

On 6/7/2024 at 12:58 PM, deathlyhill9 said:

Yeah imma about to switch to mo2 cuz the purging thing breaks my skyrim stuff more than anything least till I know this issue is fixed 

Highly recommended!  Updating mods after a Startfield update requires a little more effort with Mod Organizer 2 however there is NO thrashing of your hard disk, no constant copying and deleting of files madness.  You can install a mod or an update literally in seconds.

It's sad to see the users being blamed for the sudden appearance of this, telling people it's there fault for something that has never been mentioned or warned about while installing mods.  The expectation that users should have proactively searched all these threads to know what a "bad mod setup" is, is a bad expectation.  How would they even know to do that?  Why wouldn't Vortex popup and say "you sure you want to do this "bad mod setup"?  

[vortexposer]

MO2 wouldn't know what to do with this "mod type" file conflict either, since it only deals with one. E.g. When using Root builder, would a file buried in a subfolder named "root" conflict with another file in its normal "data" structure? No, it wouldn't. User wouldn't know there were problems, except for this specific file not doing anything. Vortex has mod types and they can/do conflict - but only when their mod type are appropriately matched. When their mod types don't match.. something like a forced "purge" happens, or in its previous versions - ended up in its file being dropped and registered as an "external change". This has been known about for years but was generally only found to be an issue once heavy use of mod types became normalized by inexperienced users.
 

Edited June 23 by vortexposer

[Pickysaurus]

On 6/21/2024 at 11:26 PM, TennesseeTuxedo said:

Highly recommended!  Updating mods after a Startfield update requires a little more effort with Mod Organizer 2 however there is NO thrashing of your hard disk, no constant copying and deleting of files madness.  You can install a mod or an update literally in seconds.

It's sad to see the users being blamed for the sudden appearance of this, telling people it's there fault for something that has never been mentioned or warned about while installing mods.  The expectation that users should have proactively searched all these threads to know what a "bad mod setup" is, is a bad expectation.  How would they even know to do that?  Why wouldn't Vortex popup and say "you sure you want to do this "bad mod setup"?  

Have you tried any of the previous instructions we've given to help identify the issue. It's not trivial for Vortex to tell you what's happening as it's a very unexpected state for the user to have gotten themselves into this situation without any clue what they did to cause it. 

Here's a few images in case you're not sure what I've said. First, you need to show the modtype column

Then you can click to group by modtype.

As you can see I have SFSE with a blank modtype and 8 "Data folder" mods. 

What will be happening is that one of your mods without a modtype is deploying a file that is intended to go into the data folder, but one of your data folder mods is ALSO deploying the same file. So you have this kind of thing:

• "Default" modtype mod is placing the file "Data\Textures\Photos\SomeFile.png" in the game root folder, resulting in a full path of "Starfield\Data\Textures\Photos\SomeFile.png".
• "Data Folder" modtype is placing the file "Textures\Photos\SomeFile.png" in the game's data folder, resulting in an identical full path of "Starfield\Data\Textures\Photos\SomeFile.png".

In this situation Vortex doesn't know which one of these files to use as a priority so it has to purge and redeploy repeatedly. 

The fix is to open any of the "Default" modtype mods and remove anything they contain that deploys to the data folder. (So basically just any of these mods that have a Data subfolder if you right-click and open the staging folder entry). 

If you'd rather just not troubleshoot the issue, you can turn off this detection as described below, but this is risky.