[Request] designate directories full of toggleable mods about thatorthis HOT 11 CLOSED

Yup, that is theorically possible; we can do it by proxying DirectoryModCandidateFinder and hijack its callback to filter out individual mods that we don't want (read as: a bunch more Fabric hacks). I will look into it after fixing #2.

I'm actually looking for a more general way to control mods' loading. ThatOrThis is currently designed for modpacks, but it's just a proof-of-concept; maybe in the future I'll make it a library for the community to use, or make different versions of ThatOrThis for different needs.

from thatorthis.

In terms of user interface, I've came up with three different ideas to implement the toggling of individual mods.

1. Define a special directory (e.g. .minecraft/mods/thatorthis) that is always loaded but mods inside can be "disabled" individually (via a seperate settings screen). Modpack rules are not affected.
2. Certain options of a modpack rule can be "edited" by right-clicking on the rule button. This brings up a seperate screen where user can disable mods controlled by this option.
3. Introduce a global blacklist that affects all modpack rules.

Your "toggle_directories" suggestion is like a mixure of ideas 1 and 2. I prefer idea 1 personally, but with flexibility concerns in mind I can't really decide.

from thatorthis.

Well 3 sounds like it enables modpack users to accidentally break things.
1 would work and be simple, but it would be nice to be able to separate optional mods into 'categories' of sorts.
2 sounds good, but maybe have a special case for when a rule only has one option (making it effectively like my original idea in that case)?
edit: oh and also I should say I was assuming 2 would be per-option and opt-in

from thatorthis.

Well, it's been a hard week refactoring the config & GUI code. I accepted your original idea (although with some minor tweaks), since it's flexible enough while not being too messy. Nested screens are also implemented, fulfilling the request of able to put mods into "categories".

v0.2.0 is full of haste code, let's hope it's stable enough. Note that the format of config files has changed; migration guide on the release page.

from thatorthis.

Giving it a try now, thanks for your hard work!

from thatorthis.

I'm confused as to what types do for options.
Here is my updated rules.json

My intent is to make the "OPTIONAL" and "CLIENT" rules allow you to completely enable/disable the directories of their respective names, but also, while they're enabled, allow the mods in those directories to be toggled individually.

I thought this would mean creating a "DEFINED" rule with a "GENERATED" "on" option, but currently my rules are behaving as though everything were "DEFINED".

If this isn't the intended use of types in options, what is?

from thatorthis.

Types only work on rules, not rules' options. A DEFINED rule can have a set of options in the options field, while a GENERATED rule allows toggling mods in the directories given in the directories field. There is currently no way to combine both types' behaviors, i.e. you cannot enable/disable the whole directory and toggle mods in it at the same time.

I might have overlooked this when designing the new config format a week ago, but I don't really see the point. A "select all" button on the GENERATED rule screen would be helpful, though.

As for your rules.json, there's no point adding "type": "GENERATED" to options; these are not read anyway. This rules.json should work, but as shown above you cannot disable a whole directory loaded by a GENERATED rule, so all mods are loaded by default. Fabric Loader will ignore mods aimed for a different side, so I guess it's fine. A modpack typically won't have server-only mods bundled in, also.

from thatorthis.

Oh oops, I misread the release notes and thought that the "DEFINED" present in the choices.json was actually part of an "option".

Adding a button to toggle all mods in a "GENERATED" directory would be nice though

from thatorthis.

Apologies if I'm just making a silly mistake, but my updated rules.json still isn't working.

Here's latest.log, thought afaict it doesn't give any specifics (informative error messages would be nice, but I understand this mod is still early in development).

In-game when I try to access thatorthis via mod menu I get a message saying there were errors in my rules.json and the option to open the logs directory.

from thatorthis.

The GENERATED rules are missing their defaults field. Adding it should fix the problem.

     // ...
     {
       "id": "OPTIONAL",
       "type": "GENERATED",
       "caption": "Optional mods: %s",
       "tooltip": "Mods with a server component that aren't required on the client. ",
+      "defaults": [ ],
       "directories": [ "OPTIONAL" ]
     },
     // ...

Have a NullPointerException thown on every missing field sounds pretty stupid, but afaik implementing optional fields with Gson is not trivial, and the whole Rules structure is read-only by design, making things worse. Maybe later.

Also, v0.2.1 has just released, with the ability to disable a screenful of mods without config file changes. Give it a try.

from thatorthis.

It's working great on 0.2.1 now that I've added the defaults and removed the %s placeholders.

Thanks again for the mod and for the updates : ]

from thatorthis.