Minecraft 1.19.2
Fabric 0.14.24
Lootr 0.4.27.67

Whenever I use my resource pack to try to change the block models of the Lootr barrels to be consistent with my vanilla barrels, they appear invisible. Funny enough, though, that when I don't have Indium installed, they are not invisible but won't change to silver after being opened. This seems similar to #164 considering embeddedt referenced something about the barrel's baked model.

Elements of Lootr chests also appear invisible when I change the block entity model of vanilla chests (probably because they use vanilla chests as a parent) with the Entity Model Features mod.

I totally understand if this is low on the priority list considering I, as someone who knows nothing about coding and maintaining mods, can just opt out of using a 3D model for barrels and EMF for chests. I just wanted to both make my issue known and hope that my suggestions can help make this mod better before it stops receiving updates. Thanks in advance.

Just as an update, please check out #296. I'm not sure if it's related or not.

I've spoken to some of the developers of the Fabric Rendering API (FRAPI) and my hypothesis seems to be incorrect, especially given that it renders correctly in the inventory. I'm unsure if it's related but I'm going to pass this issue on to EMF (if you're still using that).

The barrels were invisible before I started using EMF (I don't use EMF anymore since an EMF update a couple months ago broke something in my resource pack that I didn't feel like working around) and continue to be invisible without any other mods present, so I know it's not that, and I'm not sure where to go from here :/

@noobanidus Hey any updates on this situation? I know it's probably been a long enough while since you've thought about this in any capacity, but I nonetheless wanted to check in and see if there were any recent insights on this

Unfortunately, this isn't something I've been able to get to the bottom of. I'm going to see if I can join a Fabric discord and get some insight from the people there about the issue.

Are you able to send me a copy of your resource pack?

EDIT: I've double-checked my code, and it's possible that, if you are overriding lootr:block/lootr_barrel and lootr:block/lootr_barrel_open, that could be the issue. If you aren't able to send a copy of the resource pack, than a screenshot of your resources might help.

EDIT: Double-chcked your previous message, you appear to be overriding the correct models. I'm really not sure what the issue could be.

EDIT: Again, are you able to confirm that your models work without Sodium and Indium running? I didn't realize Indium was Sodium's implementation of Indigo.

Are you able to send me a copy of your resource pack?

Yes
Salad Test§0.zip

EDIT: Again, are you able to confirm that your models work without Sodium and Indium running? I didn't realize Indium was Sodium's implementation of Indigo.

Yeah I just booted up a testing instance with just REI, Jade, and Lootr, and I can confirm the vanilla barrels show up properly, and the Lootr barrels are invisible, and appear 3D in my hand like shown in my previous messages.
I suppose I could add a new screenshot to verify.

Okay, thanks! This actually helped me resolve the issue.

My code was deficient and only emitted the standard faces (north, south, east, west, up, down, etc), and failed to emit the null face; that works fine with my model, as it's a cube, but for any other complex model, all of the quads are found when querying for the null direction instead.

I'll be getting a release out for 1.20 shortly. I've not generally been doing releases for 1.19, but as this was the version you originally reported it for, were you still using that? If so, I can do an additional release.

Here's a screenshot of it working in 1.20:

I'll be getting a release out for 1.20 shortly. I've not generally been doing releases for 1.19, but as this was the version you originally reported it for, were you still using that? If so, I can do an additional release.

Yeah unfortunately I still have a lot of my must-have mods that haven't been updated to 1.20.1. That's either because of time/effort (which is totally justified. Devs don't owe us updates) or just straight stubbornness for a few of them which is a shame. I'd love to not have to be the person that begs for 1.19.2 support all the time, but I'm just not at the point with my must-haves to update my whole "daily driver" modpack to 1.20.1.

So to answer your question, yes, I would definitely appreciate an additional release for 1.19.2. Thank you so much with all of your help btw. You've been very receptive and helpful :)

Okay, I'm making a release now which hopefully resolves this. I've only back-ported the fixes for the baked model, not all of the other changes that have been made to 1.20.1.

So sorry for the delay in replying to this issue, November was a bit of a hectic time for me and then Christmas/New Year had my internet drop out for two weeks.

I'm going to respond to the issues as far as I understand them:

• Final image, Lootr chest doesn't have the correct textures, or the texture UVs don't appear to be correct: I think you are right in that this is an issue with the changed Vanilla chest model being different. You would most likely need to find a copy of the new Vanilla chest texture and compare it to the Lootr chest texture to ensure that the UVs are in the proper area; you would then probably need to add this to a texture pack for Lootr. The base textures for Lootr can be found in this folder, and are chest.png and chest_opened.png.
• Second image: Lootr uses a custom loader for barrels which specifically provides the lootr:block/lootr_barrel, lootr_barrel_open models by building from lootr:block/lootr_barrel_unopened, etc. I believe that if you want to properly overload the changes between the two barrels, you'd need to override lootr:block/lootr_barrel_unopened, etc, with your new models. You can find the relevant base models in this directory.

Unfortunately, I'm not sure what kind of impact Indium has on baked models; as far as I'm aware, at least in 1.19.0, Lootr is using the correct method for custom baked models such as these.

This issue differs to #164, as that was specifically a failure to include the new "resolve parents" methods that were introduced in 1.19, and was a code issue rather than a texture pack issue.

I hope this information helps, and I'm sorry I can't provide more help with Indium. I'll ask @embeddedt to have a quick look through this.

EDIT: I'm also interested in whether or not this (the blocks being invisible) happens with Indium without the texture pack that you're using.

No worries about the delay. I had honestly forgot about this issue myself with the chaos of the holidays and whatnot.

In response to the question in the edit, I have had no issues with Indium acting weird and it doesn't appear to render anything invisible without my texture pack and/or the new models in it. I should also clarify that this resource pack is of my own making, and I've been teaching myself how to use Blockbench and Aseprite in order to tailor it to what I like, so any issues I run into are on me to solve (Edit: but also no pressure because I'm the only one playing with it).

You were spot on about the UVs being in the wrong areas rendering the lid of the chests invisible, and I have just rectified that particular issue. Despite that being resolved, I'm still not understanding why giving lootr:block/lootr_barrel_unopened (or any of the others: Unopened_Open, Opened, and Opened_Open) a new model turns it invisible.

I even investigated what would happen if I only gave the unopened barrel a 3d model, and it would stop being invisible when I opened it.

Okay, so this makes sense: when the model is loaded, it's loaded in code and it manually pulls in specific models. Then it bakes those quads in the code, and obviously the Fabric loader doesn't support dynamically creating new models for some reason. In theory, there should be a way to fix this, but I'll need to ask around.

Unfortunately, unlike Forge, it's not just a matter of stipulating new models in the file which specifies the loader -- and it appears that the code to re-bake the model isn't fired after a resource pack is loaded...