Nagev

Hi guys,
Just spent a good 60 minutes trying to reproduce this while managing SSE and VR alongside each other, switching between them, installing mods, intentionally changing the target gamemode for the downloads, etc. Each operation was reversible and at no point were the mods assigned the wrong primary gamemode. The only thing that could potentially cause something like this would be if the VR extension gets loaded before SSE but that's impossible as they're loaded alphabetically.
Can you try to set all the downloads to SSE and then disable the bundled Skyrim VR extension in the extensions page and let me know if the downloads are still set to skyrimvr.
Edit: My assumption is that you're all using Vortex 1.13.3 - if you're not, please update.

Hi there @metalheadhr
First of all, thanks for bringing this to our attention, your tests are appreciated and did indeed highlight a bug.
After running some tests on my end, this appears to be a visual bug in the plugins page.

As you can see in the snippet above, although the plugins page is defining the LOOSE version as the source, the deployment manifest itself is using the correct source. You can double check this yourself on your end - open up your "vortex.deployment.json" file and look for the ".esp replacer" source. (Searching by "SofiaFollower.esp" will match too many entries from the original mod)
This will be fixed in Vortex 1.13.4 which will be released sometime in the new year.
P.S. In the future please report any such issues on our issue tracker as it offers better visibility: https://github.com/nexus-mods/vortex/issues

@7531Leonidas - that's actually intended behaviour; the conflict resolution system will wait for you to finish installing and deploying your mods before re-checking if any conflicts exist. It's an optimisation which made collection installations quicker.
I can look at making the optimisation optional if it's indeed a hinderance. At the very least I think I'm going to hide that notification while installations are running.

Hey @Razor671 - judging by the snippet you sent, you're potentially using a very old version of Vortex, you can confirm the version by looking next to the window buttons at the top right.

 
If the version is not visible, it's a clear indication of a very old Vortex version. Stable is currently 1.13.2

1.13.2 has been rolled out and will fix both categories and the inability to manage FalloutNV on machines that can't connect to Github

Thank you for the heads up - noticed this a bit too late and didn't get to add it to todays patch release; but will make sure we take care of this for the next one.

Hi there,
Vortex functions based on its extensions system; some extensions require others to work and Vortex will automatically download and install its requirements when it can, this is by design. In the case of the last extension you'll have to disable Fallout New Vegas as well to stop it from trying to fix its dependencies. Please stop disabling extensions that are bundled with Vortex.. It's only going to cause you trouble in the long run.

Hi there, this is down to a bug we just fixed. Will be releasing this as part of 1.13.0-beta.4
https://github.com/Nexus-Mods/vortex-games/pull/141

Hi there - why do you suspect Vortex is the culprit in this case? Vortex only grabs focus if you're actively downloading mods from the website. Any in-game issues are always down to the mods you have installed, or potentially a different application grabbing focus.

Then I'm afraid we're at an impasse as I can guarantee that the official Vortex installer contains no malicious code whatsoever. As Zanderat mentioned, the issue is unique to your system. We've never had any reports of Vortex installing Windows updates/AMD drivers or anything of the sort. The recent update (I'm assuming you're using the 1.13.0-beta.3 release) would've never caused the issues you're describing.
On the other hand, Vortex "removing itself", has been encountered by users that were running the application through the Vortex installer itself rather than the application shortcut (causing it to re-install every time they would run the installer). Alternatively there have been instances where some cloud storage services would revert Vortex changes (removing the `%appdata%/vortex` folder); so if you do use any sort of cloud storage solution, make sure it knows to leave Vortex's data alone.
Please note that I can't rule out hardware failure, especially given that you're encountering BSOD.
Out of curiosity, which 3rd party extensions do you have installed?

Hey all, thanks again for reporting this issue. Good news is - the bug has been fixed; bad news is we can't release anything on Thursdays as we can't provide support over the weekend. Beta.3 will be released early on Monday to fix this, in the meantime please just ignore any update notifications that point you to the website asking you to choose the update yourselves.

Hey @imprimis432,
The 'concerns me' message was directed at LeapInL which suggested that his assigned groups (manually selected) had been reset to their default values as part of the update. As vortexposer stated; Vortex has mechanisms in place to maintain the assigned groups even through Vortex uninstallation, and that piece of functionality hasn't changed in years which is why I found it odd that he may have went through that.
I see nothing wrong in the snippets you sent - as you can see, the plugins which have a manually selected group (the bold ones) no longer show the "no metadata message", while some of the others that have the default LOOT assigned groups (italic, slightly faded) have it.
Again, this is a purely cosmetic feature and if the message is displayed, it simply means that there is no metadata to sort by, which is expected for most plugins, ESPECIALLY newer ones that have yet to be added to the masterlist.

Hi there - as VortexPoser mentioned, you're currently experiencing a modType conflict - FOLON is actively conflicting with the two ENB mods you have set up. The overrides are automatically calculated based on the mod rules you defined to handle said conflicts. Changing all the conflicting mods to the same modType is indeed one solution to avoid purging on mod enable/disable/install/uninstall/update.
We do have a fix in place in 1.12 which should make the modType conflicts smoother now. So as long as you're ok with intermittent purging as you change your mods list, you should be fine either way.

Hi there - this issue is caused by a change in the mod's archive structure + one of our installers which appears to have been broken for a loooong time. Thanks for your report, the fix will be included in version 1.6.3 of the game extension.

Hi there!
The error suggests that the Vortex installation is corrupted for some reason - try re-installing and ensure you disable any security software/policies you have instated

Hi there - apologies for the late reply; been busy fixing the profile switch issue. We're currently testing a fix for it @yofamgaming
@Zanderat - it is _not_ safe to switch profiles at the moment as some overrides may be lost. Switching to an empty profile is an absolute no-no.
yofa's issue is unrelated to yours Zanderat, it's more likely that Vortex didn't remove some redundant overrides correctly, fortunately the applied fix will solve both issues.
We're currently testing things internally, but if you're interested in testing with us, please contact me on Discord (nagev_) we will ofc make sure to fully back up your state before we make any changes to ensure you do not lose anything.
- Nagev

Hi there,
The exclamation points highlight that there are file overrides defined on a respective mod, functionally they're identical to previous versions of Vortex, 1.10.8 does have an annoying bug where the overrides are applied needlessly on a whole mod basis, these are safe to ignore; we're going to release a new Vortex version next week which will clear those up.
I responded to the other forum post as well - please do not switch profiles for the time being.
 

Hi again,
New version has been released, and the preview functionality will now work as expected; please see:
 

Hey there - please read the following post:
 

Please see 
 

Hey @cooperbh,
Really sorry you had encountered this issue, please know that we never release such a big update without thoroughly testing it - @insomnious and I, have been using the updated branch since December to ensure we detect any issues that may arise on our own environments first. A preview version of this update was also made available in January for those willing to test the new functionality before the beta, and it appeared to run smoothly for our 20+ testers.
As you probably know, this update's main feature is to enhance the conflict detection logic to work across different mod types; an issue that affected Vortex for a very long time and has been limiting the app's efficacy when attempting to support new modding patterns for new and existing games. Existing modding environments have to be scanned for existing conflicts which were previously undetected, according to my tests this incurred a ~15% delay when calculating conflicts + the deployment event itself which as you know can take a significant amount of time depending on the user's mod setup (number of mods and custom rules + LOOT's sorting mechanism, etc). The delay itself would only occur during Vortex's first run which we thought was acceptable - clearly we need to further optimize this functionality to run faster and better inform the user of what Vortex is doing.
I'm afraid that stopping Vortex mid-migration and moving back to a previous version will indeed cause unexpected behavior even when rollback is technically achievable (which it should be as long as Vortex completes its first run).
Note to anyone updating to 1.10.2 - even if Vortex appears to be stuck - it's not! Please let it finish the migration, and if needed, only rollback to 1.9.X once your plugins have finished sorting.
We're currently working on 1.10.3 which will optimize the migration and ensure this never happens again.

Hi there - the cache is located inside your game's staging folder ("%appdata%/vortex/residentevil22019/mods/invalcache.json" by default unless you moved the staging folder somewhere else) - it's used to keep track of which filepaths Vortex had been previously invalidated so that Vortex can restore the filepaths as required. There's currently a bug in 1.4.9 which can cause the cache to become corrupted which should be fixed in 1.4.10 (will be released sometime this week)
 
I'm afraid that since your cache is corrupted, there's a chance that even if you manage to manually fix the cache file (you can try to do it using https://jsonlint.com/) Vortex may lose track of some invalidated file paths and therefore will never be able to restore them - this may not be a big deal if you still have a mod installed which overrides that specific filepath, but if you do manage to fix the cache file and notice weird in-game behaviour (e.g. zombies with missing heads) then you will have to delete the invalcache.json file and verify your game's integrity through Steam in order to fix that; after the file integrity check, you can click the deploy button and all your mods should be re-instated.
 
Please do not delete the invalidation cache without checking the game's integrity as that will just cause Vortex to lose track of all the filepaths it had invalidated.

Thanks for your report sticky115.
 
Anyone affected by this - please start the game at least once through the Tale Worlds Launcher as that will generate the LauncherData.xml file for you. You should be good to go after that.