ezforever / thatorthis Goto Github PK

When creating my modpack, I am finding it annoying that when i make an error in rules.json, i have to close the game anyway to fix it.

It would be useful to have a (togglable,disabled by default) option to just crash when rules.json was invalid.

I love this mod and it is making life so much easier, but i think it'd be even better if there was an icon like mod menu has, above that icon, or a bar (like mod menu) (configerable)

This mod seems amazing and I think it will make my life a lot easier, but there's one more feature that I would find very useful.

A lot of client-only mods are ignored and therefore optional when connecting to servers.

I'd love to be able to put all such mods in a directory and allow the user to individually toggle each of these mods.

This could maybe be implemented by having a rule that, instead of an "options" entry has its own "directories" entry, or maybe call it "toggle_directories" or something to make it clearer that directories specified at the rule level mean they're for toggling, not an "option".

It is funny, but it is a bug :)
Demo
(I used a laptop touchpad to get this)

my rules – rules.zip

An example modpack (e.g. MultiMC or Curseforge-based) would be nice to get a better grasp at how the rules work.

Currently (as of v0.2.1) in a dedicated server environment, there is no way to change ThatOrThis' settings without manually editing choices.json. This is not considered a lack of feature (since ThatOrThis is not designed for server-side anyway), but it would be nice to have a similar GUI as on client-side.

Features would be like:

• An additional button will be added to the server GUI (that window with console and memory usage bar charts), which brings you to the settings window.
• The settings window will be remade using a Java GUI toolkit (Swing?) mimicking the layout and behavior of a client-side settings screen.
• The window will not be textured, and because of the inability to render formatting codes, all formatting codes will be omitted from the display.
• If server is started in headless mode (-nogui), no button or window will be shown.

This feature will, however, need to rewrite a lot of vanilla GUI components. Also, since even server.properties needs to be edited by hand, there is no strong demand to implement this feature. So I'm posting this question issue here for suggestion and feedback.

Please consider publishing the mod to Curseforge to make it easier for modpacks to use it.

Edit: actually modpacks couldn't use this right away due to JAR bundling needed, but if you implement the direct download, they could. Still, would be great to have it in CF already for exposure.

Example

{
  "aliases": {
    "sodium": [ "sodium" ],
    "sodium-extra": [ "sodium-extra" ],
    "cool-mods": [ "mod1", "mod2" ],
  },
  
  "rules": [
    {    
      "id": "cool-stuff",
      "type": "DEFINED",
      
      "caption": "Cool Stuff: %s",
      
      "options": [
        {
          "id": "on",
          "caption": "On",
          "isDefault": true,
          "directories": [ "cool-mods" ] // works as if mod1 and mod2 were in a directory called "cool-mods"
        },
        {
          "id": "off",
          "caption": "Off",
          "directories": [  ]
        },
      ]
    },
    {    
      "id": "sodium-v-extra",
      "type": "DEFINED",
      
      "caption": "Renderer: %s",
      
      "options": [
        {
          "id": "sodium",
          "isDefault": true,
          "caption": "Sodium",
          "directories": [ "sodium" ] 
        },
        {
          "id": "sodium-extra",
          "caption": "Sodium Extra",
          "directories": [ "sodium", "sodium-extra" ]
        },
      ]
    },
  ]
}

Reasoning

Many times you will want a mod to be individually togglable and this could happen for a large amount of mods, with the current system you'd have to make a new directory for each and every mod you'd add. Under this system, this would improve UX, as everything can be changed in a singular file (or a set of them, if this feature is not part of rules.json), without the need to manage mod directory structure.

Description
The "reset" (§r) parameter does not apply to text during automatic line breaks. At the same time, the last specified parameter starts to apply to all subsequent text by default, and the new "§r" will reset the text formatting to it.

Demo
Example rule:
{ "rules":[ { "id":"test_rule1", "type":"DISABLED", "caption":"Hover me", "tooltip":"randomtext§a §rrandomtext§a §rrandomtext§a §rrandomtext§a §rrandomtext§a §rrandomtext§a §rrandomtext§a §rrandomtext§a §rrandomtext§a §crandomtext§r randomtext randomtext" } ] }

Normal view:

When upscaling the interface:

To reproduce

• Install latest ThatOrThis
• Move one of the rules.json files given below as an example to the config folder
• Launch Minecraft
• Open ThatOrThis screen
• Wrong text formatting here (if it isn't, set a larger scale of the interface)

Example rules
Example rule.zip
Noticed this when creating my modpack: My rules.zip

As the title says. Maybe this mod can switch to quilt?

Quilt 看起来支持加载额外模组，也许可以切换到 Quilt？

Allow right-clicking a mod in the toggable mods section to open its Mod Menu Config GUI.

As mentioned in #1, I have a plan to make ThatOrThis a library mod, expose the ability of choosing and loading additional mods to other mods and developers. Modpack configs, GUI elements, etc. will be moved to a separate (optional) mod.

However, there are some questions to be answered before we could work on this:

1. Is this will ever be needed? If not, better leave the mod in its current form. Refactoring code is never fun to do.
2. How will the mods communicate with the library? Given that ThatOrThis runs before initializing other mods, it's impossible to "ping" each mod on the fly for their opinions.
3. How should the library deal with rule management and conflicts? What if two mods suggested exactly opposite rules?

In some situations it would bee useful to be able to prevent loading mods from certain directories or other rule objects. For example when user want to load a mod that is incompatible with another loaded mod, this is a good precaution.

Is it possible to implement something like this?

when starting the mod it will give this error:

Exception in thread "main" java.lang.NoClassDefFoundError: net/fabricmc/loader/discovery/ModResolutionException at io.github.ezforever.thatorthis.Main.run(Main.java:33) at io.github.ezforever.thatorthis.PreloadAdapter.<clinit>(PreloadAdapter.java:14) at java.base/java.lang.Class.forName0(Native Method) at java.base/java.lang.Class.forName(Class.java:466)

Technically speaking, ThatOrThis take its inspiration from Modsmod and GrossFabricHacks, which abuses the LanguageAdapter feature of the Fabric Loader. This allows part of this mod's code to run even before Fabric Loader starts to initialize most other mods. It then read configs, resolve for additional mods to load, and inject them into the loader via Java reflection wizardry.

NOTE: ThatOrThis is only intended for small, client-side mods. It may cause crashes and/or server/world incompatibilities if rules and options are not designed carefully. Test your modpack throughly before and after installing this mod.

Reading those paragraphs made me wonder - is that "gross hack" even necessary? Considering that it cannot hotswap mods anyway, wouldn't it be way easier to just append a ".disabled" or similar to the jar's filename?

Kept here to replace TODO.md in the repo. Items marked "(?)" are still under consideration.

Emergency changes

Fabric Loader v0.12.0 introduces a massive refactor on mod loading mechanics, which breaks ThatOrThis completely. A rewrite needs to be done before it's too late. As the rewrite will break compatibility with Fabric Loader v0.11.x, support for these versions will be dropped on ThatOrThis v0.3.0.

• Internals rework due to Fabric Loader's new mod resolution algo based on "biases" (FabricMC/fabric-loader#461) (commit de94067)
  • What if ThatOrThis found a mod with higher biases than the currently loaded one?
• Refactor FabricInternals to keep only interfacing code and move inner classes to a new package (commit de94067)

Stuffs to a better & cleaner config schema: (Include in v0.3.0?)

• Improve config schema robustness by allowing optional fields to be unset (Not a easy thing to do with Gson)
  • Introduce external libriaries (jackson / JSON5) instead? (Relocate classes to avoid conflict)
• Predicates for rules/options? (#21 has a brilliant idea)
• Add tooltips to GENERATED rules' buttons (text from modmenu.descriptionTranslation.XXX? Format?)
• Customizable/fixed namespace for ruleset translation (make text fields optional in the process)
• Recover from mod conflicts ("safe mode"/load default/last-good choices)
• Online tool for v0.2.x~v0.3.0 transition

• Show filtered out mods in debug log (commit 216b4ba)
• Check for LanguageAdapters and GrossFabricHacks entrypoints on injecting a mod, and if found, issue a non-fatal error (LanguageAdapter found in "xxx-language-support"! Expect it to break)
  • (Experimental) support on loading LanguageAdapter mods (commit e6c2361)
• Mark each additional mod's parent as ThatOrThis (or a dummy mod like "Mods loaded by ThatOrThis") for simplifying the mod menu (Set CustomData modmenu.parent; need more reflection hacks)
  • Maybe inject an non-existent container mod in the discover phase?
• (?) Download mods from CurseForge/Modrinth/Maven/Link (FabricMC/fabric-loader#282)
  • Modrinth has a Maven repository (https://api.modrinth.com/maven)
• (?) Allow loading "pure" jars as libraries (Makes Maven capability more useful)
• (?) Utilize ArgumentModCandidateFinder (FabricMC/fabric-loader#470)
• (?) Replace @xxx.xxx hack with JSON-based text (Text net.minecraft.text.Text.Serializer.fromJson(String))
• (?) Refactor RuleHolder to be like a container, similar to ChoiceHolder? (Good for consistency but otherwise unnecessary for now)
• (?) Combine disabled into ChoiceHolder (Not possible for now due to Map<> inheritance, but should be done)
• (?) Rewrite GUI components to take advantage of 1.17 features (e.g. CyclingButtonWidget)

The ability to search through toggable mods would be very nice.

It would be nice to have rules that depend on the enabled state of generated/defined types.

For example, using boolean conditions with the field "ruleCondition" to enable a rule configuration:

{
  "rules": [
    {
      "id": "shaders",
      "type": "DEFINED",
      "caption": "Type of optimizations: %s",
      "tooltip": "Enable Sodium optimizations (Most performant) or Optifine (Better shader tunning)?",
      "options": [
        {
          "id": "sodiumId",
          "caption": "Sodium",
          "directories": [ "modsSodium" ]
        },
        {
          "id": "optifineId",
          "caption": "Optifine",
          "directories": [ "modsOptifine" ],
          "isDefault": false
        }
      ]
    },
    {
      "id": "SodiumOnlyOptimizationsId",
      "type": "GENERATED",
      "caption": "Sodium only optimizations",
      "tooltip": "Enable other optimization mods that are not compatible with optine",
      "directories": [ "sodiumCompatibleOnlyMods" ],
      "ruleCondition": "sodiumId"
    },
    {
      "id": "SodiumOptimizationMod43AddonsId",
      "type": "GENERATED",
      "caption": "Configure mod 43's Addons",
      "tooltip": "Choose what addons are enabled for mod 43 (only compatible with Sodium)",
      "directories": [ "sodiumMod43Addons" ],
      "ruleCondition": "SodiumOnlyOptimizationsId:modid43"
    }

The first rule (DEFINED) has two options, either Sodium or Optifine.
When choosing Sodium, the user then could see a new button with sodium only mods (rule with id SodiumOnlyOptimizationsId).
When enabling a specific mod (modid43, in the example), the user could then see another button for configuring modid43's addons.

PS: Really nice work on this mod!

https://github.com/EZForever/ThatOrThis/blob/master/src/main/java/io/github/ezforever/thatorthis/internal/Bootstrap.java#L19-L32

https://modrinth.com/mod/yacl

I have a client+server environments and I'm trying to use thatorthis to allow me to load client-only mods only on the client and server-only mods only on the server.

I got things setup for the client and it works in singleplayer. I use git version control in my .minecraft/ directory, and I cloned the repository into my server environment (I have lots of things ignored, I basically just sync datapacks and mods. I've been doing this for months, just separating server/client mods manually. The usage of git is not the issue. )

For the server, I get a crash during startup, this is the console output.

Could not create directory .\mods\.\mods\OPTIONAL in the console prompted me to create the directory mods/mods/, and sure enough the game starts up if that exists, and any directories of selected rule options are created.

{
  "id": "a-rule",
  "type": "DEFINED",
  
  "caption": "Switch: %s",
  
  "options": [
    {
      "id": "off",
      "caption": "Off",
      "directories": [ ]
    },
    {
      "id": "on",
      "caption": "On",
      "isDefault": true,
      "directories": [ "a-mod" ]
    }
  ]
}

to

{
  "id": "a-rule",
  "type": "BOOLEAN",
  "caption": "Switch: %s",
  "switchText": [ "On", "Off" ],
  "default": true,
  "directories": [ "a-mod" ] 
}

This would also be useful when/if #21 is introduced.