container variations GUI from other mods
dadoirie opened this issue · 30 comments
I'm wondering how to show GUI variations for modded containers like Variant Barrels & More Chest Variants
Press F3+H to show advanced item tooltips.
You see an ID under the item's name (formatted modid:item_id, colored blue iirc), it should be placed inside the brackets ([modid:item_id]). Additionally, the interaction.texture needs to be specific, because OptiGUI only knows vanilla containers' default textures.
An inspector will be added in the 2.2.0 release (or a pre-release), which will tell you these details.
not sure that I can completely follow here: "Additionally, the interaction.texture needs to be specific"
Also I am a resourcepack newbie and not a modder, that been said I don't know if those mods need to have a OptiGUI compatibility coded in them or does OptiGUI handle this?
What I'm missing here? As said - not getting what you mean with "the interaction.texture needs to be specific"
[lolmcv:bamboo_chest]
replacement=./bamboo.png
what I'm doing wrong here:
tried both folder namespaces
with
[lolmcv:bamboo_chest]
interaction.texture=minecraft:textures/gui/container/generic_54.png
replacement=./bamboo.png
Your last snippet looks right, I know why it doesn't work.
A small amount of code is needed to connect the two mods. It can be done on either OptiGUI side or the other side.
The current codebase makes it quite simple to add this. I'll add it to OptiGUI in some way in 2.2.0.
If you find other custom container mod, let me know in another issue, so I can add support for them.
I got MCV working with my modified resource pack. The code is not yet upstream.
yay - can't wait for it 🥇
snipped is right?
[lolmcv:bamboo_chest]
interaction.texture=minecraft:textures/gui/container/generic_54.png
replacement=bamboo_chest.png
Yep, except interaction.texture won't be required
and each mod which adds containers needs additional compatibility or is that also taken care of?
For simple mods (like MCV), only a couple lines of code is needed, which processes the block entity (OptiGUI can only process vanilla block entities by default).
For completely new container, which add other properties (for example, a color or variant), it will need a selector (like myblock.color) and an interface+implementation containing it implemented in OptiGUI. I'll work on selector extensibility.
This code can be added to either the other mod or OptiGUI (open a PR if you find such a mod, and I'll probably make it compatible... eventually).
I can't reference any code or docs because I haven't pushed them yet.
then for now please add compatibility for MCV and the Variant Barrels ... or Variant Vanilla Blocks which has basically the crafting tables, grindstones, barrels, cartography tables, smithing tables & smokers ... actually (also don't wanna come over like requesting features and compatibilities) since I'm no modder and have some basic knowledge of Javascript (meaning I can read and modify code - I've also once successfully extracted a mods single functionality which also worked as a standalone mini mod) and if I get some examples (meaning if it's one file where I just need to rename some references) I'd look into it adding the Variant Vanilla Blocks which are using the vanilla GUI of the corresponded container.
I still have to find a good way to automatically test core functionality, and I have many ideas to implement in the next release. Compatibly is just one thing I'm working on. I'll eventually get there.
I just took a look at variant barrels
There are more variant mods to support
Will take some time
(also blaming the slow development pace on gradle)
Whoops
That's why I don't usually push individual commits
why?
Because I can fix things if I miss something and I don't need to add a new commit or force push
from the creator of Variant Barrels & Variant Vanilla Block: Variant Chests
hello, i just stumbled across this while trying to do something similar for the farmer's delight cabinets, giving them each a different texture depending on the wood type, and if i understand this correctly this wouldn't be possible at the current time. so could i suggest that that could be looked into in the future?
I'll open a PR in it, when I release OptiGUI 2.2.0. The first alpha build contains the API, which may be refined later on.
It's been quiet here, because I went on to implement the Toast abstraction into LiLaC, then I did university things, and now I develop Staff Mod. If I'm lucky, I'll get this done by Minecraft 1.21, but no promises. Yes, I'm still alive.
I'm trying to add support for quark's variant chests but it doesn't work.
This is how I'm doing:
[quark:acacia_chest]
interaction.texture = minecraft:textures/gui/container/generic_54.png
replacement = assets/quark/acacia_chest.png
[chest quark:ancient_chest]
interaction.texture = minecraft:textures/gui/container/generic_54.png
replacement = assets/quark/ancient_chest.png
None works
What am I doing wrong?
If the INI file is at assets/optigui/gui/whatever.ini, OptiGUI looks for the replacement texture at assets/optigui/gui/assets/quark/acacia_chest.png, because you specified a relative path. If the replacement texture is at assets/quark/acacia_chest.png, quark:acacia_chest.png should be specified as replacement.
Wait, so the replacement is the target texture that I want to change?
The texture I made to replace quark's is at "assets/optigui/gui/assets/quark/acacia_chest.png".
Can you give me an example how to properly do it?
Nope, OptiGUI looks for the replacement in the loaded resource packs. I assumed you placed the resources in the wrong folder, so your example looks correct, if every file is in the right place.
If OptiGUI can't find the replacement while loading resource packs, it will log a warning in the game's console to let you know:
I will eventually add an in-game GUI for this.
interaction.texture tells OptiGUI what the original texture is. This is optional for vanilla containers, because OptiGUI knows their original texture.
replacement tells OptiGUI what to replace it with.
For that texture, the absolute path (ID) is optigui:gui/assets/quark/acacia_chest.png, or you can use a relative path starting at the INI file's folder.
The support for other mods is very basic and not very well-tested, so it could be an OptiGUI issue, but it got better in 2.3.0-alpha.1.
The problem seems to be with the target.
The "[chest quark:ancient_chest]" actually changed the vanilla chest texture, then I tested some textures with the vanilla chest and everything worked, the problem seems to be the "[quark:acacia_chest]".
Looking at the "latest.log" the only reference to optigui load failure is with the "desktop.ini".
Maybe creating a single .ini file for each chest works? Right now I'm using a single .ini to change a bunch of things (vanilla chests, villagers, shulkers and more).
Are you running OptiGUI 2.1.x on Sinytra?
Yes
Then ignore what I said, it's about OptiGUI 2.3.0.
OptiGUI 2.1.x is an ancient codebase, it requires a preprocessor to be registered for each block entity class. This preprocessor was removed in 2.3.0-alpha.1 for simplicity and better compatibility.
Sinytra is not tested at all.
Is 2.3.0-alpha.1 compatible with 1.20.1?
I could test it!
Not yet, but I will backport to 1.20.1 after the full release (because OptiGUI 2.3.0+ will not be a universal JAR to support 1.18-1.21)
I will try and test some things on newer versions, so when the backport drops, I can compare and test.