App is ignoring MO2 virtual file system and changes .hkx files directly inside mods sub-loders

[Ne0niq]

Hi ShikyoKira! First of all, thank you for your hard work on this wonderful tool!

Please let me to describe my actions in strict order, so that you can understand what happened and how it happened.

0. I installed Nemesis Behavior Engine as a mod in Mod Organizer 2 and added a link at MO2 panel to start the tool (without designating working folder).

1. At first I had problem with the behavior engine tool and solved it in my way: The tool did not started though MO2 while the Nemesis_Engine folder was placed in [Mods] sub-folder of MO2. By the way, my MO2 is in portable mode, so no registry data, only Steam registry data with Skyrim installation path.

2. How I solved the problem with tool: I placed Nemesis_Engine folder with the tool into C:\Games\Steam\steamapps\common\Skyrim\Data\ and leaved Meshes and Scripts in E:\Games\MO2\Mods\Nemesis Unlimited Behavior Engine. After that I changed the MO2 link to run the tool to C:\Games\Steam\steamapps\common\Skyrim\Data\Nemesis_Engine\Nemesis Unlimited Behavior Engine.exe without designating the working directory. As a result the tool is started successfully.

3. I updated and patched Nemesis behavior successfully and all animations worked fine.

4. I know that there is no place for FNIS here, but please read further to understand the Nemesis issue, which I couldn't reveal without trying to run FNIS on my mod set. I think it's useful info for you anyway. I decided to switch to another MO2 profile with FNIS (a variant of my mod set without Nemesis) to run the game with [FNIS Sexy Move] mod I faced the issue - T-pose when running the game with FNIS despite there where no errors when building a patch. My personal mistake was that I forgot to remove/deactivate Nemesis files in MO2\mods and Skyrim \Data. I deactivate/removed all Nemesis files, then run the FNIS patching process again and still got T-pose. I realized that after Nemesis some .hkx files was patched right inside the source folders of the mods in MO2\Mods. To confirm that I used file manager (Total Commander) and searched for *.hkx in MO2\Mods, then I sorted the search result in descending order by date. My the suspicions were confirmed - many .hkx files had new time stamp right inside each mod subfolder, so they was changed directly instead of virtual file system and output to MO2 Overwrite folder. It was kind of torture - manually restoring all behavior .hkx files of many-many mods (I have over 1300 mods set with hudreds of custom animations), but I am fine with that, I always have a backup. After I restored initial files of each mod FNIS worked fine again.

MY RESEARCH RESULTS: Nemesis Unlimited Behavior Engine changing behavior files directly inside the mods sub-folders not in virtual file system of MO2. Since all animations working well in game, this is not the issue, but technically, it's wrong, because mods files must stay untouched in Mod Organizer 2 - it's the MO2's purpose.

I always admiring your work on Nemesis project, ShikyoKira, so I hope my report will be useful for you, even if I was wrong in something, I don't know.

I'm guessing that the reason is hidden in a moment when I decided to separate sub-folders of Nemesis in two parts, as I described in p.2, but I am not sure that this can make difference.

Currently I am afraid to use Nemesis because I don't want to loose 2 years of work on this huge and beautiful, stable mod set. Since I got all animations working with Nemesis I don't think that I did something wrong, but I will be glad to hear from you anything if I was wrong. Also I suspect Mod Organizer itself, so it may be no Nemesis issue, but it's very hard to catch the reason.

Can you help me, ShikyoKira? I think Nemesis should use MO2 virtual file system correctly and not change .hkx files directly inside mods sub-folders, because mods are placed outside of actual Skyrim\Data folder and must be untouched.

P.S. I know that the PatchLog may turn out to be useless, but here it is (GDrive), just in case. You can find many warnings about wrong animations there, but all of them working, so I don't know why the tool trying to tell me that. Sorry if I am overloaded you by the info ;)

[ShikyoKira]

Hi, Ne0niq. What an excellent report.

1. First, regarding the execution procedure, I have noticed it varies case by case, for me, it works whether I have it in MO's mod list or direct skyrim's data directory. Still, I have received several reports about MO not able to start it unless it is in data directory. As I can't recreate this issue and the fix is quite simple, I simply just ignore it and plan to just leave the fix in FAQ

2. I have long been aware of Nemesis changing the behavior directly in other mods. However, this problem isn't unique to Nemesis, FNIS has this issue as well, if you do the same test for FNIS, you will notice often the time stamp is different as well. And Fore brought it up to Tannin ages ago but their conversation turned sour and til this day it remained unfixed.

This means that the problem isn't originated from Nemesis or FNIS but how MO react to tools like Nemesis and FNIS. Since I am not the author of MO, this is the a speculation of where the problem arise in MO. MO has a restrict policy of editing the source, meaning the files in mod list. This can only occur when the source is being read while being written at the same time, treat it like in Edit Mode. So that when you do anything in xEdit as well as CK, the source will be updated, not new files being created in Overwrites. In the case where the source is only being written, this means that it is being created not edited. This will result in the output being created in Overwrites.

The problem with Nemesis and FNIS is MO fails to execute this policy correctly. When I create a new file, MO treats it as Edit and Write Mode not Edit Mode. FNIS relies on MO plugin to solve this issue.

In short, both issues, I have had such issue before but either nothing I can do to fix it as it is from MO side =/

[ShikyoKira]

I know this isn't exactly caused by Nemesis. But I will try if we can come up with a solution to it as I understand your concern and frustration

[ShikyoKira]

few hours of testing, these are my findings:

1. Export the new file in the original location and under the original file name. Doesn't work, gets replaced
2. Export it in a temporary folder, copy its binary, delete it, and create a new file out of it in the correct location. Doesn't work, still get replaced
3. Export it in a correct location but under different name, since the new file and the original file are not having the same name, by logic both files would be there, hence i proceed to rename the new file to the original file name. Doesn't work, still get replaced

The 3rd one is my last resort. Unfortunately even that doesn't work, suggesting that there is no way around it. So I'll just close this as it is no longer our issue. Thanks again for reporting

[Ne0niq]

Thank you very much for your time, additional testing and explanation!

[Al12rs]

Hey, Mo2 Dev here! So there is some misconception about how the Mo2 VFS is supposed to work. The VFS is transparent to changes to files. If a file present inside the VFS is edited, replaced, deleted and recreated it will end up in the starting position. This is to have consistency because the VFS can't actually protect files inside the mods from open for writing editing or deletion. So if you drop a file with the same name in the VFS as one that is or was there already in the same session it will get replaced. Only new files end up in overwrite. I would also like to have Copy On Write VFS but there are so many issues with the entire concept. Many Devs with great experience have discussed on this already extensively. So for now that is what we have.

Fnis actually implemented a feature to simply not install the generated files inside he Data folder and instead drop them in a user defined location (for example a Mo2 mod). This way Fnis does not modify any mods files and the user can have multiple profiles without issues.

Maybe something similar could be added to Nemesis as well. Allow users to define an output folder other than the Data folder so that they can avoid overwriting mod files. Other tools such as Bodyslide or Dyndolod also offer a similar feature.

[ShikyoKira]

Thanks for the confirmation. I was expecting that to be the case after all the testing.

If users can define an output folder then everything should be fine or at least that's a decent workaround. Thanks for the suggestion, I will look into it to make sure everything is as expected