Generates invalid trpfd after installing, then removing, Increased Poke Population

[Ritaku02]

(The following was done using a dump of Scarlet 1.10)

Okay, something strange is going on here. Trinity, after merging a romfs with the mod Increased Poke Population, would continue to generate a trpfd that expected the files from that specific mod. So, I went and completely deleted Trinity, re-added my mods, pointed Trinity to my game dump's romfs folder, and set the output folder. Installed all my mods except Increased Poke Population, then opened the game in Ryujinx. Game runs fine, all mods work, no problems, and checked the CRC of trpfd. Deleted output romfs folder, installed again with Trinity, but with a few mods excluded, everything's still fine, and the generated trpfd has a different checksum from before, I'm guessing from the different mod loadout.

Finally, rebuilt the romfs folder, again from scratch, with all mods including Increased Poke Population. This is where things get interesting. The trpfd this generates has a CRC of 7A88ED5B. This specific trpfd expects Increased Poke Population. Again, delete and regenerate romfs, without Increased Poke Population. The trpfd generated is the same; CRC of 7A88ED5B. Booting the game at this point, without Increased Poke Population, results it hanging at a gray screen. At this point, I have to completely delete Trinity and re-unzip it, plus oo2core, plus set it up again, for Trinity to start working properly and not generate an invalid trpfd.

[Reisyukaku]

Trinity will look in all the zips and find files that exist in trpfd and flag them such that they're loaded from romfs (this should be reflected in the tree view as well if you were to load the edited trpfd).
Assuming you're loading an unedited trpfd then the changes should reflect the current state of the checked mods in the list on apply.
Assuming you're loading an edited one manually, then it will only reflect the state of the mods in the list and leave other file flags alone.

That being said i assume you're saying that the increased mon mod is UNCHECKED during apply, but still in the list with unedited trpfd?

[Ritaku02]

"That being said i assume you're saying that the increased mon mod is UNCHECKED during apply, but still in the list with unedited trpfd?" Correct, the mod is unchecked, I've deleted the old output romfs folder, and click Apply Mods. The trpfd that's generated still expects the unchecked mod, and the trpfd it's drawing from is unedited, direct from a game dump. In fact, if I check no mods and have Trinity ouput only arc\data.trpfd, the trpfd is still exactly the same as what it generated previously.

Edit: And yes, it's drawing from an unedited trpfd, from a romfs dump of the game I did myself.

[Ritaku02]

An update; Using the latest nightly, if I delete a mod from the list, then close and re-open Trinity, then apply mods, it generates a valid trpfd.

Edit: But the mod has to be deleted from the list, not just unchecked, then I have to close Trinity after.

Edit 2: Also, the game seems to behave in random ways when dealing with an edited trpfd that you've subsequently deleted a mod without changing the trpfd. Some, it'll (apparently) continue working fine, some you get an infinite loading screen after pressing A to continue your game, and some (like removing Poke Population) causes a gray-screen hang on bootup.

[Reisyukaku]

soft locks means it looks for a file and cant find it (i.e file is flagged in trpfd).
Also just so we're clear, it still applies UNCHECKED mods on latest nightly?
Would be weird that closing it helps set it since the only thing that happens on close is it saves settings.json, which holds no bearing on applying mods. I updated the path parsing a little but i cant seem to replicate any way to get it to run an unchecked mod

var selectedFile = settings.mods.Where(x => Path.GetFileName(x.Path) == (modList.Items[i].ToString())).First().Path;
if (modList.GetItemChecked(i))
    ApplyModPack(selectedFile, lfsDir);
else
    RemoveModPack(selectedFile);

ccf13b0

[Reisyukaku]

ok i think i finally realized what the issue was, it wasnt restoring the unushed hashes, should be fixed
ad407c9

[Ritaku02]

Sorry for the delay, yes, it happens when unchecked as opposed to fully removed. Haven't had the chance to test the latest release, though