JSON Resource feedback

[opekope2]

If you are creating a resource pack, I'd appreciate constructive feedback about the new JSON Resources, if you have any.

Docs: https://opekope2.dev/OptiGUI/JSON.html
Tip: use OptiGUI Inspector (F12 key by default) while a GUI screen is open to generate a JSON Resource with every important detail included. Paste it into a JSON file in the resource pack's assets/<namespace>/optigui/gui folder (any valid namespace is supported, not just optigui as before)

[Vi-Tul]

I downloaded 3.0.0-alpha.3 version for Fabric 1.21. For an hour I tried to change ender chest texture, I couldn't. Can you show an example for ender_chest.json for me to understand, what I was doing wrong?

Also it would be awesome for resourcepack creators to have an automatic conversion tool, from ini to json.

Another thing is that lots of people download latest version of OptiGUI without looking into it and than complain in resourcepack's comments about textures now working. Can you add backwards compatiblility for alpha versions or at least state in the beginning of changlog that it's not for everyday users

[opekope2]

Imagine not having the attention span to read the Important section 💀. 85k+ downloads for a pre-release is crazy. I moved the important part to the top of the changelog and added some ⚠️ emojis ⚠️ around it.

Support for OptiFine properties and OptiGUI INI files will be re-added in the upcoming releases.

---

If you press F12, OptiGUI Inspector will copy a JSON to your clipboard like this, which dumps everything that can be matched against:

{
  "generated_by": "OptiGUI 3.0.0-alpha.3+fabric.1.21",
  "docs": "https://opekope2.dev/OptiGUI/JSON.html",
  "containers": "minecraft:ender_chest",
  "textures": {
    "minecraft:textures/gui/container/generic_54.png": "example:path/to/changed/texture.png"
  },
  "if": {
    // ...
  },
  "match": {
    // ...
  }
}

You can remove the unnecessary things from it. It has a link to the docs, which says that JSON files are loaded from a resource pack's assets/<namespace>/optigui/gui folder.

Can you tell me what causes misunderstanding, so I can try to make the docs or OptiGUI better?

---

Example resource pack file structure:

assets
└─example
  └─optigui
    └─gui
      ├─ender_chest.json
      └─ender_chest.png

For this, the ID of ender_chest.png is example:optigui/gui/ender_chest.png, so you need to replace example:path/to/changed/texture.png with it:

"textures": {
  "minecraft:textures/gui/container/generic_54.png": "example:path/to/changed/texture.png"
}

[AmongstReality]

There's actually a real issue with experimental version of the mod being the latest update.

I was doing something and I needed a separate instance of Minecraft 1.20.1. I created it using Modrinth App and installed OptiGUI. I launched the game and the resource pack was not working as intended. Well, I investigated and turns out Modrinth App installs the latest version of the mod, even though it's an alpha.

This is one of many reasons why this experimental version of the mod has more than 70k downloads. A lot of people use Modrinth App, or maybe some other launcher, to install mods and since they download the latest version, people download the mod and then complain to resource pack authors about their resource pack not working. It's not just attention span problems.

[opekope2]

This is clearly an anomaly rather than attention span that there are way more Modrinth downloads than CurseForge.
I manually re-released OptiGUI 2.3.0 beta 6 as a hotfix for this issue.
I also manually featured the "original" beta 6 releases (there weren't any featured versions) so I can check which version is downloaded by Modrinth app.

[Vi-Tul]

I moved the important part to the top of the changelog and added some ⚠️ emojis ⚠️ around it.

I manually re-released OptiGUI 2.3.0 beta 6 as a hotfix for this issue.

Thank you, now most of the people will use the right version

Can you tell me what causes misunderstanding, so I can try to make the docs or OptiGUI better?

Well, I found out why textures weren't working - I assumed that for "assets/namespace/optigui/gui" file location "namespace" was optional, so I did everything in "assets/optigui/gui", as it was prior to 3.0 version.

[Vi-Tul]

Found an issue with this json format.
Example: I want to make different textures for llamas' GUIs for every colour of equipped carpet. In colour.json I check if in "@body_armor_item" is a specific colour of carpet:

{ 
   "match": {
      "@entity": {
         "@body_armor_item": {
            "@id": "minecraft:orange_carpet"
         }
      }
   }
}

The problem is that if carpet is not equipped, there is no "@body_armor_item" in "@entity", so there is way to check for carpet existence. And without "@body_armor_item" OptiGUI prioritizes texture for no carpet variant even when carpet is equipped.
I tried this, but it doesn't work:

{ 
   "match": {
      "@entity": {
         "#none": {
            "=": "@body_armor_item"
         }
      }
   }
}

Can you show me how to achieve the desired result, if it even possible?

[opekope2]

From the docs:

OptiGUI loads .json files from a resource pack's assets/<namespace>/optigui/gui folder, including its subfolders in any depth. The namespace can be anything as long as it's valid, not just optigui.

---

#none in your example checks if @entity (the llama) is an NBT list, and none of its elements is the NBT string @body_armor_items

The absence of an NBT tag can be checked using this tip:

{
  "match": {
    "@entity": {
      "none_of": [               // Invert matcher (check if child NBT tag `body_armor_item` is not present)
        {
          "@body_armor_item": {} // Check if child NBT tag `body_armor_item` is present
        }
      ]
    }
  }
}

I didn't add none as I feel like it's redundant, but it could make resource packs more readable, so I'll reconsider it. It would look like this:

// This will not work in OptiGUI 3 alpha 3
{
  "match": {
    "@entity": {
      "not": {                 // Invert matcher
        "@body_armor_item": {} // Check for the presence of `body_armor_item`
      }
    }
  }
}

[Vi-Tul]

Thank you for your help, now it's working properly!

[MiniTheMB]

Hi. Whenever I use the inspector, it gives me this:

# Generated by OptiGUI Inspector

# You may not need all selectors
[minecraft:chest]
biomes=minecraft:desert
chest.large=true
comparator.output=0
date= //ofc redacted
heights=56
interaction.hand=main_hand
interaction.texture=minecraft:textures/gui/container/generic_54.png
name=Treasure Chest
player.biomes=minecraft:desert
player.heights=56
player.name=Mini_The_MB

# NBT (for more detailed inspection purposes, as there is no selector for NBT):
# {Items:[]}

# If you have an idea or feedback about the inspector, feel free to share it at
# https://github.com/opekope2/OptiGUI/issues/72

I can't find any documents regarding translating this into a regular .json format, and the ID's used doesn't match either ("interaction.texture" isn't mentioned anywhere at all.)

I did try to make something basic, like this:

{
    "containers": "minecraft:chest",
    "textures": {
        "minecraft:gui/container/generic_54.png": "cc:optigui/treasure_chest.png"
    }
}

hoping it would at least constantly replace the texture to "treasure_chest.png", but it doesn't work either.

[opekope2]

Seems like you forgot to enter the full path of the original texture:

- minecraft:gui/container/generic_54.png
+ minecraft:textures/gui/container/generic_54.png

---

OptiGUI 3 inspector generates a JSON resource. I will add a resource pack converter, which will do the conversion automatically.

INI files support changing only a single texture — this is specified by interaction.texture.
JSON files allow changing multiple textures, specified in textures (sprites are also supported, but it's buggy as of alpha 3).

[opekope2]

Would reusable JSON macros be useful? It's more trouble implementing it than not, and vanilla NBT is not very deep (other than maybe written books and text components)

// assets/example/optigui/macro/villager.json
{
  "@entity": {
    "@VillagerData": {
      "@profession": {
        "=€": ["#input", "@prof"] // minecraft:cleric
      },
      "@level": {
        "€": ["#input", "@lvl"] // >=2, <5
      }
    }
  }
}

// assets/example/optigui/gui/cleric.json
{
  // containers, textures, ...
  "match": {
    "€example:villager": {
      "prof": "minecraft:cleric",
      "lvl": {
        ">=": 2,
        "<": 5
      }
    }
  }
}

[Vi-Tul]

Would reusable JSON macros be useful?

Well, in my opinion, not really. Don't get me wrong, this feature would be great to have, but I'm afraid that it would be too niche and maybe not worth the effort. I think for newcomers this can be a bit too complicated, more advanced creators can easily make a script that generates json file with needed parameters.

[opekope2]

For the next version of the JSON resource, I plan to make some additions and changes to make it more versatile. Here's a sneak peek, I may make some changes before releasing it. Any feedback and feature request is welcome.

• Split containers to blocks, entities, items, and inventory
  • Introduce unknown for previously unsupported screens (not initiated by client action)
• Split textures to change_textures and change_sprites
  • Add weighted random replacement textures
  • Relative replacement textures (./replacement.png)
• Compare NBT with another one (like the player is below the interacted block)
  • For more advanced calculations (like the player is at least 3 blocks below the interacted block), I could easily add a way to do math. I don't expect this to be used often, but could be helpful for specific use cases
  • I don't think that dynamically getting the regex for example would be useful, and it would have an impact on performance
• Change the style of any displayed text

This could be useful, but I'm not sure if people are going to use it.

• Draw extra textures/sprites/text on the screen in addition to changing existing ones

[opekope2]

Because of some refactoring, #none, #any, #some, and #all can no longer be prefixed with #, but these will gain the ability to match the values of an NBT compound, not just the elements of an NBT list.

This change hasn't yet been released.

I believe just using none, any, some, and all (without the # prefix) would be confusing and not descriptive enough, but none_of_list, any_of_list, some_of_list, and all_of_list would suggest that NBT compounds are not supported.
no_elements, any_elements, some_elements, and all_elements sounds better, but it may not tell the resource pack creator which part of the NBT compound it tests (as a developer, a map has a list of keys, a list of values, and a list of key-value-pairs, hence why I believe it's confusing).

If you have some better name ideas, go ahead, and enlighten me.

[opekope2]

Sneak peek of the upcoming OptiGUI Debugger and some new JSON features: