WineHQ

Mod Organizer

No Screenshot

Submit Screenshot

The latest 64-bit version of ModOrganizer with support for both newer 64 bit games (Skyrim Special Edition. Fallout4) and older 32 bit games (Skyrim Legendary Edition).

Application Details:

Version: 2.x.x
License: Free to use and share
URL: https://www.nexusmods.com/skyr...
Votes: 0
Latest Rating: Bronze
Latest Wine Version Tested: 3.18-staging

Maintainers: About Maintainership

Link Source Code Link Development Discord Server Free Download Skyrim SE Nexus Mod Page

Test Results

Old test results
The test results you have selected are very old and may not represent the current state of Wine.
Selected Test Results

What works

  • Everything seems to work without issues.
  • All the MO2 interfaces work and it installs mods.
  • All menus work.

What does not

If you launch the game via MO2 you will get to the main menu of the game but on trying to load a save or make a new save it looks like game hangs.

Workarounds

MO2 uses Microsoft Visual C++ 2017,  due to a bug with direct installation, I recommend using 'winetricks vcrun2017' to get the run-time libraries to work correctly.

What was not tested

  • Verifying if the mods work 
  • Getting in the game to test mods.

Hardware tested

Graphics:

  • GPU: Nvidia
  • Driver: proprietary

Additional Comments

Not too sure what is causing this loading issue with the MO2, hopefully someone can shine more light on it.

selected in Test Results table below
Operating systemTest dateWine versionInstalls?Runs?Used
Workaround?
RatingSubmitter
ShowArch Linux x86_64Oct 23 20183.18-stagingYes Yes NoBronzeZenAnonX 
CurrentGentoo Linux x86_64Aug 27 20183.14Yes Yes YesGarbagecallum haynes 
ShowArch Linux x86_64Jun 23 20183.10-stagingYes Yes NoSilverJarrard 
ShowLinux Mint 18.3 "Sylvia" x86_64Jan 04 20183.0-rc3Yes Yes NoBronzeA.J. Venter 

Known Bugs

Bug # Description Status Resolution Other apps affected
46697 NtQueryDirectoryFileEx needed by Mod Organizer 2. UNCONFIRMED View
47931 USVFS requires Shell32 implementation using Windows APIs UNCONFIRMED View

Show all bugs

HowTo / Notes

Bypass failing VFS

This is required to make mods load properly ingame untill VFS works properly in wine. Thanks @Jarrard and @A.J. Venter for this workaround.

VFS script by A.J. Venter is needed for this workaround, get script from here.

  1. Enable mods in Mod Organizer.
  2. Close(or keep running) Mod Organizer and run "python movfs4l.py". This will create the VFS for game to recognize mods.
  3. Launch game from skse_loader.exe directly. DON'T launch the game from MO.

Re-run script before game launch whenever new mods are enabled or disabled.

To stop VFS, run "python movfs4l.py UNVFS"

Fixing Fonts

Enable subpixel font smoothing

  • winetricks fontsmooth=rgb

Disable render extension for client side fonts

  • Open wine regedit, and inside HKEY_CURRENT_USER\Software\Wine\X11 Driver make an entry for "ClientSideWithRender"="N"

Reference - https://wiki.archlinux.org/index.php/wine#Fonts

Comments

The following comments are owned by whoever posted them. WineHQ is not responsible for what they say.

MO2 Status under Wine/Proton/Steam
by Jarrard on Friday November 22nd 2019, 23:02
I would like to direct people to this reddit post about the status of MO2 under Wine. Its 'mostly' working now.

www.reddit.com/r/linux_gaming/comments/d3493y/i_got_mod_organizer_2s_usvfs_running_under_wine/

Some things to note:
- I recommend people use Glorious Eggroll proton releases for Bethesda games as it works best.
- Also NXM linking is still something people will need to configure manually with their xdg-open system.
- To get MO2 working its expected you can follow instructions with some level of intelligence and intuitive thinking ;).... if not just rely on the in-game non script mods in the modshop!
- Modding under Linux often has extra levels of complexities and steps, we (linux users) do not have a AIO tool that combines everything intuitively together yet like how MO2/NMM/Vortex does for windows.
RE: MO2 Status under Wine/Proton/Steam
by Jarrard on Friday November 22nd 2019, 23:06
Forgot to mention, also some helpful tips in here: (xdg system notes also)

www.reddit.com/r/skyrim/comments/8l9bez/guide_sse_on_linux_with_wine/
Mod Organizer 2.2.1 Does Work, But a few things to NOTE.
by Jarrard on Tuesday May 28th 2019, 16:42
So Mod Organizer 2.2.1 does work under wine with a few issues to be aware of.
1) MO2 behaves slowly and will have 1-10s pauses as it initialises internet queries (unknown issue)
2) There is a persistent drag drop text that only can be removed by right clicking somewhere (annoying at the least)
3) The interface is not at all as clean as it is in windows so expect some rather different looks in font and scaling
4) Some of the programs like FNIS needs a VM to work correctly, others like xEdit need small workarounds.
5) The vfs mounting script is a slow workaround and will ad as much as 5 minutes to skyrimse.exe boot time, its not ideal and we need native mo2 vfs or a MUCH faster method. This means testing mods is frustrating due to large amounts of time restarting the game.

Overall mods can be used on skyrimse with mo2 but its frustrating and cumbersome, you will not get a good experience especially if you want to run more then a few mods like large texture and model mods. That's the situation atm, playing these games with mods and MO2 under win10 is still about 100x more enjoyable experience atm. One day we may get there but not today.
RE: Mod Organizer 2.2.1 Does Work, But a few things to NOTE.
by Jarrard on Tuesday May 28th 2019, 16:59
I do not believe MO2 VFS works fully to run script extender atm, however xEDIT will detect and scan the esp files correctly so I dunno. If you get it mounting its vfs for fo4 or sse then let us know.
Alternative
by Patrik Máša on Friday January 11th 2019, 6:15
Since this currently does not work, I have created this (actually, original was very old, but now I have updated it):
github.com/neVERberleRfellerER/FalloutNVLinuxLauncher
It uses OverlayFS for mods. While the initial setup (preparation of directories) takes some time, it needs just OverlayFS and bash (unfourtunately, but I have no idea how to portabilize it while keeping it reliable). It is built to be as simple as possible and as a result should be very reliable.
It is called after new Vegas, but it does not do anything special so it should work perfectly fine with everything that uses the same engine.
MO with Oblivion?
by kandra on Thursday November 22nd 2018, 13:17
Has anyone else tried this with Oblivion GOT disc? I've tried the movfs4l.py fix and get an IOError saying that modlist.txt doesn't exist in my directory DESPITE it being there. Has anyone else tested this with Oblivion and got better results?
Mod Organizer 2.1.3 (almost works)
by Jarrard on Saturday June 23rd 2018, 20:16
It seems with wine3-10 and dxvk0.60 (maybe older) MO2.1.3 almost works, it functions fully and will launch the game, even appears to mount the file system but something goes wrong and the game will stall with 13-15% cpu idle at about 1GB memory usage. Not sure what went wrong.

It's worth noting that if your running the game from NTFS then the lunchtime can be 2-3min due to slow parsing of esp/esm files, this doesn't happen under Windows and could be some specific issue with NTFS (I have not personally tested EXT4 but am told it works faster).

If anyone figures out whats going wrong with mo2.1.3 vfs (note you don't need 2.1.1 work around anymore) then let us know.
RE: Mod Organizer 2.1.3 (almost works)
by Jarrard on Saturday June 23rd 2018, 20:24
PS. For quick testing I recommend just launching FO4Edit within MO2, if the VFS works then the mod esp/esm files will show there.
RE: Mod Organizer 2.1.3 (almost works)
by Christian Widmer on Tuesday June 26th 2018, 17:34
I have just tested Mod Organizer 2.1.3 with wine-3.11 (vanilla with dxvk) and, at first glance, the VFS seems to work for Skyrim SE.
RE: Mod Organizer 2.1.3 (almost works)
by Christian Widmer on Tuesday June 26th 2018, 17:38
Apparently, I was a bit too excited. While the game does start without issues, mods with ESP/ESMs do not appear in the mod list.
RE: Mod Organizer 2.1.3 (almost works)
by Jarrard on Tuesday June 26th 2018, 17:40
Did you do setup for Wine such as installing .net? I have not tested with .net installed yet but even FO4EDIT and wine3.11staging it doesn't mount the files for me, it says it does but xEDIT finds nothing.

Test with xEDIT if you can and see if it mounts the mod files (launch within mo2) and if it does then I guess there must be something else happening at my end.
RE: Mod Organizer 2.1.3 (almost works)
by Christian Widmer on Tuesday June 26th 2018, 18:15
I tried it with SSEEdit and it is just as you expected. As I have already said in my second message, it does not find anything besides the default files. I have just found this[1] line in the console output, though. Should not the usvfs DLL be listed after the colon? This might be a starting point for further investigation.

[1] 01:07:24 [D] USVFS DLL Name:
RE: Mod Organizer 2.1.3 (almost works)
by Jarrard on Tuesday June 26th 2018, 18:21
Yes, I checked my windows10 mo2 logs and it says the below.

[D] USVFS DLL Name: usvfs_x64.dll
RE: Mod Organizer 2.1.3 (almost works)
by Jarrard on Tuesday June 26th 2018, 18:23
I checked my Linux Wine log and it says USVFS DLL Name: usvfs_x64.dll

Make sure your load mechanism is set to Mod Organizer and not script extender.
RE: Mod Organizer 2.1.3 (almost works)
by Christian Widmer on Tuesday June 26th 2018, 18:51
My load mechanism is set to Mod Organizer. I have only seen something there once -- unfortunately, I do not know why -- in many tries. With +loaddll in WINEDEBUG, however, I do see the dll getting loaded, so it does not seem the empty line is actually linked to the issue.
RE: Mod Organizer 2.1.3 (almost works)
by Jarrard on Tuesday June 26th 2018, 18:53
Yes except the usvfs log files are empty which is pretty telling. (they should be FULL of dll overwrite text etc)
RE: Mod Organizer 2.1.3 (almost works)
by Jarrard on Tuesday June 26th 2018, 18:25
Looking further down in the mo_interface.log it does say [D] USVFS DLL Name: ) and not the dll file itself, so perhaps its somehow failing to load the DLL further on past the initial check.
RE: Mod Organizer 2.1.3 (almost works)
by Jarrard on Tuesday June 26th 2018, 18:30
Ok the usvfs-2018-xxxxx.log files generated provide nothing, comparing to windows, it should be full of DLL overwrite log text so clearly the usvfs is failing.

I might install SLIM dotnet and see if that helps since MO2 is meant to have dotnet installed.
Fix for Mod Organizer 2.1.3
by Jarrard on Tuesday May 22nd 2018, 19:15
To get mod organizer v213 working you just need to copy the usvfs files from v211 on top of v213. Resolved ;)

Now if we want we could perfect this script and inject it in as a usvfs replacement, if we wanted to have it in a nice package and all.

The files of v211 you need to keep are:

usvfs_proxy.exe (I don't think this is used)
usvfs_x64.dll
usvfs_x86.dll
RE: Fix for Mod Organizer 2.1.3
by Jarrard on Tuesday May 22nd 2018, 19:22
With MO2 we would need to pull variables to feed into the script obviously, and resolve the python3 dependency.

BUT no need to bother about that until we're confident this script works really well.

Not like I'm doing much, just a tester and ideas man.. A.J. Venter's doing all the real work :)
RE: Fix for Mod Organizer 2.1.3
by A.J. Venter on Wednesday May 23rd 2018, 3:09
Thanks, this worked perfectly, I can also confirm that setting up nxmhanlder into xdg works with this so the "ModManager Download" button is now functional.

I added this to my guide on reddit as well.
RE: Fix for Mod Organizer 2.1.3
by Jarrard on Monday June 25th 2018, 7:05
This is no longer needed with v2.1.3 due to bug fix 45294

However it does not fix the usvfs and will still not correctly mount files (just use fo4edit.exe to test).
I'm sure the original bug reporter will notice this eventually and submit another bug in due time. I would do it myself but I have difficulty knowing what data to submit and such, not very good at it.
Rebuilding v211 for Linux (because it works)
by Jarrard on Monday May 21st 2018, 23:38
I'm looking at the source code for v211 on the nexus git hub (github.com/Modorganizer2/modorganizer/tree/v2.1.1) and I'm strongly thinking we can back peddle from v213 and resolve these problems for Linux users for MO2.

First is fixing the nexus login issue, which could be just a couple line fixes in src/nexusinterface.cpp (602) and src/nxmaccessmanager.cpp (45). This will probably at the very least fix the query system. Then we can compare v212 with v211 and see what really broke things AND/OR fix the remaining login issues, IGNORING usvfs changes.

Once this is done we could directly insert your symlink script into mod organizer as a substitute for the usvfs system, essentially ditching it for a lighter solution that has linux considerations.

Let me know what you think of this idea.

PS. As of yet I do not know exactly howto build this under Linux without using a VM to do so since it relies on visual basic 2015 is seems.
RE: Rebuilding v211 for Linux (because it works)
by A.J. Venter on Tuesday May 22nd 2018, 18:58
It's a good idea but I'm almost certain you won't be able to build it on Linux, you'll have to use a windows VM - even on windows MO is notoriously difficult to compile so I wouldn't add even MORE complexity to it if I were you.
RE: Rebuilding v211 for Linux (because it works)
by Jarrard on Tuesday May 22nd 2018, 19:23
No longer needed, v213 works with my solution posted above. (stupid simple really)
VFS Work-around
by A.J. Venter on Monday May 21st 2018, 7:18
I wrote a small python script to provide a temporary work-around for the broken VFS functionality from ModOrganizer2.
This is not a full solution and does not cover things like per-profile INI files but it does allow using ModOrganizer2 to install mods and set load orders.

To use it do the mod preparation with MO2 but do not start the program with it. In fact you can safely close MO2.
Then run the script below to set up the VFS layer and loadorder and run Skyrim/FallOut as per usual.

Important Notes:
* You need to edit the PATHS map at the top of the script to match your setup.
* WINEPREFIX must be set in the shell where you run this
* The script requires mhddfs to set up the VFS - if you wish to use a different FUSE tool modify the line starting with CMD= to match it's needs.
* I've only done preliminary testing with the script so far.
* I cannot guarantee it will keep working well with large load orders, however issues there are more likely to be on the FUSE layer than in the script.
* I've added preliminary support for multiple profiles but have not yet tested this. It seems to work fine with 'Default' at least.

Once MO2 works fully under wine I highly recommend using that instead of this work-around, it will have more functionality and not be reliant on 'I'll fix an issue if I come across it'. If you do find and fix an issue, feel free to send me pull requests though.

URL: github.com/ajventer/ksp_stuff/blob/master/movfs4l.py
RE: VFS Work-around
by A.J. Venter on Monday May 21st 2018, 10:30
I have updated the script with a new version which uses symlinking rather than FUSE which solves the problem that FUSE will not merge "Textures" with "TEXTURES" and "textures". It is also much better performance wise and seems to be working well.
RE: VFS Work-around
by Jarrard on Monday May 21st 2018, 10:33
Cheers, going to give it a shot. But again how do you determine file priority in the data directory? is mod order preserved.
RE: VFS Work-around
by A.J. Venter on Monday May 21st 2018, 10:36
As I said- I actually read the configuration stored by MO2 when you set it up.

So yes, Modorder is, indeed, preserved.

As far as I know the script should work as-is for Fallout4 as well (with the right base paths obviously) but I haven't tried that.
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 18:54
New version uploaded. Changes:

- Links that override pre-existing files will now back up the file and create the link correctly. The backup is restored when running with UNVFS parameter.
- Support for out-of-mo-tree paths, using seperate mods and profiles keys.
- Complete fix for case sensitivity (see below)
- Directories created now store each step of the path individually and remove bottom-up - so it should no longer leave empty parent directories behind.

IMPORTANT: Please restore a PRISTINE data directory before using the new version.

I finally concluded the only clean way to fix case sensitivity is to lowercase everything. The script will now do that inside the data directory at startup. However it cannot fix pre-existing duplicates. So if there is already a Meshes and a meshes then it won't get the right results so it's important to restore a pristine data directory before using the new version. All destination paths are also lowercased when linked.
It remains advisable to run UNVFS before running MO, and then rerun the script after making changes inside MO.

This should be a much more stable version but please keep in mind this is STILL experimental. There may yet be bugs I haven't caught in my basic testing.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 18:56
Yes I just posted the lower case solution idea below, I didn't see this post.

I will give this a spin, sounds good.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 18:58
To fix pre-existing duplicates I suggest adding the lower-case function of your script in a way that can be called without doing anything else such as script.py -FIXCASE
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 19:02
Nope, it won't work.

The OS won't let you rename something to a name that already exists. It would need to be significantly smarter, detecting if the destination exists already and in that case, moving the CONTENTS across and then removing the folder... it would get very hairy.

This is why I always keep a backup of my game data dir before messing with mods - doubly so when using an experimental automated tool for installing things :P

As I said, the rename already happens automatically on every run - even on UNVFS - but that won't fix the problem of "I can't rename Meshes to meshes because meshes is already there".
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 19:06
Ok I get what you mean,

In such case where your trying to lower case a folder and its lower case version already exists, you could instead just move the contents of said folder recursively to the lower case folder. THEN you might get a situation where a file already exists, in that situation you can keep the newest one and rename the OLDER file with UNVFS in-front for backup purposes, then log that.

Hows that for a work around?

I think NMM does something similar but moves overwrite files elsewhere or something, but that isn't needed if we just insert UNVFS in front.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 19:10
All this would need to be done before applying the mods folder over, since its contents take priority.

Really keeping the older or newer version of a file is not very good because there is no way to know what mod might want which file, its just a blind guess to resolve any precursor conflicts since the script can't know the priority of pre-existing files. It's the best you could do however, MO2/NMM can do no better in such a situation.
RE: VFS Work-around
by A.J. Venter on Wednesday May 23rd 2018, 2:44
But the moment you do that, you now have new issues. If you just MOVE the contents - then they aren't being renamed.
If you want to rename them as well - you need another recursion call inside what is already a recursive function - so the complications get bigger and bigger.

This scenario should only exist if somebody had used an older version of the script - which is only 2 days old so that's a very small number of people.

I think just saying "work from an initially pristine data directory" is a simpler solution in the end - so few people are affected that the extra complication (and likelihood of bugs) isn't worth it in my view.

Even if you used the in-game mod tools before running the script it wouldn't be an issue - as long as THOSE were run on an pristine system, they'd have used the existing paths with their normal capitalisation and so would cleanly rename.
RE: VFS Work-around
by Jarrard on Friday May 25th 2018, 17:39
Just thinking of how MO does it, sometimes you want to overwrite files such as the DLC esm with fixed versions (cleaned).

I have seen normal symlinks overwrite files and folders in the past such as DXVK when it overrides dlls dxgi etc.. 'setup_dxvk.sh'

I can't really follow the code to determine what its really doing so I could be wrong.
RE: VFS Work-around
by A.J. Venter on Saturday May 26th 2018, 2:37
The current version does in fact overwrite files with links - but it makes backups of the originals so that UNVFS can restore them.
RE: VFS Work-around
by Jarrard on Monday May 21st 2018, 10:32
I eagerly wait the update to this.

How are you determining data file load order and overwrites from MO2? is there a XML file with that info somewhere that is written?
RE: VFS Work-around
by A.J. Venter on Monday May 21st 2018, 10:34
Update was just pushed, it's the current version on the same link.

It's even simpler. MO2 just has a text file with the mod directories listed in order and a one-character symbol indicating if it's enabled/disabled/unmanaged.
I ignore everything except 'enabled' and just do some clever file traversals from there.
RE: VFS Work-around
by Jarrard on Monday May 21st 2018, 10:39
Whats the name of this text file?
I think I have found it before but for some reason I can't now.
RE: VFS Work-around
by A.J. Venter on Monday May 21st 2018, 10:43
There are two important ones.
Modlist.txt contains the mod directory order.
Plugins.txt contains the ESP list and load order for the game.

Both exist in the profile directory.
I symlink plugins.txt directly to the game.
I parse modlist.txt to handle the mod data.

You may want to read through the script source and get a feel for what it does.
RE: VFS Work-around
by Jarrard on Monday May 21st 2018, 10:46
Ok I think my pee sized brain is starting to understand it now. It only needs to worry about symlinking the core mod folder of each mod and not individually catalog each physical file of every mod because MO2 basically does that in the physical sense in app?

Have I got that right? I was looking for some big text file with every file with full paths and ordering.
RE: VFS Work-around
by A.J. Venter on Monday May 21st 2018, 10:52
It's a little more complicated than that, but the core concept is that MO2 installs each mod in it's own folder then uses an overlaying filesystem to place them over the Data folder in order.

My symlinking code recursively goes into each mod directory in order and links the entire file structure to an identical one inside your data folder, this is done in a "new links override old links" fashion so if a mod later in the order overwrites a file from a mod earlier in the order it's the correct file that the game eventually sees.
RE: VFS Work-around
by Jarrard on Monday May 21st 2018, 10:54
Hopefully there won't be any case sensitive issues cropping up since mod authors love randomly putting in capitals for their folder and filenames at will :-)
RE: VFS Work-around
by A.J. Venter on Monday May 21st 2018, 10:56
My script contains code to fix that on the folder level. But there could potentially be an issue if two files only differ by case, both will show up in game. Fixing that will be rather more difficult.
RE: VFS Work-around
by Jarrard on Monday May 21st 2018, 10:59
Maybe make a separate script to lowercase the data directory. I have actually done that before with OLDrim, but that was a long time ago and I don't remember the code.
RE: VFS Work-around
by Jarrard on Monday May 21st 2018, 10:54
I'll give feedback tomorrow sometime, WAY past my bed time. This looks awesome non the less :)
RE: VFS Work-around
by A.J. Venter on Monday May 21st 2018, 11:01
I reckon I have an idea how to do files as well. I'll update the script later tonight with that added.
RE: VFS Work-around
by A.J. Venter on Monday May 21st 2018, 11:12
Done.
Fairly simple approach: the first file capitalisation that gets created is kept.
If a later mod has a file with the same path and the same name but only capitalisation differs - it will replace the link using the name from the previous mod.

So this way if you have mods that contain:
Textures/aa.png
Textures/Aa.png
textures/AA.png

Ultimately AA.png will be in your Textures folder, but it will be called aa.png, and there will be a symlink from Textures to textures.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 7:25
Small oversight on the script,

You assume people will save their profiles folder in the mo2 directory.

People will just need to be aware of that and copy it over there. (I keep mine on the mod download drive as to not loose settings).
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 7:29
Heh, I always use stand-alone MO2 setups in the "Portable" type - I didn't even realize it was possible to put the profile elsewhere.

Honestly I'm not sure how to even change that, I really don't want to hard-code the profile path (I like that currently you can just give a profile name on the commandline to use a different one).

I'd have to do a setup with a different profile path and then go study how it looks to figure out how to support that method.

Personally I always keep it in-folder because all my MO's are specific to ONE GAME ONLY - generally contained in a winebottle-per-game layout. That way nothing I do with MO in one game can affect my usage of it in another game.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 7:35
From what I can tell, you script assumes everything is within the MO2 folder? and that there is no game paths present inside MO2 folder.
This is not really how MO2 is meant to be used.
If you play 1 game that is fine, 2 games, and big issues occur such as profile files overwriting each other.

An example structure is as followed, I'll use fallout4 and skyrimse as examples.

/DriveA/MO2/Fallout 4/profiles/Default/
/DriveA/MO2/SkyrimSE/profiles/Default/
/DriveB/MO2/Fallout 4/mods
/DriveB/MO2/SkyrimSE/mods

Essentially you need to be able to define where the profile is and where the installed mod folders are, and they need syntax to be able to separate games/locations.
"mo": '{PREFIX}/drive_c/MO' is not sufficient to derive all of the above info from because the profiles and mods folders could literally be anywhere.

OR am I completely missing something here?
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 7:41
MO2 has two main ways of being used - as demonstrated in the dialog that pops up when you add a game to it.
You can choose between "set up a game folder" and "portable mode".

I always use portable mode since all my games are in their own, unique, wine bottles and only ever have one game.
This is the RECCOMENDED way to game on wine btw.

But with the information you provided - I can add some keys to allow it to work, basically by adding some more configs to the PATHS map - one for the mod directory, and one for the profiles directory.

Then just change the code in the main section to use those values correctly.

I'll do this for the next version - but that will only be possible tomorrow.

But if you feel up to making the change:
Change the current 'mo' key in the paths map to: 'profiles'
Add a key 'mods' with the path to your mods.

Then in the main section change the code that sets up PDIR and MODS to use these new keys.

If you do that, test it, and send me a pull request I'll merge it.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 7:45
Recommended way to have bottles for each game, even thought MANY games share identical settings and configuration?
It may be recommended but its FAR from practical or necessary. I do have multiple prefixes but only move things between them if needed.

Anyway and simple way to define profiles and mods path would help allot.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 7:41
I would suggest defining 'profiles' and 'mods' since both are often not located in the MO folder itself.

Its not uncommon for users to keep their mo application folder separated from their game mod and configuration files. What happens if you delete MO directory? there goes hours/days of mod installation and custom fixes etc... :)
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 7:43
I, on the other hand, like being able to back up that one folder and keep EVERYTHING safe.

I can't imagine why I'd ever delete the MO directory.
Even when upgrading I just rename it, install the new one, then move those two folders over to it.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 7:51
I have operating system drives, and storage drives, mods and content that does not need fast read speed goes on my storage drive and I never need to worry about making backups if my OS drive fails. (or I forget)
I have the mods folder installed on a dedicated NVMe drive for games, for maximum speed. Normally I would put MO2 on this drive along with profiles, but never the downloads.
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 7:53
Yeah... I can't afford that many drives.

I got one big drive with one OS partition, one swap partition and one data partition.

Another equally massive drive makes a nightly clone of everything on the first one, so I'm safe except the ultra rare scenario where both fails at once.

That's about the most feasible home-affordable solution within my budget.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 8:08
I had everything on one BIG 3TB drive once. Then it failed, I learnt my lesson.
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 8:12
That's why I have TWO 4TB Sata drives, every night a cronjob runs that rsync's the one I'm actually using to the second one.

Other than that- it's never used at all (except if I am restoring something from that backup).

So unless both fails at the same time - which is highly unlikely since the backup drive is so rarely being accessed - I'm golden now.
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 7:46
I wrote this guide today, which gives a fair idea of how I approach my gaming:

www.reddit.com/r/skyrim/comments/8l9bez/guide_sse_on_linux_with_wine/

Just to expand (on what's not in there) my WineBottles directory also contains a Skyrim folder - with a similar layout and utility scripting for skyrim classic, a falloutNV folder- same and several more.

Every game contained in it's own little univerise, with it's own wine build/version that works for it, it's own configs and libraries and modifications. And all can be (and are) backed up by just ensuring that one folder is backed up.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 7:57
A blank wine prefix with nothing installed takes up 500MB, a kitted out prefix takes up 2-3GB. After several games your looking at a storage crisis. I can't afford $1000 on a 2TB SSD just to cater for such practices :)
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 8:02
I use 4TB data. Drive.

SSDs are out of my price range.

It's still best practice with wine to use individual prefixes. That way you never issues because one game only works with one library override and another only with a different one.

I don't even share wine builds between multiple games unless I've absolutely ensured they have identical needs. Too many games only work with a specific wine version, some require staging, some won't run under staging.

I prefer to avoid such issues. It is also largely the way PoL works by default.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 8:07
May I introduce you to your lord and savior, his name is Lutris :)

Anyway spinning rust and UHD 4K Bethesda games don't mix from my experiences.
I can't tolerate disk access stutters a single bit so that is why I segregate my stuff like I do.

If I was rich I'd buy 4TB NVMe SSDs and laugh. But I was only able to get a 500GB one so I must balance things.
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 8:10
I tried Lutris before... I didn't much like the way it worked.

But to each their own, my way as I do things now works very nicely for me, it keeps things neat and self-contained and I am very happy with the results.

I only play 1K since I don't have a 4K screen and the money to buy one anyway - and I've never found load issues to be a major concern - in SSE load times are virtually non-existent, even when the game is seriously heavily modded.

But to each their own - your method works for you, mine works for me. If we wanted to do everything the same as everybody else - we would use windows :P
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 8:24
1k is absolutely fine for spinning rust. Move to 4k and UHD and you will gouge your eyes out :)
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 8:28
Well, hopefully when the time comes that I can afford a 4K screen and a new graphics card that's worth it (I use the top-end 1K card the Nvidia 1050ti right now) I'll also be able to afford an ssd drive.

At that point I'll probably move my games over to that.

But I'm still likely to stick to per-game bottles, even if it means I can only keep the game I am playing right now on SSD and have ot swap them out when I start a new one.

I tend to pretty much play one game for months one end, then start playing another for months on end again. So doing that every 3 to 6 months won't be too much of a hardship (and I won't have to rebuild all my working setups).
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 8:08
Another advantage is this.

Say I want to recreate my skyrimSE prefix for some reason (botched winetricks command or something):

mv prefix/drive_c/Steam .
mv prefix/drive_c/MO .
rm -fr prefix
mkdir prefix
WINEPREFIX="`pwd`/prefix" winecfg
mv Steam prefix/drive_c
mv MO prefix/drive_c

Done- the whole process takes less than a minute.

If there is a dozen games in there on the other hand - it would be a nightmare to get them all safely out of the way so I can destroy and recreate it.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 8:15
That is fast and easy, but is it safe long term? My experience says no.

My OS drive is just a normal 550MB/s while my games drive is 3200MB/s, its not easy managing things but the performance makes it worth it.

If you game at 1080p then you are probably unable to understand the amount of data access that 4k and UHD textures demand, its scary!

Anyway to resolve the problem, I can symlink to MO folder, then things get symlinked in a nice ugly circle :)
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 8:17
Heh - or you can make the changes I described in the other comment.

They are quite simple changes (just three lines need ot be changed).

I just cannot do it until tomorrow due to work and parenting obligations.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 8:22
Sorry sometimes I miss some of your comments because WineHQ has a REVOLTING comment system!
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 11:51
Ok,what your image shows shouldn't happen. I'll have to come up with a different approach then.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 8:21
Right now I have

PATHS={
"mo": '{PREFIX}/drive_c/Mod Organizer 2',
"fallout4": '/mnt/GamesSSD/SteamLibrary/steamapps/common/Fallout 4/',
"plugins.txt": '{PREFIX}/drive_c/users/theriddick/Local Settings/Application Data/Fallout4/Plugins.txt'
}

But my profiles and mods folder are located 2 separate drive, symlinking profiles over is not a issue, but the mods folder will likely cause a issue.
(which going by script you assume is in the mo2 folder, even thought MO2 allows for individual defined paths)

PS. I know I repeat myself, I just want to make absolutely sure the problem is well defined. :)
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 8:23
The mo entry can be entirely removed.

Instead create an entry for 'profiles' and one for 'mods' with the paths specified.

Then just change the lines that set PDIR (profile directory) to use the new 'profiles' key instead and lower down change the line that sets MODS to use the new 'mods' key.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 8:26
Yep will do, cheers.

Looks great non the less, very easy to modify.
I just felt making it by default to allow for profiles and mods path definitions might help others down the track.
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 8:29
I agree, and the advantage of those changes is that they are still compatible with portable MO setups like mine, so that way both approaches will work fine.

Hence if you do it, and confirmed it's working, please do send a pull request and I'll merge it into github so everybody can get the update.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 9:12
Two issues have cropped up.

1) How do you uninstall the symlinks, in particular if something goes wrong (2)
2) It seems if there is a preexisting file in the game data folder or its plugins.txt user... folder, the script will quit with a FileExistsError.

If a uninstall method has not been devised then I propose making a --uninstall argument or something that will search the plugins.txt and game data folder for any symlinks and remove them. There is likely a easier way but I'm not very familiar with fuse and its functions.

And secondly if a file already exists, can we not just symlink over-top of it, this seems to work with the dxvk install scripts when you already have dxgi.dll in your windows directory?
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 9:14
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 9:18
There is already an uninstall method. Call it with UNVFS as parameter.

I'll fix the profile bug.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 9:23
nevermind, it was simple.

while inside the fo4 data folder I did the following.

ls -la * # to list all symlinks files/folders
find -type l -delete # and to delete them

Also I discovered a problem, a unforeseen issue. If you install mods via the bethesda ingame mod library, it will make a mess and not obey case sensitivity.
This screws up your script somehow, probably because it finds dupe script/texture and everything else folders.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 9:29
find -type l -delete appears to not delete the folders left behind, interesting issue.
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 10:19
There are two kinds of folders it encounters. If a folder doesn't exist at all, it creates it. If a folder exists with different capitalization it creates a symlink to it. This should not cause issues since the two folders are really the same thing, writing to either the outcome is the same. Only one file will be created.

I don't use the mod store but it's possible it has an issue because it sees the links as dupes. I can't really see an easy answer,. I need to make file paths work even if a folder somewhere inside has different capitalization. Your approach will require very difficult code.

Best solution may be to have the script forceably lowercase everything on startup, and force lower case everything it produces as well. I'll look into that for the next version.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 9:26
Your script might not be obeying case sensitivity itself. More testing required (finding dupe folders inside the core ones).
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 9:30
I'm not finding that. Wonder what triggers it. The script has a safe uninstall method already. Use it. UNVFS
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 9:38
Yes I see, just gotta change Mo_Profile to UNVFS. Should probably move that definition to top, and explain what UNVFS is also.

Anyway like I said if you use ingame mod store, its going to create big problems. So is it possible the script can be made to check if a file/folder exists beforehand, and then just write ontop of it with same case sensitivity as to avoid duplicates? (preserving any files within a folder of cause).
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 9:40
Here is a good example of what will happen:

In this example the script has found that I have a mod that overwrites the default bethesda MainMenuLoop.bk2 file that already exists, and has chucked a tantrum.

Traceback (most recent call last):
File "./MO2vfs4l.py", line 112, in
addvfslayer(DATADIR,modpath, log)
File "./MO2vfs4l.py", line 87, in addvfslayer
updatelink(src, dest)
File "./MO2vfs4l.py", line 34, in updatelink
os.symlink(src, dest)
FileExistsError: [Errno 17] File exists: '/mnt/GamesSSD/Games/MO2/FO4/mods/GUI -- Main Menu Magnolia/Video/MainMenuLoop.bk2' -> '/mnt/GamesSSD/SteamLibrary/steamapps/common/Fallout 4/Data/Video/MainMenuLoop.bk2'
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 9:43
And I'm seeing Textures, textures, Meshes, meshes, Materials, materials. The script is definitely not applying these links with a uniform case sensitivity!
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 9:48
This is what I have modified so far, its setup to uninstall the links. Hopefully I've just done something obviously wrong.

pastebin.com/6iyHxkxT
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 9:54
PS. Forgot to mention, UNVFS did nothing when MO_PROFILE='UNVFS'
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 10:22
You don't change the variable. Just call with it as parameter.

./movfs4l.py UNVFS
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 10:24
Ok that resolves that.
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 10:25
That will remove created folders as well.

I'll come up with a fix for overwrites of Bethesda files. I never considered that.
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 10:23
Those are not duplicates. They are symlinks, all those meshes folders are the same folder.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 10:29
Yes ok not duplicates, but the game is not going to like seeing Meshes with some files in it, and another 'meshes' folder with some OTHER files in it?¿
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 10:30
It won't. meshes, Meshes and MeshEs will all have identical files in them, not copies, the same files. That's how folder links work.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 10:45
Oh ok, that isn't so bad then. However it could confuse files added by the ingame mod installer since those files will PICK a specific folder to go into, there is no guarantee the game will choose the correct one at that point since they will no longer be the same (bethesda will not install the files into all the folders, just one).

Maybe its not a issue?

The other problem left is preexisting files cause a symlink overwrite error. Gotta figure that out.
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 10:49
Should not be an issue. It can write into any of the folders (it will use the game default) and the file will show in all of them.

The overwrite issue is tricky. The current code won't remove an existing file unless it's a link, don't want to risk breaking the game.

The solution probably if the target exists and is not a link is to rename the target and add it to the log, then when UNVFS runs automatically restore the backed up version.

Tomorrow night I'll be free to work on the code, I'll implement that as a fix then.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 10:58
Cool, sounds good.

I was thinking however, for files that already exist, what if you rename the file with UNVFS. and just have the script check for any files with that at the front, and remove it upon uninstall?

I don't think that would be overly risky, you could even write a unvfs log file noting this just in case something happens.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 10:59
Perhaps we could also add a function to TEST/FAKE install the symlinks beforehand?
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 11:12
Just going to leave this image here, notice the problem. The game does not like this, mine zombies after intro vid and takes quite a while to load up.

Folders don't look identical, seems its cherry picking case...

dumpt.com/img/viewer.php?file=6e8hkfbmzkpyd0ms95uc.png
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 11:15
Also might need to make the script so it removes empty folders of where symlinks were after the UNMOUNT/UNVFS process. It leaves all the empty folders behind, which seems ok but does confuse things.
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 12:17
Folders created should be removed already.

What is likely happening is that parent folders aren't recorded and so they stay behind. I'll look into fixing that as well.
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 18:50
While not the most elegant solution you could simple lower-case the entire mods folder and the game data folder before doing the symlink process. It would resolve the issue for sure. I have done it in the past.

Any new mods installed from other sources such as in-game store or steam will ruin this so adding this as a separate function of the script would be useful such as x.py -FIXCASE which checks mods & data folder and nothing more. (but still do this automatically when creating symlinks).
RE: VFS Work-around
by Jarrard on Tuesday May 22nd 2018, 18:54
Since I never come up with anything original, I found a old example of lower casing a folder recursively.

But you probably know howto do this already just in your head. :-/

e.g.
stackoverflow.com/questions/152514/how-to-rename-all-folders-and-files-to-lowercase-on-linux
RE: VFS Work-around
by A.J. Venter on Tuesday May 22nd 2018, 18:57
That's exactly the solution I went with, but please see the caveat in my post above.

The problem with new mods shouldn't be an issue because the script does it on every startup, so simply re-running it will sort them out.

It's such a quick process that it's worth just keeping it in there and making sure that after every run things are as they should be.
RE: VFS Work-around (bug)
by Jarrard on Tuesday May 22nd 2018, 19:42
There is a slight bug where you maybe forgot to account for the UNVFS renaming of a file when restoring it back to its original name.

It's trying to rename mainmenuloop.bk2 back to mainmenuloop.bk2, it should be mainmenuloop.bk2.unvfs back to mainmenuloop.bk2

Traceback (most recent call last):
File "/usr/lib/python3.6/shutil.py", line 544, in move
os.rename(src, real_dst)
FileNotFoundError: [Errno 2] No such file or directory: '/mnt/GamesSSD/SteamLibrary/steamapps/common/Fallout 4/Data/video/mainmenuloop.bk2' -> '/mnt/GamesSSD/SteamLibrary/steamapps/common/Fallout 4/Data/video/mainmenuloop.bk2'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
File "./MO2vfs4l.py", line 108, in
unvfs(DATADIR)
File "./MO2vfs4l.py", line 68, in unvfs
shutil.move(b,b.replace('.UNVFS',''))
File "/usr/lib/python3.6/shutil.py", line 558, in move
copy_function(src, real_dst)
File "/usr/lib/python3.6/shutil.py", line 257, in copy2
copyfile(src, dst, follow_symlinks=follow_symlinks)
File "/usr/lib/python3.6/shutil.py", line 120, in copyfile
with open(src, 'rb') as fsrc:
FileNotFoundError: [Errno 2] No such file or directory: '/mnt/GamesSSD/SteamLibrary/steamapps/common/Fallout 4/Data/video/mainmenuloop.bk2'
RE: VFS Work-around (bug)
by Jarrard on Tuesday May 22nd 2018, 20:09
Here is another bug for you. Pretty obvious what the script is doing. Basically I'm putting UNMOUNT after the script to remove links, which it does, but somehow it inserts that into the path for plugins.txt.

Setting symlink from "/mnt/StorageDrive/Games/ModOrganizer2/Fallout 4/profiles/UNMOUNT/plugins.txt" to "/home/theriddick/.wine64x1/drive_c/users/theriddick/Local Settings/Application Data/Fallout4/Plugins.txt" for loadorder
Linking "/mnt/StorageDrive/Games/ModOrganizer2/Fallout 4/profiles/UNMOUNT/plugins.txt" to "/home/theriddick/.wine64x1/drive_c/users/theriddick/Local Settings/Application Data/Fallout4/Plugins.txt"
Parsing MO mods configuration
Traceback (most recent call last):
File "./MO2vfs4l.py", line 119, in
for modpath in [os.path.join(MODS,i[1:]).strip() for i in open(os.path.join(PDIR,'modlist.txt')).readlines() if i.startswith('+')]:
FileNotFoundError: [Errno 2] No such file or directory: '/mnt/StorageDrive/Games/ModOrganizer2/Fallout 4/profiles/UNMOUNT/modlist.txt'
RE: VFS Work-around (bug)
by A.J. Venter on Wednesday May 23rd 2018, 0:57
This one is human error.
The remove links parameter is UNVFS not UNMOUNT.

Any parameter except UNVFS is assumed to overwrite the profile, so if you have multiple profiles and don't want to use Default at the moment you can just give the profile name on the command line.
RE: VFS Work-around (bug)
by Jarrard on Wednesday May 23rd 2018, 2:55
Ok, I just used the end of script message as a guide which says,
"VFS layer created. Rerun this script to update. Run "%s UNMOUNT" to shut it down"

Shut it down could be interrupted as uninstalling it.
RE: VFS Work-around (bug)
by Jarrard on Wednesday May 23rd 2018, 2:57
I'll just change it so it says,

'VFS layer created. Rerun this script to update. Run "%s UNMOUNT" to shut it down or UNVFS to remove VFS'

Still not sure what unmount is meant to do in all honesty.
RE: VFS Work-around (bug)
by A.J. Venter on Wednesday May 23rd 2018, 3:02
There is no UNMOUNT option.

There used to be, back in the first version which used a FUSE base filesystem overlay. I changed it to UNVFS when I did the link based rewrite to be more properly descriptive.

I just forgot to update the message at the end. I'll do that now.
RE: VFS Work-around (bug)
by A.J. Venter on Wednesday May 23rd 2018, 1:02
Thanks,

I just pushed an update that fixes this one.
RE: VFS Work-around (bug)
by Jarrard on Wednesday May 23rd 2018, 3:07
Cheers,

Also I take it you read the info about MO2 v2.1.3 working now with a small file swap correct? I tested it and NXM login and queries work
(have not tested linking yet because I have not made the changes for that on this system)
RE: VFS Work-around
by Jarrard on Saturday May 26th 2018, 7:21
Are you still using mhddfs with this script? someone suggested it wasn't using FUSE at all.
RE: VFS Work-around
by A.J. Venter on Sunday May 27th 2018, 3:12
No, I am not using it anymore, and not using FUSE at all. Trouble with that approach was that FUSE systems like MHDDFS didn't offer any way to deal with case insensitivity and adds an performance overhead. The symlink system that replaced it allowed me to fix both.
Even trying to use mhddfs now I would have to still do the rename-to-small-caps and also do this in every mod folder as well.

That said, you should update your copy. A community member caught a bug in the mod order and sent a pull request which I merged this morning, it will be more stable with that.
RE: VFS Work-around
by Jarrard on Sunday May 27th 2018, 3:56
Ok fair enough, thought the guys over at git modorganzier site seem to think FUSE could handle case. If you have time read the thread in link below.

github.com/Modorganizer2/modorganizer/issues/372

The issue they said that UNVFS can't really ever be used as a replacement because it modifies the host directory (can cause damage), that's the main issue I think.

This is why I was saying if a symlink system can be made to only function while its loaded in memory then it be great, but at present it could be a issue for that use case.

Also what kind of performance issue was FUSE causing?
RE: VFS Work-around
by Jarrard on Sunday May 27th 2018, 4:00
In particular,

www.brain-dump.org/projects/ciopfs/

However its not good if it doesn't work under Windows also. And also no good if performance is badly crippled.
RE: VFS Work-around
by Jarrard on Friday June 8th 2018, 20:49
Do you think this script could be made to work under windows10?

Just doing some performance comparisons and noticed mod organizer usvfs has recently failed under windows10 due to likely a windows update (how ironic is that),.

So wondering if this would work under windows if python was installed? or would the symlink commands fail, I know windows has them but not sure if its applied the same way.
RE: VFS Work-around
by A.J. Venter on Saturday June 9th 2018, 0:43
It probably could yes. According to stackoverflow at least python 3.2 has windows support for the os.symlink function the script uses.
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 3:13
I tried running it was was spat a syntax error related to my paths, I wasn't sure if using the \ or / was needed since Linux uses the forward slash method while windows uses the backslash.

However I suspect it would not work even if I did ignored the wineprefix variable.

What's your thoughts on this all, what would need to be changed do you think for windows compatibility?
Maybe it can be made OS dependant so if your running windows it runs slightly different scripting that works?
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 3:15
actually seems windows will accept either, derp
RE: VFS Work-around
by A.J. Venter on Saturday June 9th 2018, 3:24
The proper way in python is to use os.path.join - which will work on any operating system, or the constant os.PATHSEP which returns the proper path seperator for the platform.

I don't even have a windows install to experiment with, but in theory this should be extremely close to working in windows as I haven't done anything that's particularly platform dependent.

Of course I did use the WINEPREFIX variable but it's fairly easy to just replace the line which sets that (near the top of the file) with a constant - it could even just be 'C:\' depending on your setup.

Having said all that, I have no idea what may break under windows, no capacity to test it and no particular desire to support that. If you want to make a windows version feel free, but I can't really help you much with that. I checked the python docs and it says os.symlink should work under windows - but I have no idea if there are differences in what it expects, how it will behave or the viability of the resulting outputs.

The best I can tell you is that Vortex is using windows native symlinks and it seems to work for them.
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 3:22
Looks like I may have spoke too soon, might be able to get this working :)

Setting symlink from "E:/Games/ModOrganizer2/Fallout 4/profiles\Default\plugins.txt" to "C:/Users/Riddick/AppData/Local/Fallout4/plugins.txt" for loadorder
Linking "E:/Games/ModOrganizer2/Fallout 4/profiles\Default\plugins.txt" to "C:/Users/Riddick/AppData/Local/Fallout4/plugins.txt"
Parsing MO mods configuration
Creating directory D:/SteamLibrary/steamapps/common/Fallout 4\Data\meshes\actors\character\_1stperson\animations\furniture\fusioncore
Traceback (most recent call last):
File "FO4_movfs4l.py", line 120, in
addvfslayer(DATADIR,modpath, log)
File "FO4_movfs4l.py", line 76, in addvfslayer
mktree(p, item.lower(), log)
File "FO4_movfs4l.py", line 49, in mktree
os.mkdir(tree)
FileNotFoundError: [WinError 3] The system cannot find the path specified: 'D:/SteamLibrary/steamapps/common/Fallout 4\\Data\\meshes\\actors\\character\\_1stperson\\animations\\furniture\\fusioncore'
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 3:26
"plugins.txt": 'C:/Users/Riddick/AppData/Local/Fallout4/plugins.txt'

That needs the forward slash but the others seem ok?

Still gotta deal with the below.

Traceback (most recent call last):
File "FO4_movfs4l.py", line 120, in
addvfslayer(DATADIR,modpath, log)
File "FO4_movfs4l.py", line 76, in addvfslayer
mktree(p, item.lower(), log)
File "FO4_movfs4l.py", line 49, in mktree
os.mkdir(tree)
RE: VFS Work-around
by A.J. Venter on Saturday June 9th 2018, 3:31
While windows may accept both, I'm pretty sure mixing them is a bad idea :P

I remember I had to deviate from the pure pythonic os.path.join approach because it produced a broken output at one point - you may just want to find the '/'.join line and replace it with a '\'.join instead.

That may fix your issues with the directory creation.

I had to create my own recursive directory creation function even though python includes some because the python ones give me no way of recording every step in the process - and if I don't log every change made, then UNVFS can't reliably UNDO everything we did.

That was actually in the mktree function if I recall correctly.

BTW. - I'm actually playing FO4 now, under wine, using this script to mod - and it's working fine. I did find though that for FO4 it's better to use wine's own dx11 rather than dxvk - dxvk gave me weird artifacts and I couldn't get the game to work in full-screen mode (or in fact anything but windowed borderless) and then the mouse woudl keep escaping.
Using wine native I could run it full-screen, use a wine-desktop to force it to the right monitor and use mousejail to fix the mouse-leaving-the-game issue.
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 3:37
If you can help me make the adjustments to this script via me giving you the errors and such then I think we can get this working on Windows, I'll try the adjustments you said above.

As for DXVK, you need to have latest, and probably patches from wine glorius eggroll plus f4se patches (search for wine ge git and f4se wine-hackery git for the patches)

I use wine 3.9 staging without issue. But like I said I need this to work in windows also to do baseline performance testing for dxvk, and mo2 vfs is broken atm. (I'll blame MS)
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 3:52
I should mention here that if you have a NVIDIA card then remove the GALLIUM 9 patches from the PKGBUILD. Their for MESA drivers.
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 3:43
The area where it should mk directory is:

def mktree(root, path, log):
tree = root
for p in path.split('/'):
tree = os.path.join(tree,p)
if not os.path.isdir(tree):
log['dirs'].insert(0,tree)
print ('Creating directory ',tree)
os.mkdir(tree)

Changing '/' to a '\' actually causes a syntax error.

Also for the mouse escaping the wine window, setup a virtual wine window to the resolution of your screen you play on, and tick the capture mouse option. This will fix that, but you will get another nasty bug where the taskbar renders on top (maybe) there is a patch for that but the registry key resets after 10 uses or so (weird).
RE: VFS Work-around
by A.J. Venter on Saturday June 9th 2018, 3:59
The capture option didn't work for me, even with a wine desktop - which I'm using anyway, I still needed mousejail for it to work. This could be a window manager difference (I'm using cinnamon on Ubuntu).

Anyway, it's working just fine for me, getting a consistent 60FPS despite serious graphics and texture mods - so I'm not going to mess with it, I don't see DXVK giving me anything of value here (I can't get skyrimSE to run without it on the other hand - so there it's used).

Another advantage of my "each game in it's own bottle" approach is that it's easy to select the best graphics layer for the specific game I want to play.

As for that problem - the issue here is that if you leave it hardcoded on forward-slash and you have MIXED slashes then you will end up with the path not being split properly - which is a major problem.

So you can try changing that path.split('/') to: os.path.split() instead.

It broke for me on Linux - probably because of mixed windows/linux path elements, but on a pure windows setup it might work and fix the script for you.
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 4:07
Traceback (most recent call last):
File "FO4_movfs4l.py", line 119, in
addvfslayer(DATADIR,modpath, log)
File "FO4_movfs4l.py", line 75, in addvfslayer
mktree(p, item.lower(), log)
File "FO4_movfs4l.py", line 43, in mktree
for p in os.path.split():
TypeError: split() missing 1 required positional argument: 'p'

Seems it needs something in the brackets.

As for DXVK, it gives me better fps in all titles, I run at 4k so it's extremely noticeable. Max fps is important in bethesda titles due to the horrid optimizations done, for example going to a place in FO4 like BUNKER HILL will likely eat 30fps or so (at least for me) so if your only just sitting on 50-60fps as average then that can be a huge issue because once you go there you'll be playing at 30fps. So with Bethesda titles the best fps to get is around 80-100 fps in high fps areas, however you will of cause cap this due to the physics glitching that can happen above 60fps.

In FO4 at present at 4k I can see FPS dips to about 35fps which is annoying because it happens due to terrible optimization done by Bethesda, I hope to get this FPS up as DXVK matures.
RE: VFS Work-around
by A.J. Venter on Saturday June 9th 2018, 4:10
os.path.split(path)

Dunno if it will work - but it's worth a try.

You should look at the texture optimization mods on nexus. I'm not using them since I am getting a solid 60FPS with high res textures (except not the high-res DLC - which everything I read says is terrible, as it was on Skyrim actually).
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 4:20
The FO4 UHD pack is good if you have 8GB+ VRAM however you will only see the real difference at 1440p or above resolutions.
It does make a difference but he problem people have is that textures look the same but just higher fidelity, people expect it to change the texture look, it only increases the pixel density which a blunt eye won't notice! :)


Seem to get the same error now.

Traceback (most recent call last):
File "FO4_movfs4l.py", line 119, in
addvfslayer(DATADIR,modpath, log)
File "FO4_movfs4l.py", line 75, in addvfslayer
mktree(p, item.lower(), log)
File "FO4_movfs4l.py", line 48, in mktree
os.mkdir(tree)
FileNotFoundError: [WinError 3] The system cannot find the path specified: 'D:\\SteamLibrary\\steamapps\\common\\Fallout 4\\Data\\meshes\\actors\\character\\_1stperson\\animations\\furniture'
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 4:23
Is the issue not with os.mkdir(tree)?

Script:
def mktree(root, path, log):
tree = root
for p in os.path.split(path):
tree = os.path.join(tree,p)
if not os.path.isdir(tree):
log['dirs'].insert(0,tree)
print ('Creating directory ',tree)
os.mkdir(tree)

Full command and error output (cmd console admin mode)

D:\Games>python FO4_movfs4l.py
Setting symlink from "E:\Games\ModOrganizer2\Fallout 4\profiles\Default\plugins.txt" to "C:/Users/Riddick/AppData/Local/Fallout4/plugins.txt" for loadorder
Linking "E:\Games\ModOrganizer2\Fallout 4\profiles\Default\plugins.txt" to "C:/Users/Riddick/AppData/Local/Fallout4/plugins.txt"
Parsing MO mods configuration
Creating directory D:\SteamLibrary\steamapps\common\Fallout 4\Data\meshes\actors\character\_1stperson\animations\furniture
Traceback (most recent call last):
File "FO4_movfs4l.py", line 119, in
addvfslayer(DATADIR,modpath, log)
File "FO4_movfs4l.py", line 75, in addvfslayer
mktree(p, item.lower(), log)
File "FO4_movfs4l.py", line 48, in mktree
os.mkdir(tree)
FileNotFoundError: [WinError 3] The system cannot find the path specified: 'D:\\SteamLibrary\\steamapps\\common\\Fallout 4\\Data\\meshes\\actors\\character\\_1stperson\\animations\\furniture'
RE: VFS Work-around
by A.J. Venter on Saturday June 9th 2018, 4:28
It is, but the question is what is causing it to break.

I'm guessing it's the double-slashes that are getting introduced - without REAL testdata (i.e. being able to run it on windows myself) I can only take an educated guess where that's happening.
But maybe the easier answer is to just get rid of them.

Try replacing the line: tree = os.path.join(tree,p)
With:
tree = os.path.join(tree,p).replace('\\','\)

I think that may help.

I always stick a lot of print statements in when debugging, so the output shows me each step of the data manipulation - it helps to figure out where things are going wrong if you can see the point where the way the variable changes isn't the way you want it to change. You may want to try that if you're still stuck.
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 4:39
Sure, syntax error it seems

D:\Games>python FO4_movfs4l.py
File "FO4_movfs4l.py", line 44
tree = os.path.join(tree,p).replace('\\','\)
^ (this is pointing to the last character)
SyntaxError: EOL while scanning string literal

I updated windows10, mo2 vfs fails again, seems they have make the uvfs compatible with a specific version of windows10 only... how nice.... (punches wall)

Also you can install a virtualbox windows VM very easily for testing (I have one) but I understand you don't want to devote such time to the problem like that.
RE: VFS Work-around
by A.J. Venter on Saturday June 9th 2018, 4:40
Sorry, typo.
Correct version is:
tree = os.path.join(tree,p).replace('\\','\')
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 4:42
Still claims there is a syntax error there. Maybe more typo somewhere?
RE: VFS Work-around
by A.J. Venter on Saturday June 9th 2018, 5:04
Yeah - I see what's happening, we're now having a conflict between the \ as an escape character and windows using it as a pathseperator.

The easy answer it seems is to use the fact that windows accepts forward slashes as well to our advantage:

tree = os.path.join(tree,p).replace('\\','/')

I tested the function in a python shell using the path from your output and it seems to produce a viable result.
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 5:32
1 down two 2 go :)

Traceback (most recent call last):
File "FO4_movfs4l.py", line 100, in
DATADIR=os.path.join(pathHdlr(PATHS['fallout4']),'Data')
File "FO4_movfs4l.py", line 52, in pathHdlr
return p.replace('{PREFIX}', PREFIX)
TypeError: replace() argument 2 must be str, not None
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 5:34
IGNORE that one.
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 4:45
I should also point out that at no point does it create any folders.
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 3:50
I may be able to fix MO2 after all, seems MO2 was changed last month in line with windows10 update last month, which I apparently did not get even thought windows claimed it was up to date. THIS is why I have windows10, useless sack of lying crap!

Still want to get this script working as a backup method for win10 in case the update(s) fails. (which they have done before)
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 5:36
Sorry if this comment is out of order, WINEHQ comment system is giving me a headache as it needs ever increasing screenspace to show comment links.

So after the last syntax suggested we seem to be getting somewhere. No more \\

D:\Games>python FO4_movfs4l.py
Setting symlink from "E:\Games\ModOrganizer2\Fallout 4\profiles\Default\plugins.txt" to "C:/Users/Riddick/AppData/Local/Fallout4/plugins.txt" for loadorder
Linking "E:\Games\ModOrganizer2\Fallout 4\profiles\Default\plugins.txt" to "C:/Users/Riddick/AppData/Local/Fallout4/plugins.txt"
Parsing MO mods configuration
Creating directory D:/SteamLibrary/steamapps/common/Fallout 4/Data/meshes/actors/character/_1stperson/animations/furniture
Traceback (most recent call last):
File "FO4_movfs4l.py", line 119, in
addvfslayer(DATADIR,modpath, log)
File "FO4_movfs4l.py", line 75, in addvfslayer
mktree(p, item.lower(), log)
File "FO4_movfs4l.py", line 48, in mktree
os.mkdir(tree)
FileNotFoundError: [WinError 3] The system cannot find the path specified: 'D:/SteamLibrary/steamapps/common/Fallout 4/Data/meshes/actors/character/_1stperson/animations/furniture'
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 5:38
Typing in manually below is the correct method of creating a directory under windows.

mkdir "D:/SteamLibrary/steamapps/common/Fallout 4/Data/meshes/actors/character/_1stperson/animations/furniture"
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 5:45
If I was to guess, os.mkdir(tree) is doing nothing or not correctly using the mkdir command, such as mkdir "path"
RE: VFS Work-around
by A.J. Venter on Saturday June 9th 2018, 5:52
It may never be getting called, os.isdir could be getting an incorrect result.

I honestly can't much help beyond this point.

Except to say the issue in pathHdlr is happening because the value of PREFIX is unset - you're probably still reading in the environment variable but it doesn't have a value.
RE: VFS Work-around
by Jarrard on Saturday June 9th 2018, 5:59
set I forgot to set WINEPREFIX=c:\ before running script, so that's a non issue.
MO2 2.1.3
by Jarrard on Saturday May 19th 2018, 4:13
Was messing with this, I didn't installed .NET and just had wine mono installed and it seems to work until you try to launch the game and it does not fully start (claims certain files not found).

I have F4SE working and that method of loading does the same, stalls on loading.

The only version that worked for me was the standalone in Wine C:\ directory, was quite surprised.

As far as I can tell this mod manager will work fine once uvfs issue is sorted, it seems to want to work but something is causing it to stuff up.

I have not found any log files giving any hints.

So close, but still so far.

DXVK+F4SE working great, if we can only get any mod manager with proper FMOD support working!
RE: MO2 2.1.3
by A.J. Venter on Sunday May 20th 2018, 4:59
Glad to hear F4SE is working, gives hope that SKSE64 may work in the future, it's basically the one major component missing to make skyrim special edition viable on wine.
RE: MO2 2.1.3
by Jarrard on Sunday May 20th 2018, 6:25
That patch seems to be generic so perhaps SKSE64 will work also,.
RE: MO2 2.1.3
by A.J. Venter on Sunday May 20th 2018, 6:38
Which patch are you referring to ?
DXVK ? Because if so, no it doesn't. It does fix graphics performance for me - but doesn't fix the SKSE64 memory allocation bug.
RE: MO2 2.1.3
by Jarrard on Sunday May 20th 2018, 6:41
github.com/hdmap/wine-hackery/tree/master/f4se This doesn't work for SKSE64?

As for MO2 I'm trying to get some traction in resolving the usfvs issues.
RE: MO2 2.1.3
by A.J. Venter on Sunday May 20th 2018, 11:10
I'm not familiar with that patch. I'll test it with SKSE64 tomorrow and report back.
RE: MO2 2.1.3
by Jarrard on Sunday May 20th 2018, 12:27
I might have tested it already and confirmed by a quick check in the menu settings for the SKSE line near the version number. I have not tested if mods actually work yet, will get around to that.
Still wish I could use MO2.
I might just resort to copying out the mods individually from the mo2 install folders until its resolved. Some mods are REAL hard to manual install with the FOMOD GUI process!
RE: MO2 2.1.3
by Jarrard on Sunday May 20th 2018, 12:28
'WITHOUT' the FOMOD GUI process!
RE: MO2 2.1.3
by A.J. Venter on Sunday May 20th 2018, 19:38
I can confirm that the patch works for SKSE64 now.
RE: MO2 2.1.3
by A.J. Venter on Sunday May 20th 2018, 19:55
Any chance this patch may fix the VFS as well as make the latest release work ?

source.winehq.org/patches/data/145126
RE: MO2 2.1.3
by A.J. Venter on Sunday May 20th 2018, 20:08
Testing that is not so easy, the patch is incompatible with the staging patches.

So to really make it work one will have to work through it, and make the same additions manually - then created a new patch.
RE: MO2 2.1.3
by Jarrard on Sunday May 20th 2018, 20:12
You could just test it with non staging? just see if it works.
I know that the vfs system will output log data into a user local directory and if those are empty then it may not be working. You can enable debug in MO2 and open to log directory.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 2:14
I can't even find this /dlls/ntdll/ntdll.spec b/dlls/ntdll/ntdll.spec file...
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 2:18
Wait nevermind, I found it under just the ntdll folder. Is this a patch that came after wine 3.8?
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 2:26
Seems the failure to patch is in the dlls/ntdll/ntdll_misc.h file, the ntdll.spec was fine. Now its just a matter of looking into whats mismatching (I'm new at this so not sure If I can spot the problem and resolve it, will try.)
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 2:37
The patch came from the Dev branch of MO2 before it became the current release about a week ago. It was posted on the main wine mailing list as a possible fix for the DLL load failure that stops the current release from even starting.
I cannot say whether it would fix the VFS issue but since it's related to the same library there is at least a possibility.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 4:06
Ok I have tested it and nothing much changes unfortunately. Basically Fallout4.exe process just sits at %12-15 CPU usage and 969MB memory usage with a black screen, so it appears to basically stall still with vfs launch attempts.

If you get anything else happening let us know,. Even if you get some actual log text because I get nothing.
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 4:13
Can you share your fixed patch so I can apply it please? We now know that it won't fix the underlying issue but it's still needed to get the latest MO2 to run (I assume you tested with that ?)

If I can get it running I believe I can come up with a workaround people can use until the internal VFS is fixed in wine. It won't be ideal. I can't make per profile ini files work, or make all's worked launched from inside MO but I could potentially make Skyrim/FO see the filesystem and load order MO2 produces.

If I can get a running MO build I'll try put my idea together and if it works I will share it.
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 4:16
s/all's/apps/g
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 4:21
I used standalone MO2 2.1.3 which worked fine before this patch. The patch doesn't seem to break anything noticed yet so there is that.

pastebin.com/Pi67wS93
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 4:23
It might not be important but MO2 is in 'C:\Mod Organizer 2' and I didn't create a portable profile.
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 4:23
2.1.3 Standalone isn't working for me - but I'll try it with your patch when I have some spare time later today and then see if I can get my idea to work.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 4:42
Well all I did was use winetricks to install/set -- win7 fontsmooth=rgb corefonts xact physx vcrun2017 and then installed dxvk and sdk. I'd say only vcrun2017 is all you need for mo2 if at all.
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 5:58
Sadly I still cannot get MO2 to run even after adding that patch.

I get this:
0009:err:module:attach_dlls "usvfs_x64.dll" failed to initialize, aborting
0009:err:module:attach_dlls Initializing dlls for L"C:\\MO\\ModOrganizer.exe" failed, status c0000005

Which leaves me unable to tryout my work-around idea since I don't have a working MO2 to work-around on.

I will see if I can get an older build of it to play nice - though this means it won't be able to do Nexus downloads - it may help other people at least
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 9:37
tried changing the folder name from MO to Mod Organizer 2?

I have seen that usvfs error code before with the installer version!
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 9:38
That is the standalone version, i just used a simpler path to extract to.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 9:39
Actually, MO2 works for me also. Hmm, are you certain you don't have the installer version?
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 9:40
Mod Organizer 2 (Standalone Version)-6194-2-1-3.7z

That's the file that was extracted in that path.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 9:46
Ok give me a tick, I have something you can try.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 9:50
Ok remove your MO2 and any local settings files (refer to zip for reference).

- Extract this to your c drive prefix, two things you must edit however.
1) users/ make sure it is correct username
2) Edit the directory path to your Fallout 4 in users/username/Local Settings/Application Data/ModOrganizer/Fallout 4/ModOrganizer.ini

Here is a copy of my MO2 with configuration files.
mega.nz/#!7iBSyQSL!RQT14bVB_idROggSj05iEs6vgWFaACxagUOvV6erX5U
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 9:51
PS. Your prefix should be a 64bit :)
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 9:56
It is, it's my SSE prefix.
I don't own fallout4, but I can work with the older version for my immediate needs and that works fine.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 10:00
May I ask what OLD version works with the vfs system for you? can fallout4 be made to work with it?
RE: MO2 2.1.3
by A.J. Venter on Tuesday May 22nd 2018, 0:56
It's not just the URL that changed, nexus changed the entire way authentication is done, the old system was insecure. The new one went live early in May and all clients had to be patched. Only MO2.1.3 supports it, nobody has updated MO1 yet.

I can't take credit for the symlink idea, nexus did it first with their new alpha client - I just used the same idea to produce a temporary work around for mo2 under wine.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 9:57
There is one warning message in problems icon however, it says .net 4.6 or greater is required, however I just have stock atm.
Perhaps you are installing .net and its causing issues there. Not sure why MO2 would work fine without .net but it does.

I would test without .net to start with because that could be THE THING that is triggering the issue.

Perhaps we are looking at this wrong and this is infact a .net related problem and not usvfs...
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 10:03
I've not got dotnet installed just wine-mono.

The old version also doesn't have working VFS - which is why I'm using the work-around I shared above (I'm working on a greatly improved version right now) - the only core difference is the new one can do the new Nexus authentication, but there is an open bug report about it being broken on wine with the specific error I'm getting. I think you are just very lucky it's not affecting you.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 10:07
Well I think because .net isn't fully installed then it isn't doing the vfs part, this would explain why the vfs logs all come up empty.

I'm installing .net462 via winetricks now to see what happens, something tells me it won't work because .net still has too many bugs when it comes to running under wine, let alone wine64...
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 10:09
Also I don't remember seeing any workaround posted by you, sorry maybe I'm blind?
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 10:19
It's not in this thread, it's in it's own top-level comment on this page.

The FUSE layer though seems to really struggle with even a few large mods.

So I'm working on a new version that will use symlinks instead (the same approach that the new Nexus mod manager is using).
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 10:26
Oh I see, sorry I missed it.

Well I look forward to this new method, maybe I can get it working with v213?

I did manage to install NET462 (its messy with lots of err's etc) and MO2 no longer complains about it being missing.

I just don't trust that .net can install itself correctly, lots of mscor halts you need to close manually during install and loads of error messages!

usvfs still shooting blanks into the log files unfortunately.
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 10:32
It should work just fine on 2.1.3 unless MO2 has changed it's config file structure between versions - which is exceedingly unlikely.

But let's kill this thread now - it's getting too squished up to read :P

Time to start a new discussion if we have more to say.
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 13:56
Okay, so on a hunch I tried your version and to my great surprize, it worked.

I have no idea what the difference is - but thanks.
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 14:09
I found the difference. Your copy is not 2.1.3 - it's 2.1.1 - which does still run, but can't log into nexus anymore.

So no downloading directly until 2.1.3 works under wine.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 21:11
Damn, I must have got confused. I was so sure it was 2.1.3. Sorry for the mix up.

I will try and get the MO2 guys to resolve the issue since it was fine with 2.1.1. I have already told them about your BETTER (IMO) method of mounting the files.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 21:32
Have you noticed that mod organizer seeks for the meta info via NMM address which is not found and possibly not longer used?

Seems like it could be fixed quite easily by redirecting nmm.nexusmods.com to www.nexusmods.com ???
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 21:54
Nexus does not allow direct ip linking, so this complicates situations as a simple HOSTS file edit is not enough because it needs a ip address and can't redirect domain names.

I'll keep investigating until I find a solution, it may not even work in the end but the first step is getting a proper domain name redirect without IP method.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 22:20
Nope, can't really figure it out.

Anyway MO 2.1.1 nexus access is likely not working because its trying to access the wrong host. In the console it will say things like 'Host nmm.nexusmods.com not found' where is should be www.nexusmods.com.
RE: MO2 2.1.3
by A.J. Venter on Tuesday May 22nd 2018, 0:59
MO2 is notoriously difficult to build even under Windows. Good luck if you want to try it.
RE: MO2 2.1.3
by Jarrard on Tuesday May 22nd 2018, 1:24
Yes perhaps but I really don't understand why the query system wouldn't work with such a fix.

Probably won't get far, see what comes of it all.
RE: MO2 2.1.3
by A.J. Venter on Tuesday May 22nd 2018, 1:31
In the meantime I am actively using my script and MO2 is workable with manual downloading, did it for years before we figured out how to make nxm links work. And as I use the script I make it better.

One suggestion: if you want to change an existing mod setup. Run the script with the UNVFS parameter before you run MO2 or MO2 will see the mods as unmanaged versions.

If you decide to try integrate it into MO2 it could work. It's written in mostly pure python and the new version removed the command calls so I think it should run under Windows with little or no changes but I've never done much windows Dev so can't be sure. You will need a python copy under wine though, and it's written in python3 so the one integrated with mo2 won't work unless you change a few things. I think the only major changes would be the print statements which don't take brackets in python2 but if it's integrated you can probably just remove all print statements, they won't be needed then.
RE: MO2 2.1.3
by Jarrard on Tuesday May 22nd 2018, 1:45
I mostly just want MO2 mod query and meta data system to work. So It makes it easier installing and categorizing the mods.

Could make it so you can install python3.0 and just make it a requirement rather then using a integrated method, honestly It's unlikely I can achieve much on my own.

I'm just hoping to back port some fixes into v211 if I'm real lucky.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 4:37
Here is my wine3.8staging build for Antergos/Arch, you can install it with pacman.
Might be useful for testing sometime. Also you might need to recreate a prefix for all patches to take effect.

mega.nz/#!qqg3WQBR!4_ohMI3Xvtzord7D_ZsFjcNHDKB0P4K_7wFd-6Ih5KA

PATCHES APPLIED: The first 9 are PBA patches (general perf patches).
Note some might not be useful.

0001-wined3d-Initial-implementation-of-a-persistent-mappe.patch
0002-wined3d-Add-support-for-backing-dynamic-wined3d_buff.patch
0003-wined3d-Use-ARB_multi_bind-to-speed-up-UBO-updates.patch
0004-wined3d-Use-GL_CLIENT_STORAGE_BIT-for-persistent-map.patch
0005-wined3d-Disable-persistently-mapped-shader-resource-.patch
0006-wined3d-Perform-initial-allocation-of-persistent-buf.patch
0007-wined3d-Avoid-freeing-persistent-buffer-heap-element.patch
0008-wined3d-Add-DISABLE_PBA-envvar-some-PBA-cleanup.patch
0009-wined3d-Add-quirk-to-use-GL_CLIENT_STORAGE_BIT-for-m.patch
wine145126.patch______________________________________________________(the patch you wanted to test)
harmony-fix.diff
fallout4-fix.diff
taskbar-fix.diff_______________________________________________________(requires registry entry)
getfreememstatecallbackfix.patch________________________________________(f4se/skse64 fix)
mapimagetopdown.patch_________________________________________________(f4se/skse64 fix)
RE: MO2 2.1.3
by A.J. Venter on Tuesday May 22nd 2018, 1:49
If you want to try I would suggest attempting to just port back the authentication changes and leave out whatever they added to the VFS layer in 2.1.3 that broke the whole thing in wine. A 2.1.2 version that can authenticate with Nexus coupled with my script would be a fine solution. Meantime I am playing SSE on wine for the first time, and that makes me happy.
RE: MO2 2.1.3
by Jarrard on Tuesday May 22nd 2018, 1:53
Yes that sounds about what will happen, I will back port 213 into 211 but start with small things that shouldn't break anything.

On top of that someone at the mo2 git said all this nastiness happened because of a windows10 update forced on everyone and wine simply has not caught up to those changes (who knows if it ever will).
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 2:36
AND, its building. Was just a matter of changing the #endif to a /* version */ so the patch knew were to insert the code because staging has other insertions going on and the endif statement is moved down below those. You might find a similar issue?

I have atm staging3.8 + PBA patches and some fo4/skse patches on top that resolve a black-screen issue. However I think they were only needed back in wine3.5/6.
RE: MO2 2.1.3
by Jarrard on Monday May 21st 2018, 10:23
Installing .NET462 does not change the situation of Fallout4.exe process hanging at about %15cpu and 937MB memory usage. It did however get rid of the MO2 error message complaining about missing .net, a small victory I guess :)
RE: MO2 2.1.3
by A.J. Venter on Monday May 21st 2018, 10:29
Well, my work-around should still work for you since it doesn't launch via MO.
MO is only used to install the mods and set the load-order, while my script then creates the proper structures for your game using MO's config files as input.

In fact it's probably better to shut MO2 down BEFORE running the script and the game.

I just pushed the updated version which is working much, much better. It uses symlinking and a record to ensure you keep your skyrim directory pristine, and has work-arounds to fix one of the big problems with native Linux VFS for wine things: windows is case insensitive and plenty of Mods contain folders that already exist in the game but under a different capitalization. Mine links all such occurrences to the existing folder.

github.com/ajventer/ksp_stuff/blob/master/movfs4l.py

I have obviously just tested it a bit so far - but it seems to be working well.
Back