[Bug]: Pandora looks for FNIS behaviours & animations in the wrong directory

[line0]

Check for duplicate issues

• [X] I have verified that there are no duplicate issues.

Version

v2.3.0-beta

Provide Instructions on Reproducing the Problem

As a Vortex user whose output path is not the Skyrim data directory but an out-of-tree directory in the Vortex mods folder, I was wondering why Pandora would pick up Nemesis and Pandora mods just fine, but simply not detect any FNIS mods.

So I had a quick look at the source code and found the (likely) culprit in FNISParser.ScanProjectAnimList(): Pandora looks for behaviours and animations in the output path (which is either empty or only contains the Pandora outputs from a previous run), when it really should be looking in the CWD (i.e. the skyrim data directory), instead.

Once I made the following changes, FNIS mods started to be detected and processed just fine. I also confirmed they work in-game.

From:

https://github.com/Monitor221hz/Pandora-Behaviour-Engine-Plus/blob/b8e5d7a38c369be83c407fb358f565e4fc3fee1c/Pandora%20Behaviour%20Engine/Models/Patch/Patchers/Skyrim/FNIS/FNISParser.cs#L153-L154 https://github.com/Monitor221hz/Pandora-Behaviour-Engine-Plus/blob/b8e5d7a38c369be83c407fb358f565e4fc3fee1c/Pandora%20Behaviour%20Engine/Models/Patch/Patchers/Skyrim/FNIS/FNISParser.cs#L170

To:

var currentDirectory = new DirectoryInfo(Path.Join(Directory.GetCurrentDirectory(), project.ProjectFile.RelativeOutputDirectoryPath));

ScanProjectBehaviors(project, currentDirectory);
ScanProjectAnimations(project, currentDirectory);

Steps to reproduce:

0. Install Pandora as a mod in Vortex (e.g. in D:\Games\Vortex\Mods\SkyrimSE\Pandora - Stage Data), deploy it (which symlinks its files into the Skyrim data directory tree, e.g. D:\Games\Steam\steamapps\common\Skyrim Special Edition\Data) - I don't think this part is relevant, though.
1. Have some Pandora/Nemesis and FNIS mods installed and deployed.
2. Create an empty output folder for Pandora within the Vortex mods directory (or anywhere else, shouldn't matter).
3. Run pandora with:
   • Target: D:\Games\Steam\steamapps\common\Skyrim Special Edition\Data\Pandora Behaviour Engine+.exe
   • CLI Args: "-o:D:\Games\Vortex\Mods\SkyrimSE\Pandora - Stage Data"
   • CWD/Start In: D:\Games\Steam\steamapps\common\Skyrim Special Edition\Data
4. Press Play
5. Observe the output listing all deployed Pandora mods but not a single FNIS mod.

Provide Relevant Files

(nothing of interest)

Provide Visual Proof (optional)

No response

Contributing To Development

• [X] I read this project's Contributing To Development

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. It will be closed shortly unless activity resumes.

[djarb]

@line0, since you've identified this bug and worked out how to fix it, why don't you create a pull request so that the main devs can just merge it instead of having to put the effort into re-solving the problem?

[Monitor221hz]

I don't understand how this problem arises. If Pandora is installed externally, you should be using the -o: startup argument to specify an output path that is your Skyrim data directory. If Pandora is installed internally, the output path should be the Skyrim data directory by default.

[djarb]

It comes up when the -o option is used to specify an external output directory. Then, the output directory would be overlayed onto the game directory by a mod manager. The recent release notes seemed, to me, to be saying that this was the preferred way to do things.

[Monitor221hz]

Right, it keeps slipping my mind that Vortex users don't have the built-in manager option of setting output mods like MO2.

The problem here is that MO2 users that install Pandora to an external location use the -o: command to tell the engine where the data folder is (letting the VFS handle the output path), while Vortex users use it to as a way to set the output mod folder. If the solution were to be implemented as is, MO2 users would be affected with the same bug.

This arises because MO2 users (me included) are misusing the -o: command, using it to inform the engine of the game location instead of using it to specify where the files are output.

In the next version I'll switch to using registry paths in combination with the change proposed above, which should fix the problem for Vortex users and stop MO2 users from needing to use the output command in a hacky way.

[Monitor221hz]

Fixed in v2.3.5-alpha.