Jump to content

Vortex Not Handling my Junction Links


Vyxenne

Recommended Posts

My games, and hence my Vortex Mod Deployment drive, are on an SSD. However, since I don't need SSD speed for Bodyslide operations, I installed Bodyslide on a regular HDD and created an empty Data\CalienteTools\BodySlide folder on my SSD which I then converted to a Junction Link pointing to the actual BodySlide folder on the HDD.

 

This arrangement has worked fine for years (with NMM) but now, suddenly, instead of installing new BodySlide SliderSet and ShapeData files "seamlessly" into the Junction-Linked Bodyslide folder, Vortex instead renames the BodySlide files, changing their extension- for example "Scarlet Dawn Armor.xml.VortexBackup" (or very similar words) which of course disables the BodySlide xml's (or osp's or osd's or nif's or whatever) and leaves me with a completely useless set of *.VortexBackup files when in reality the BodySlide files are ***right there!*** but rendered useless by Vortex due to tacking on the bogus file extension.

 

Meanwhile, Vortex installs the *actual* BodySlide files with their correct names and extensions to its "virtual" path, something like \blah\blahVortex\mods\virtual install\blah\blah but of course this is useless because it is not in the SSE\Data\CalienteTools\BodySlide path structure where BodySlide needs them to be. I've been wondering for months how I was installing new BodySlide files with Vortex but they weren't showing up for use in BodySlide!

 

Every other Windows program known to man (OK, the seven of them I've ever dealt with :tongue:) handles Junction Links seamlessly, pretending that the folders and files exist at the linked-from location even though they are actually at the linked-to location.

 

Please, why is Vortex forcing me to manually delete all of the bogus *.VortexBackup files and then manually copy all of the misplaced BodySlide files from the "virtual install" folder into the SSD (where they actually end up on the HDD since the entire BodySlide path structure does not actually exist on my SSD) instead of treating the Junction Link like every other Windows program treats it? Is there some setting or change that I can make to whip the li'l bugger into shape and make it mind?

Link to comment
Share on other sites

+1, would like to know this as well, since i make heavy use of ntfs junctions to setup my multiple mod loadouts.

 

VO not handling junctions gracefully is one of the key reasons i haven't done the transition yet. and now MO2 even brings bsa-loosefile conflict detection to the table...

Link to comment
Share on other sites

+1, would like to know this as well, since i make heavy use of ntfs junctions to setup my multiple mod loadouts.

 

VO not handling junctions gracefully is one of the key reasons i haven't done the transition yet. and now MO2 even brings bsa-loosefile conflict detection to the table...

 

You can use "Profiles" in Vortex for multiple mod loadouts, no need for ntfs junctions.

 

Link to comment
Share on other sites

 

+1, would like to know this as well, since i make heavy use of ntfs junctions to setup my multiple mod loadouts.

 

VO not handling junctions gracefully is one of the key reasons i haven't done the transition yet. and now MO2 even brings bsa-loosefile conflict detection to the table...

 

You can use "Profiles" in Vortex for multiple mod loadouts, no need for ntfs junctions.

 

 

 

Tried that, does not fit my use case. Except something changed and mods which are currently not used (i.e. from other profiles) are not displayed in the current profile. i don't need to see 500 mods with a "disabled" status.

Link to comment
Share on other sites

 

 

 

i don't need to see 500 mods with a "disabled" status.

 

 

 

Then turn on the ENABLED filter

 

BEFORE:

 

 

*snip*

 

AFTER:

 

*snip*

 

 

 

i'm well aware and appreciate the images. it just is more of a band-aid instead of a solution - it would bug me to no end that i *could* have the real thing when i actually need to use this filter and find a mod that's uninstalled in this profile :pinch:

 

anyways, we're getting OT

Link to comment
Share on other sites

@ Vyxenne:

 

While I'm not sure how you're setup the various directories, for simplicity let's say you're got the game + Vortex mods-directory located on c:, while the linked Caliente-directory is located on d:

 

This means "Scarlet Dawn armor.xml" is physically located on c:, while Caliente-directory is physically located on d:

 

Vortex uses hard-linking, but hard-linking only works if all links is physically on the same drive.

 

This means what you're trying to do can't work as long as Vortex is using hardlink-deployment.

 

The only way you can use hard-linking is if game + Vortex mods-directory + linked Caliente-directory is physically on the same drive.

 

As for the .vortexbackup, if you have manually installed some files outside of Vortex and a mod installed in Vortex replaces one of the manually installed files, the manually installed file is re-named with a .vortexbackup at the end. If you disable the mod adding the new file, or if you hit Purge on Vortex mods-tab, the original file will be restored, meaning without the .vortexbackup at end of file-name.

Edited by Rattledagger
Link to comment
Share on other sites

Just want to add.

No one is forcing you to use Vortex. If you have a solution that works for you, keep using it.

Just don't expect Vortex to change to handle your unique use case.

And having game files spread across multiple physical drives is a unique use case.

 

Well one more comment.

There is absolutely no need to install Bodyslide as a Vortex mod.

If it is on a different drive, just install it manually.

No need for Vortex to ever know about it.

Edited by rmm200
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...