Is there any way to rename mod files to all-lowercase/uppercase before/during deployment/activation?

[northsidedown]

For context: I'm using Vortex 1.0.2 on Linux (via Proton 4.11-3), right now exclusively for Fallout 4. It seems like the modding community/ies for Bethesda's games (and/or perhaps Bethesda themselves) are averse to maintaining any consistency between uppercase and lowercase letters in their folder and file names; this normally ain't a problem on Windows (since Windows is case-insensitive), but causes problems on Linux (with various mods either entirely not working or frequently bugging out).

 

The two typical workarounds to this issue:

1. Rename all files to a consistent casing scheme (e.g. all-uppercase or all-lowercase) before installing
2. Install to a case-sensitive filesystem (e.g. a separate NTFS partition, or a "wrapper" FUSE FS like ciopfs)

Both of these are kind of a pain to do (renaming everything won't make it easy to account for installation/patching order, and moving to a different FS means a lot of file-copying and mountpoint-creating and such), so it'd be neat if Vortex just did it for me; I suspect Option 1 would be the simplest.

 

It looks like there is indeed code in place to "normalize" filenames during deployment, including renaming everything to uppercase: https://github.com/Nexus-Mods/Vortex/blob/master/src/util/getNormalizeFunc.ts

 

However, it doesn't look like that's happening by default (as evidenced by the proliferation of "meshes" v. "Meshes", "textures" v. "Textures", etc. in my "Fallout 4/Data" folder). Perhaps it's turned off for Fallout 4? If so, is it because the base game doesn't default to all-uppercase? If so, would it be possible to somehow tell Vortex to turn that on anyway (under the assumption that I've, say, already renamed everything in the original install directory to all-caps)?

 

If there's no easy way to do this (and/or no easy way for me or someone else to patch this in; I'm an experienced programmer/sysadmin, but neither Electron nor Typescript are in my wheelhouse per se), then I'll probably resort to ciopfs, but this seems like something Vortex should be able to easily handle.

 

Thanks!

[Tannin42]

The normalize functionality you linked to is only used internally when doing name comparisons, it doesn't actually change the names on disk.

 

Sorry, but these games and a lot of tools surrounding them are written exclusively for case-insensitive filesystems. Renaming files will not solve your problem because files may still referred to by their original names.

So for example loot might have rules for "FooBar.esp". If the file on your disk has been renamed to "foobar.esp" but the filesystem is still case-sensitive, that is still a different file and the rules don't get applied.

 

Using a case-insensitive virtual layer (a fuse fs for example) is the only proper solution that doesn't have the potential of breaking something else.

 

It's the job of the emulation software to mimic the platform as closely as possible, it's not the job of applications to be designed for being emulated.

[northsidedown]

Fair enough; ciopfs it is, then.

 

Worth noting that (I think / in my observation / if I'm understanding the docs right) Wine (and therefore Proton) will still do case-insensitive file accesses (so if LOOT requests FooBar.esp, Wine will find and return foobar.esp); the issue is solely if FooBar.esp and foobar.esp both exist. Unless LOOT's doing something extra fancy there and actually checking for case itself?

 

Either way, thanks for the quick response on this.

 

If I do (at some point) end up chasing down a way to force-upper or force-lower filenames, then (assuming it's up to par quality-wise) would y'all be receptive to a PR for it (as a "use this at your own risk and we offer zero support for it" type of option)?

 

EDIT: also, I've only really noticed this with loose files, so I don't think LOOT would be impacted anyway.

[northsidedown]

Alright, so I went the ciopfs route. Unfortunately, Vortex really doesn't seem to like it.

 

Long story short: Vortex is insisting on using hardlinks even though I've set it to use moves instead. Logs (from enabling/deploying a single mod into the newly ciopfsified folder): https://pastebin.com/BJYPNAaY

 

Further details:

 

Vortex's mod path is at "C:\users\steamuser\Application Data\Vortex\fallout 4\mods" (where "C:" is "/home/northrup/.steam/steam/steamapps/compatdata/377160/pfx/drive_c/"). Fallout 4 is installed at "Z:\home\northrup\.local\share\Steam\steamapps\common\Fallout 4" (where "Z:" is the root of my machine's filesystem - i.e. "/"). Previously, these two paths were technically on the same partition (despite Vortex seeing different drive letters), so there was no problem deploying.

 

However, now the install folder is technically on a different filesystem/"mount" entirely, so hardlinks no longer work. Vortex is able to create the folders just fine, but doesn't write any files at all, complaining "39 files were not correctly deployed".

 

The culprit, of course, is that I forgot to switch from hardlinks to moves for mod deployment, so I changed that setting in Vortex. However, the setting doesn't seem to make a difference; as evidenced in the logs, Vortex is still trying to do hardlinks, so it's still failing. Uninstalling, reinstalling, and redeploying the test mod didn't seem to work, either.

 

Any way I can force it to move instead of hardlink? Is the deployment/activation strategy cached somewhere or something? At this rate I'm tempted to do the moves by hand (and just use Vortex for downloads, initial mod installation, and turning plugins on and off).

[Tannin42]

It's not using hard links but move deployment is also limited to work within one drive because moving between devices would be extremely slow (because that would actually

be a "copy & delete original" operation).

Vortex usually warns about this but I guess the virtualization in place here confuses the check.

 

You have to have the staging folder on the same drive as the game, there is no way around that.

 

 

> If I do (at some point) end up chasing down a way to force-upper or force-lower filenames, then (assuming it's up to par quality-wise) would y'all be receptive to a PR for it (as a "use this at your own risk and we offer zero support for it" type of option)?

 

We don't currently have a way to rename files during deployment but writing an extension that reacts to a mod being installed and then goes through the files to

rename them all shouldn't be particularly complicated.

 

If you wrote an extension for that you could publish it on https://nexusmods.com/site for other linux users.

[northsidedown]

Thanks for all the quick responses!

 

It's not using hard links but move deployment is also limited to work within one drive because moving between devices would be extremely slow (because that would actually
be a "copy & delete original" operation).
Vortex usually warns about this but I guess the virtualization in place here confuses the check.

You have to have the staging folder on the same drive as the game, there is no way around that.

 

Yep, that's what I gathered searching the forums after posting (that's what I get for not searching before posting, lol). After doing some more surgery (creating a separate "/home/northrup/ciopfs-mounts/fallout4(.raw)", mounting "fallout4.raw" to "fallout4", moving a clean "Fallout 4" and the Wine prefix into that new folder, then symlinking back to the original locations) - thus putting the Vortex and Fallout 4 data back on the same partition - I managed to get it working; Vortex now hardlink-deploys successfully (albeit with a quirk where it thinks every file it's deployed has changed, so if I undeploy a mod I have to tell Vortex that yes, save the changes please), and Fallout 4 launches fine, albeit rather slowly (and, indeed, at least some of the bugs with my current mod set have magically resolved themselves).

 

The tooltip/info for the move deployment option seems to strongly imply that moving between partitions is possible ("if mods aren't on the same partition as the game this will be extremely slow"); I'm guessing "experimental" can mean "the built-in description of it might not necessarily reflect reality" :wink:

 

 

IWe don't currently have a way to rename files during deployment but writing an extension that reacts to a mod being installed and then goes through the files to
rename them all shouldn't be particularly complicated.

If you wrote an extension for that you could publish it on https://nexusmods.com/site for other linux users.

 

Cool cool. I'll definitely look into that. Would said extension be able to act between each mod being installed? i.e. first mod gets installed, extension lowercases its files, second mod gets installed, extension lowercases its files (overwriting anything already there), etc.? I'm gradually wrapping my head around how extensions work and how to register handlers for various events, but it seems like deployment/activation is in turn an extension and it's throwing me for a bit of a loop at 1AM :tongue:

[Tannin42]

There are basically two kinds of "extensions". Proper "extensions" can be disabled and Vortex would still continue to work, this is basically the extensions that have separate repositories on github.

hardlink_deployment, mod_management and so on, stuff in the src/extensions directory within our main repo also use the same extension api and they _could_ technically be turned into separate modules but because they are so important to the core functionality and because it would be really inconvenient for maintenance to have them really factored out they are maintained as part of the core application and not toggleable.

 

But yeah, just about everything in Vortex goes through the extension api and all components basically just do their own thing and synchronize with each other only when necessary and through events that get triggered or changes to the application state. This can be confusing because it's hard to see the order things happen in or what happens if one component fails but it also means that components can be developed without considering the rest of the application too much.

 

> i.e. first mod gets installed, extension lowercases its files, second mod gets installed, extension lowercases its files (overwriting anything already there), etc.?

 

This wouldn't be a problem or at least I don't see a problem right now. Since Vortex keeps every mod in a separate staging folder from which it then gets deployed, if you lower case the files therein that has no effect on other mods and isn't affected by other mods.

The only thing that might end up being problematic is that Vortex may enable and start deploying a mod immediately after it got installed and this may then happen in parallel to what you're doing since it triggers on the same event. In that case Vortex would then, on the next deployment, consider each file renamed after deployment as one file deletion (original name) and one file creation (normalized name) and ask the user whether to keep or revert that.

 

If this turns out to be a problem you might have to look into the "will-deploy" event. Unlike most events "will-deploy" isn't a fire-and-forget event, the deployment process will actually be paused until every handler has completed. You could have a callback for that event, go through all mods that haven't been converted, do the conversion there and only return from the "will-deploy" handler when everything is done.

This ensures everything happens in the proper order.