Why the conflict between "FNIS Data" and FNIS itself?

[VulcanTourist]

Enabling the Run FNIS on Deployment Event option in Settings appears to cause the creation of an FNIS Data "mod" (in Skyrim SE), and this then conflicts with the actual FNIS mod over multiple files. It seems illogical and confusing that an option that volunteers to help manage FNIS for the user would instead create file conflicts that the user must then manage while being ill-informed what choices to make.

 

Why is this happening, and what is the best resolution?

[rmm200]

FNIS is the program you download from Nexusmods to create animation data for you from animation packs.

By definition, it is writing out data unique to the profile you are running.

In the bad old days, Vortex merged all this data back into the FNIS mod itself, messing up every other profile that uses animation.

Now, that profile specific data gets written to a profile specific file which always takes precedence over the downloaded executable.

If you have a complaint with the way this works, take it up with the FNIS extension author. It is an addon to Vortex, and you can turn it off.

[fore]

Enabling the Run FNIS on Deployment Event option in Settings appears to cause the creation of an FNIS Data "mod" (in Skyrim SE), and this then conflicts with the actual FNIS mod over multiple files. It seems illogical and confusing that an option that volunteers to help manage FNIS for the user would instead create file conflicts that the user must then manage while being ill-informed what choices to make.

 

Why is this happening, and what is the best resolution?

 

This file conflict is the result of a decision which was made more than 6 years ago to support NMM installations. NMM doesn't have "FNIS Data" or "FNIS Overwrite" files that can simply be removed by a user when FNIS is uninstalled.

 

During its generation process, FNIS creates modifications of Skyrim files. These modifications are unwanted, and cause major trouble in case FNIS is removed. Therefore FNIS includes a set of original Skyrim files. The knowledge of these files allows NMM to remove all modified files in the event of an uninstall.

 

Therefore it is (almost) always safe to overwrite FNIS files. Except in those rare (illegal) attempts by some mods to include FNIS specific files.

[VulcanTourist]

My point seems to have been missed here: Vortex is reporting a file conflict with a "mod" that was created as a result of an option within Vortex itself. Why isn't Vortex also hiding or handling the file conflict automatically?

 

 

Therefore it is (almost) always safe to overwrite FNIS files. Except in those rare (illegal) attempts by some mods to include FNIS specific files.

In the absence of any automatic handling of this conflict, I still don't understand which of the two, FNIS Data or Fores New Idles in Skyrim SE - FNIS Behavior SE 7_4_5, is supposed to be allowed to take precedence? There is a rule in place that ensures that FNIS Data loads after actual FNIS, yet the conflict lightning bolts are still presented as if there's a still a problem.

 

Perhaps I've misidentified the problem here? Is it that the conflict icons continue to be displayed even when an ordering rule is in place to govern the conflict?

[fore]

 

In the absence of any automatic handling of this conflict, I still don't understand which of the two, FNIS Data or Fores New Idles in Skyrim SE - FNIS Behavior SE 7_4_5, is supposed to be allowed to take precedence?

 

Always "FNIS Data". This one includes the files that are created anew by FNIS generation.

[VulcanTourist]

Perhaps I've misidentified the problem here? Is it that the conflict icons continue to be displayed even when an ordering rule is in place to govern the conflict?

Ah... I now realize that part of the issue and my confusion is caused by COLORBLINDNESS. The lightning bolts are apparently left displayed after a conflict is handled BUT the color changed to green. I didn't notice this, because I am partially colorblind with respect to certain shades of red/brown and green. The interaction of the dark background may also be making it worse for me. The dependency icons are even more color-inscrutable because they are so thin (and may even be multi-colored, I literally cannot tell).

 

Please include a Colorblind option to remove those conflict icons entirely once a conflict is governed, rather than merely recoloring them, with a toggle to manually redisplay them when that is needed for review.

[fore]

 

Please include a Colorblind option to remove those conflict icons entirely once a conflict is governed, rather than merely recoloring them, with a toggle to manually redisplay them when that is needed for review.

 

I haven't used Vortex yet, but I HEAVILY support this request. 8% of all males have this kind colorblindness, and I am one of them as well. :)

 

Women have a big advantage here. Only 0.4% of them have this deficiency. Because they were the ones who introduced the ability to better see red colors during evolution. They were the berry gatherers, while males only followed brown furs.

[HadToRegister]

 

Perhaps I've misidentified the problem here? Is it that the conflict icons continue to be displayed even when an ordering rule is in place to govern the conflict?

Ah... I now realize that part of the issue and my confusion is caused by COLORBLINDNESS. The lightning bolts are apparently left displayed after a conflict is handled BUT the color changed to green. I didn't notice this, because I am partially colorblind with respect to certain shades of red/brown and green. The interaction of the dark background may also be making it worse for me. The dependency icons are even more color-inscrutable because they are so thin (and may even be multi-colored, I literally cannot tell).

 

Please include a Colorblind option to remove those conflict icons entirely once a conflict is governed, rather than merely recoloring them, with a toggle to manually redisplay them when that is needed for review.

 

 

Go to SETTINGS------>THEME--------->CLONE

 

Now change the colors #86b951 (green) and #ff1c38 (red) to something you can differentiate between

[rmm200]

 

 

Perhaps I've misidentified the problem here? Is it that the conflict icons continue to be displayed even when an ordering rule is in place to govern the conflict?

Ah... I now realize that part of the issue and my confusion is caused by COLORBLINDNESS. The lightning bolts are apparently left displayed after a conflict is handled BUT the color changed to green. I didn't notice this, because I am partially colorblind with respect to certain shades of red/brown and green. The interaction of the dark background may also be making it worse for me. The dependency icons are even more color-inscrutable because they are so thin (and may even be multi-colored, I literally cannot tell).

 

Please include a Colorblind option to remove those conflict icons entirely once a conflict is governed, rather than merely recoloring them, with a toggle to manually redisplay them when that is needed for review.

 

 

Go to SETTINGS------>THEME--------->CLONE

 

Now change the colors #86b951 (green) and #ff1c38 (red) to something you can differentiate between

 

 

That deserves a section in the WIKI titled "Colorblind Considerations".

People with the problem would probably not find your solution.

[SoupViking]

I'm running into this issue and I can't get it resolved. I allowed FNIS Data to load last, but after saving that choice and deploying, then I am asked to fix it again. OVer and over.