Nice as a user, but kind of painful as a modder

[BigBizkit]

If you haven't already, you can send in a feature request via the three dots in the top right > Send Feedback > Suggestion. That way, it won't get lost.

[tesnexus8]

Thanks - I'm fairly sure I did, but I've done so again just in case.

 

I've also found a possibly-relevant piece of logfile, which I've pasted below.

 

The most-easily noticed case of the silent-overwrite bug is an armor that I took the pauldrons off with NifSkope. After Vortex does its deployment - of, again, just to emphasise this, a DIFFERENT mod - on returning to the game it's immediately obvious that the locally-modified file has been replaced, with no prompting.

 

Note: this particular mod installs itself as loose files, which may be relevant / helpful in tracking down the problem. (Though it's not limited to loose files, as Vortex also overwrote an ESP that had been modified).

 

From vortex.log:

 

Sun, 28 Jul 2019 05:24:30 GMT - info: start mod install id=slcuirass_1

Sun, 28 Jul 2019 05:24:31 GMT - warn: failed to query by key error=Please provide an API Key with your request, gameId=skyrimse, key=4ebb9ea4fa73194e37b1629cbf5a1c20:4704359:skyrimse, server=https://api.nexusmods.com

Sun, 28 Jul 2019 05:24:31 GMT - debug: got mod meta information archivePath=H:\xfer\skyrimSE\unzip\Silverlight Armor 0992 CBBE SSE\meshes\armor\Silverlight\slcuirass_1.nif, resultCount=0

Sun, 28 Jul 2019 05:24:31 GMT - debug: mod id for newly installed mod archivePath=H:\xfer\skyrimSE\unzip\Silverlight Armor 0992 CBBE SSE\meshes\armor\Silverlight\slcuirass_1.nif, modId=slcuirass_1

Sun, 28 Jul 2019 05:24:31 GMT - debug: installing to destinationPath=D:\games\VortexStaging\skyrimse\slcuirass_1, modId=slcuirass_1

Sun, 28 Jul 2019 05:24:31 GMT - info: using install path fileName=slcuirass_1, id=slcuirass_1, installPath=D:\games\VortexStaging\skyrimse\slcuirass_1

Sun, 28 Jul 2019 05:24:31 GMT - debug: extracting mod archive archivePath=H:\xfer\skyrimSE\unzip\Silverlight Armor 0992 CBBE SSE\meshes\armor\Silverlight\slcuirass_1.nif, tempPath=D:\games\VortexStaging\skyrimse\slcuirass_1.installing

Sun, 28 Jul 2019 05:24:31 GMT - debug: extraction completed code=2, errors=[ERROR: H:\xfer\skyrimSE\unzip\Silverlight Armor 0992 CBBE SSE\meshes\armor\Silverlight\slcuirass_1.nif

Can not open the file as archive

 

]

Sun, 28 Jul 2019 05:24:31 GMT - warn: extraction reported error code=2, errors=[ERROR: H:\xfer\skyrimSE\unzip\Silverlight Armor 0992 CBBE SSE\meshes\armor\Silverlight\slcuirass_1.nif

Can not open the file as archive

 

]

Sun, 28 Jul 2019 05:24:35 GMT - info: finish mod install id=slcuirass_1

 

(D: is an SSD with the game on it, H: is an HDD that mods are downloaded to (and installed from) to save SSD space).

[tesnexus8]

Come to think of it, I have absolutely no idea why Vortex is referencing that folder on H in the first place! The mod wasn't installed from that unzipped set of files, and the modified nif was just copied to the game folder with Explorer. Vortex has never been "pointed at" it. So it must be that when something was installed from the "xfer/skyrimSE" folder, Vortex opted to scan the entire tree below that, even though what was installed was a specific archive, ie a single file. That seems unlikely, but it's the only thing I can think of for how Vortex even knew that path with the nif in it existed in the first place.

[Rattledagger]

The most-easily noticed case of the silent-overwrite bug is an armor that I took the pauldrons off with NifSkope. After Vortex does its deployment - of, again, just to emphasise this, a DIFFERENT mod - on returning to the game it's immediately obvious that the locally-modified file has been replaced, with no prompting.

 

 

I'm not sure exactly how your setup is, but I did a quick test with NifSkope. Since NifSkope can open files outside the data-directory I basically did the following steps:

1: Copy a cuirass_f.nif to a new empty directory.

2: Make a hardlink-copy of this file to another empty directory, to simulate Vortex mod-deployment. Verified #hardlinks is 2.

3: Opened-up NifSkope, opened-up cuirass_f.nif from directory 1, selected something that became green in NifSkope, right-click, Block, Remove, followed by saving and exiting NifSkope.

4: Checked the date on cuirass_f.nif, it's today, instead of last year. Also checked the copy in 2nd. directory, it's also updated. Verified #hardlinks is still 2.

 

Meaning, even if I did edit a file in NifSkope, this did not break the hard-link, and since Vortex keeps track if the hard-links are still present or not this means where's no way for Vortex to know you've done any changes at all.

 

So, just a guess of your setup, let's say you've got mod A that includes some files including example 123.nif. After installation you enable mod A (but don't deploy yet).

5: 123.nif is now present in mod A's directory. #hardlinks is 1.

6: You now deploy. ==> 123.nif is now present in both mod A's directory and data-directory. #hardlinks is 2.

7: You runs NifSkope, open-up 123.nif in data-directory, does some changes and saves. ==> #hardlinks is still 2. Meaning, you've now got the updated file residing both in data-directory and under mod A.

8: You install and enable mod B that also includes 123.nif

9: Since A and B both includes 123.nif, you choose mod B to "win" the conflict.

10: You deploy, and since before deploy 123.nif in data-directory == 123.nif under mod A, where's no "external change". Instead, Vortex removes 123.nif from data-directory, and creates new hard-link to 123.nif for mod B.

 

The end-result is, the edited file is now present in mod A, while mod B's file is in data-directory. If you disable mod B, the edited file will re-appear in data-directory.

 

If you on the other hand is not installing example 123.nif as part of a mod before you edit 123.nif, then you deploy mod B you should have a file 123.nif.vortex_backup in data-directory.

 

While I'm not sure how your setup actually is, at least my quick test reveals NifSkope does not break the hard-link then you save the file and for this reason Vortex won't detect any "external change".

 

From an earlier test Notepad is the same, you won't break the hard-link, meaning again no "external change".

 

I've not tested other tools, meaning I've no idea if xEdit breaks the hard-link then you edit esp, and neither what happens if you uses the Creation Kit to edit esp.

 

If you uses Vortex to toggle ESL-flag on/off, you will break the hard-link, meaning at least here you should get "external change" next time you deploy.

[tesnexus8]

Thanks Rattledagger. That's far more clever than anything I did though: I don't use hardlinks for stuff like this, I just copy the files (because it's easier, and it also automatically means I have a backup in case something gets splattered in Data/).

 

I did just run across an interesting comment over here: https://forums.nexusmods.com/index.php?/topic/6355031-a-few-tips-from-the-focus-group/page-8&do=findComment&comment=67171231

IDK how authoritative it is, but:

"To summarize: Do not install from file. Always place the archive in the Download Folder and then install from the Vortex mods page."

 

I, of course, ALWAYS use "Install from file", because the archives live on spinning rust but the games and Vortex are all on SSD. I still have no idea why V is looking in that folder in the first place (let alone if that's what's triggering the bug) but it can ONLY be because I've used "Install from file" for files in its parent folder - there's no other action or setting that has ever referenced anything on that drive at all.