[FEATURE] - Tweaks for Mod Manager & Patcher/Panacea

[Zurphing]

For the Mod Manager:
It'd be nice if we could add an additional "dependencies" tag to mod.ymls, which would prompt the user to install an extra, additional mod if the mod manager detected the user trying to build said mod without the dependency.

On that note, it'd also be nice if we could somehow direct the priority a mod should be installed, maybe with a "priority" tag? It doesn't necessarily have to even do any shuffling, it could just be some bold red text underneath the authors name that tells the user "Install this ABOVE all other mods" or "Install this BELOW all other mods," mainly for mods like Rando or Re:Fined.

Finally, some more granular handling of applying remastered assets to newly patched in files. Right now by default, the patcher and Panacea will simply use something like this to apply remastered textures.
entries.push_back(*(short*)(off + 12) + baseoff + 0x20000000);
This works in most cases, but as it turns out the value 0x20000000 can be different depending on if the texture is intended to make a mesh "glow" or not. An example of this being the player model in Space Paranoids. If a remastered texture has transparency above 128, just like on PS2, that texture is meant to glow, and the value we should add should instead be something like 0x40000000. Whether this could be a user-specified tag in a mod.yml, or automatically done by Panacea/the patcher by reading a remastered file and seeing if it fits the criteria, either way to resolve this would be fine imo.

[Yokimitsuro]

something like this?

[Zurphing]

This is exactly what I had in mind, really nice job!

[Yokimitsuro]

I'm adding some quality-of-life improvements, such as:

When installing a mod, if it has dependencies, ask the user if they want to install them as well, and install them in the order defined in the mod.yml, taking into account the Above and Below fields.

[Yokimitsuro]

[Zurphing]

Is there handling for if a user clicks yes to install the dependencies, but doesn't enable them in the mod manager and tries to build the base mod without checking the boxes for the dependency mods? If not, I think when the user checks the box for a mod with dependencies, it should also check the boxes for its dependency mods.

[Yokimitsuro]

Is there handling for if a user clicks yes to install the dependencies, but doesn't enable them in the mod manager and tries to build the base mod without checking the boxes for the dependency mods? If not, I think when the user checks the box for a mod with dependencies, it should also check the boxes for its dependency mods.

I agree, but I think we should prompt the user first—ask whether they want to enable the dependencies instead of forcing it. This way, we maintain flexibility while also preventing potential build issues.

[Zurphing]

That sounds better, good call!

[shananas]

I'm unsure i understand the latest statement so ill give my thoughts with an example.
we have Mod A and Mod B. Mod A has a dependency of Mod B and will not work without it.

I see two ways of equal value in dealing with this.

1. If you enable Mod A it also automatically enables Mod B.

2. Or if you enable Mod A it gives a popup that works like this. Tells the user Mod A needs Mod B to work and asks if they want to enable it.
   If the user says no both mods stay disabled.
   If the user says yes both mods get enabled. The important part here is since Mod A has a dependency of Mod B it cannot be enabled without it since it wont work and would cause false bug reports.

Also if the user disables Mod B then Mod A should automatically be disabled. this can have a popup also if wanted but the base idea is Mod A can never be enabled if Mod B isn't installed and either already enabled or enabled by MM when enabling Mod A

if for some reason Mod A can be enabled without Mod B then the mod author has written their mod.yml incorrectly and should fix that.

[Zurphing]

If I'm understanding it right, the idea is that Mod A depends on Mod B and Mod C.. If the user does not have Mod A, it prompts the user to download Mod B and Mod C, and will also automatically place the mods in the priority they need to be. Example being, Mod C needs to be BELOW Mod A but ABOVE Mod B, for whatever reason.

But lets say we have another mod, Mod D which might depend on Mod C and nothing else. If we force the order and placement, its possible it could cause issues when trying to use both Mod A and Mod D together, which would ordinarily be compatible using a specific order, which is why we would ideally want to nudge people into building the dependencies alongside a mod, but not force it. At least, that's the way I'm interpreting the change.

Regardless, I think it ultimately depends on the implementation and testing out some edge-cases like this, I'm personally fine with whatever makes the most sense that removes as much manual fiddling from an end-user as possible.