Vortex 11.X has major flaws in local .zips vs meta .zips handling & various types of untracable behaviour all sourcing from a breaking change in 10.X

Describe the bug **Vortex 11.X has major flaws in local package vs meta-referenced .zip package handling in collections. You seem to have changed a major framework that handles one of your deepest running interfacing blueprints for file handling. And all the implementations that you are using in the virtual and physical file system now show its rotten teeth of the breaking change. There had to be a breaking change** that was falsely implemented in a rush or is incorrectly documented and your extensive usage pushes the framework to new edge cases. I do not want to be an asshole to dev colleagues, but to speak for the community, I will not hold back on the intensity of frustration for some of these points, that cause people to waste countless hours of their freetime.

Your influx of bugs is only the effects of this, but seemingly you have become blind to the line numbers of the core root issue.

I want to emphasize that an extra tiny bug extrapolates into tens of thousands of headache with Vortex. Pick your stance based on this take, how you read the rest of this ticket. .

Through a 46hour + 36hour shift trying to install a massive mod collection I wrote down all the madness that you are putting users through in the current state of Vortex. No normal user would put himself through this and would probably dip and use a small modpack. I wrote down a guide that has dripped through 10+ people and the resounding answer was smooth sailing through the installs if you know how to babysit vortex and its behaviours.

But the things that currently makes Vortex 11.X unusable is:

Vortex shows drastic changes in meta package policy aggression starting at 11.X
The only aid / solution for the package priority config was either very badly communicated or you just straight up didnt do that. I talked to the curator of the huge collection I source my informations from and he confirmed to me he didnt receive any info from you guys that this breaking change is coming. When you are changing things on this level, why are you not using a top 100 on your db for each supported game and send the curators the info and guides they need?

Reference: Github Patchnotes 11.3: https://imgur.com/hru0tbf

The huge point above is btw precisely why some collections get escalated into Re-Install Wars, between the collection manifest and Vortex when it comes to packages. Vortex basically always wants to have the last word and the collection manifest thinks the same, because it was designed to be exactly that, a definitive vision of how files need to be. It is beyond me why you thought this could be pushed to prod this fast. Why did none of the test cases you hopefully have ring alarm bells on this behaviour? This had to be observed during development.
In Vortex 10.8 one of your devs seemingly got frustrated with this exact issue and hotfixed it, and you are either ignoring his advice or thought it was cleared in the refactor, but this is precisely your blindspot while you are wondering where all these bugs are popping up from while you are only fixing the effects of the problem. Reference: https://imgur.com/EQjKc2H

That said, It's unacceptable that you are creating untracable behaviour that has zero indicators anywhere in the software, namely any performance monitors like task manager. Why does the UI not immediately show clearly how many MB its pulling, how many MB its r/wing to the file system, what files vortex is currently working in, etc. There was probably 20 hours passing by until I realized I could utilize task manager to trace what Vortex 11.X is doing, because Vortex 11 is behaving A LOT differently from 10.8, the only good version I am currently recommending to users. This is the only version where in my eyes, one angry, talked over senior dev pushed a hotfix his eyes saw and you collectively thought the refactor would solve that. But he saw and fixed something that day that is now hanging over Vortex like a gigantic guillotine. The current state of Vortex only engrains the userbases thoughts of "Vortex is shit".

Again, I do not want to be toxic, but only being authentic here helps. I am no PR guy, but I am also a paying customer for the subscription, so I hope you understand where the tone comes from. Bottomline I want to help out and I will happily provide all the insights that I have written down in a huge guide over 80 hours. Please reach out in DMs if you want privacy in communication @devs.

Continuning, I would definitely recommend your team to invest in atleast setting up docker containers in the github actions that build your release candidate, when its done, deploy it to a testserver, and then let the new Vortex build install the top 3 collections of the top 10 most modded games, so you can check if the new behaviour aligns with a users experience.

Ultimately, it doesn't matter to users, or to you if a build comes one day later or earlier, but you are suddenly creating an ideally one-time-setup extra steps that massively increases the QOL, and experience for the entire userbase, a better look at the product and company, and probably a much better working day-to-day for you developers. I can only imagine sitting in your development environment with a full view of the entire crazyness, so I definitely want to approach you in a polite manner. I mean well, even tho everything above is written like a enraged reddit post. My take definitely will have flaws and you are happy to correct me, but It wouldn't feel right to hold back my informations and all that I've learned if it means I can reduce stress in the community, for both the players and you, the developers.

Best wishes, Sora

To Reproduce

Download any Vortex 11.X and enjoy the nightmare

Expected behavior

A tracable file system behaviour that doesn't start re-install wars with collection with custom third party site packages.
The .zip meta vs local file system code from the fix that was pushed to 10.8 prod

Platform (please complete the following information):

OS: Windows 10, 11

Hi @sora-1337, first of all thank you for your report.

I think it's better if we start by covering the "why" behind the 1.10.x and 1.11.x changes.

1.10.x:

Vortex's conflict system pre 1.10.x was crippled by its sequential deployment of modTypes. This made detection of file conflicts between different modTypes impossible with the current deployment system; as a result Vortex would complain about external changes when there were none. Modifying the deployment system itself at this stage would require a massive re-write, something we simply do not have the resources to do, especially given that Vortex is being deprecated in favour of Nexus Mods App.

Depending on the options selected by the user in the external changes dialog, mod files would get deleted or even imported into the other conflicting mods in the staging folder. The user would then be left with a situation where if he disabled/uninstalled one/several of the conflicting mods the mod files would still be present causing unexpected behaviour at best, or more commonly - game crashes.

This is where file overrides came into play - a mod with file overrides will not deploy its files regardless of which modType it is, guaranteeing that Vortex no longer mistakes file changes it makes as external changes and avoiding breaking the mods in the staging folder. Frustratingly, there is no way for us to backwards fix environments that have already been affected by the unrecognized file conflict bug in pre-1.10.x versions; which I suspect is the main reason why so many users are having trouble with that update, as Vortex is reporting conflicts that should not have been there in the first place! (e.g. SKSE folder in staging containing .esp files and/or patched/modified dynamic libraries, creating a file conflict with mods of different modTypes)

Unfortunately the deployment system is still sequential from a modType perspective and does not adhere to deployment rules; what this means is - for us to ensure that the correct files are deployed to the game's folder, a purge MUST occur before a deployment takes place when a modType file conflict is detected. Enabling/Disabling/Installing/Uninstalling/Updating a mod which has any sort of connection to the modType file conflict will unfortunately force Vortex to purge before deployment. (We're working on ways to alleviate this but the purging is here to stay)

That being said, we were naive from a UI/UX perspective - the defined overrides need to be clearer to the user especially when a a file override is part of a modType conflict. We have been experimenting with different ways to assist in that perspective so that users can debug their environments more easily https://github.com/Nexus-Mods/extension-mod-dependencies/tree/experimental-file-overrides-table-attribute

We are tracking progress for these additional tools/design changes in https://github.com/Nexus-Mods/Vortex/issues/15765 Please do share your thoughts regarding the file override UI/UX on that ticket.

1.11.x:

The stricter mod reference comparisons were requested by the curators themselves - pre-1.11.x versions would simply skip mod installations based on ids and tags resulting in a widely different modding environment on the user's end than what the curator intended; besides potentially completely breaking the user's mods environment, the curators would get the brunt of it, as users would downvote the collection itself into oblivion and chase the curator for something he had no fault in.

The local vs meta .zips handling was never an issue in previous versions, because they were never compared in the first place; resulting in hundreds if not thousands of collections that were uploaded with potentially invalid metadata (Most prominent in Witcher 3 collections).

That being said, now that we do enforce stricter mod references - we can actually do something about fixing the collection metadata. Can you please create a small collection which exhibits the behaviour you're describing so that we can debug it.

Questions

You mentioned you've identified that Vortex is not clearing redundant file overrides correctly even after the user has resolved a conflict?
Are you able to give us pointers to reproduce this? So far every modding environment we've debugged was affected by the issue I mentioned above (orphaned/deleted mod files), or was simply part of a modType conflict which unfortunately requires the purging mechanism to execute due to the current deployment system.

Final notes

Both versions have been in beta for over 60 days (1.10.x has been in testing since December 2023 before being released to the public sometime in March or April), we did not rush any of these releases.
Both versions and their changes were announced on the forums and on Discord a week before the actual release. To increase visibility going forward we should probably start announcing these sort of updates via a news post on the website.
We're 2 devs catering for ~150k Vortex users on a daily basis, sometimes certain forum posts/discord messages are left unread; please tell other users to follow your example and ask them to post their reports on our Github issue tracker so we are immediately aware of their troubles!
Vortex is pretty much at its limit from an architectural point of view and it's made obvious by its degrading performance. Adding additional logging which is only relevant to a minor percentage of users will only degrade the application further. In fact one of the reasons why you spent so long downloading and installing that collection was down to excessive logging which was fixed and will be released as part of 1.12.x https://github.com/Nexus-Mods/Vortex/issues/15883

yapping: Sorry for the late response, my personal life got really turbulent. I only have time for a few words, but I have this thread watched so I see immediately when you reply. Maybe its better for me mentally too to keep things shorter if thats fine, I think overwise I might have tendencies to try to put together one perfect solution ... but that doesn't work too well for me.

Answer 1) Correct. The file system libaray core internals that you use - (assuming you didnt mess with a seperate backend and its a all in one electron node.js workstack) - namely electron & node.js have shown weird behaviour during my web development times. Citing myself:

This is personal placebo observance, your brain is free to throw that away as outdated yapping. But this is the line that shapes the bad wolf for me, it feels like electron is definitely maxxed out ... and to be really fair with you, a load of over a terrabyte, is a serious real-life stress test for any system and architecture, so that Vortex is the one catching the breaking points of all sides, I can see how this can throw a dimm light on the devs that mean well and actually care for their product. (You would have responded a lot different if you didnt, thats why I am putting some work into my responses).

Answer 2) Yes, I can.

I know that tickets get shitty work after the initial whining by users, so I'll try to dig out the roots for as far as I can see without having ever seen the code base and my wild assumptions. I have asked somebody from our staff to put together an example collection, that concretlely shows this behaviour on Vortex Versions later than 10.8. All 11.X vortex versions that we have seen users come to our server were hit with the same grueling re-install war.

I will go into detail what happens shortly, feel free to maybe refill your drink and download the collection while you read the rest.

https://next.nexusmods.com/skyrimspecialedition/collections/2pka2e?tab=mods

The concrete, offending mod is: High Poly Mod 1.4. A very important core mod for most serious high tier modding for the pack we try to curate.

Note: I myself am just a fresh helping hand that wrote down his technical anger and nightmare with Vortex 11, so I was invited to the Staff as I have a significant technical background that allows me to hopefully paint understandable pictures. If you need core info I will try to package, shape & provide information that you two need between the curator and you in the dimension I see fit as a middleman.

Vortex usually starts indexing meta data, it does some warmups, it spawns node.js workers ... all that jazz. Then I think its a bit RNG if it either gets in a good scheduling with the mods and you can estimate for a a dozen mods that they drip in like butter, how you as a developer probably want to see your system. Good till here.

Now, after a while Vortex will hit its knee and cry that it found High Poly Mod meta-data or it found a version itself on Nexus (i dont know how much vortex talks to the APi, i couldnt be assed to WireShark it) - you have this in your mental code flow anyway.

So this the exact moment when the first popup will now hop up in your screen ... Vortex offers you a poisoned deal.

It thinks that its solution to grab a meta.-file over a local .zip is the way to go - if I imagine the in-chair office talk or slack decision, I wouldve done it no different. It's a unluckily a unflexible wall that doesn't offer the user to control that behavior,

If you press "install alternative", the mod-pack will see it as missing later - not an option. If you press override you are now entering the reinstall-war, the mod-pack will now start fighting Vortex 11.X (I have reports up to 11.4 ... 5 ....6 ? of this happening, as our advice boils down to ... get 10.8 until 12.X comes with a clean fix.) Vortex will now reinstall the meta-sourced .zip I believe (its been a few weeks) and then continue on with its schedule that the node.js workers stream to the Electron UI. Now... one of the other workers that runs collection data will come back after a few seconds / minutes and tell you, again, that the Install of High Poly Head 1.4 was corrupted... the archive damaged... not the right one ... this line of tone. (I don't know how specific your exceptions are thrown).

If you got this and are now stuck with it too, you're in our boots. We have realized that the newest revision of the mod pack actually starts to have issues with this behaviour on 10.8 now - but these are unconfirmed and could be purely user-error related, but the consistency in the synced DMs hitting my guide thread were a bit ... telling? My brain jumped to maybe vortex rolling out extra meta files as described in the GitHub notes regarding the new meta-files used for mod structuring (if I am para-citing this correctly)

i think a checkbox in the settings for a "Expert Mode " or "Ignore Automatic Meta-Sync" ... something like that ... would probably hold your workload to fix it manageable, but gives us a tangible non-invasive option to maybe slither around it without you having to refactor a mission-critical code snippet. I do not want to push extra workloads on a project with probably tightly planned budgets and tickets. (I don't know how you work)

I think from here on you would probably start skimming since you can now fidget with my mindset in Vortex 11. To give you a reference point you can maybe do a git-diff against, definitely pull up Vortex 10.8. I can hard confirm / safe call this version is a golden one,

Important, you need to either disable networking for Vortex or create a 10.8-noupdate vortex, otherwise Vortex will update silently after a quick restart and muddy / confuse you with totally new behaviour. Figuring this out took a dozen people and quite a few man hours....

From here on out.. you see more than me with the Debug Tools. If your development kit PCs don't produce my described bug scenario in the UI as I described, please get back to me, we have concretely named .zip names documented.

Sorry for the delay, I hope this helps as a good base level specifications for the tickets.

Best wishes. Sora

Hi @sora-1337, I think this is down to a misunderstanding on how google drive downloads work.

Any file hosted on Drive which exceeds a certain size will be redirected to Google's consent portal which informs users that the file could not be scanned for viruses due to its size. The High poly mod you attached is over 180MB which is guaranteed to send Vortex an HTML page rather than the actual download link - Vortex cannot use that html page to ascertain what to download and is therefore raising the "dependency failed to download" error.

The link you provided as part of the collection's metadata is: https://drive.google.com/file/d/15_0njBUjHKidNnJPmLXEygzGVWsA3Zbq/view?usp=share_link

That should be changed to: ~~https://drive.usercontent.google.com/download?id=15_0njBUjHKidNnJPmLXEygzGVWsA3Zbq&export=download&authuser=0&confirm=t&uuid=xxxx&at=sdgwgw%3A1719310998834~~

Once you're using the correct download link, it should be perfectly possible for your users to re-download and install the archive from Drive even if they do install an alternative to that mod.

Regarding how Vortex decides to pull metadata - it only offers to override a mod from an external source if the md5 of that mod matches an entry on our API (our md5 checksums are generated based on the byte contents of the files).

I'm currently investigating an issue where some collection metadata does not seem to update correctly upon uploading new revisions of a collection. It's possible that the md5 checksum among other properties are not updated correctly as part of the revision update (i.e. old data is not replaced/removed correctly) https://github.com/Nexus-Mods/Vortex/issues/15968 - seems to me that this is the actual culprit.

This bug has probably been in Vortex for a very long time, and we're only now aware of it thanks to the stricter controls we put in place in 1.11.x

@sora-1337 looks like that link won't work after all - will need to find a way around the consent portal. Don't update your link yet.

Thank you kindly going into clear details like this, this makes a lot of sense now seeing it picked apart live.

I can maybe half-confirm your gut feeling, I have a sense that in the UI where you track file changes, theres one cycle of runners🏃 missing to collect the 'last tickets 🎟️'. This has probably been done in the performance architecture steps to mitigate unnecessary constant extra load on the drives.I dont know how friendly windows 10/11 is with providing newfile-event sinks.

Our go-to advice for users is simply 'delete a non-invasive cosmetic mod & re-add, it will refresh your local .zip'. That process obviously sends new runners 🏃 that see the lonely orphaned file system UPDATE tickets 🎟️.

Maybe that input helps.

Yeah something is definitely off - probably memoization of something that shouldn't be.

Not sure if you read my last edit above - that link is tied to my own uuid so Google will still send other people to the consent portal. I need to open up a webview for the users to manually click "download anyway".

Don't update your collection yet!

My eyes caught the update. Thanks for being this responsive.

We are holding our feet still, as I managed to write up a huge workaround guide that guarantees a 100% smooth one click install. :)

Please, no stress, work at your pace - thats when people produce the best code.

You're quick.

We'll I am happy if I set you on the right rails to fix these. I will definitely let you grind out your flow.

Since this is a closing ticket, are you interested in helping each other?

We surely could start an open poll in the server, send that over and let you have a look at a real unfiltered view on edge cases, stomach aches and confusions.

The collection we maintain is definitely what Tarkov was for Unity after they hit limitations, so I thought I'd draw that parallel and bounce a - in my eyes - healthy offer for both parties.

Speak with your team and lmk.

Nexus-Mods / Vortex