(fabric 1.19.2) Model's show missing texture when using CTM mod
Ratismal opened this issue · 8 comments
There's a compatability issue with Supplementaries when using the CTM mod.
With certain block models, the block is enveloped by a missing texture block. In these cases, looking inside the missing texture shows the fully intact texture. It seems to be caused by blocks that attach to walls. Other blocks don't have the missing block texture, but still render incorrectly.
Using a wall-mounted lantern as an example:
Video: https://user-images.githubusercontent.com/1059362/193707175-607c25c9-6062-400f-9f86-d645fe6fa770.mp4
Non-exhaustive list of relevant blocks:
- Vanilla Lantern, Soul Lantern (missing texture)
- Silver Lantern, Lead Lantern (missing texture)
- Copper Lantern, Crimson Lantern, Brass Lantern (strange texture surrounding block)
- Hanging Signs (missing texture)
Mod list:
[17:58:45] [main/INFO]: Loading Minecraft 1.19.2 with Fabric Loader 0.14.9
[17:58:45] [main/INFO]: Loading 54 mods:
- ctm 1.0.0+1.19
- fabric-api 0.61.0+1.19.2
- fabric-api-base 0.4.11+e62f51a390 via fabric-api
- fabric-api-lookup-api-v1 1.6.9+9ff28f4090 via fabric-api
- fabric-biome-api-v1 9.0.17+aeb40ebe90 via fabric-api
- fabric-blockrenderlayer-v1 1.1.20+aeb40ebe90 via fabric-api
- fabric-client-tags-api-v1 1.0.1+b35fea8390 via fabric-api
- fabric-command-api-v1 1.2.11+f71b366f90 via fabric-api
- fabric-command-api-v2 2.1.7+0c17ea9690 via fabric-api
- fabric-commands-v0 0.2.28+df3654b390 via fabric-api
- fabric-containers-v0 0.1.34+df3654b390 via fabric-api
- fabric-content-registries-v0 3.3.0+624e468e90 via fabric-api
- fabric-convention-tags-v1 1.1.1+7cd20a1490 via fabric-api
- fabric-crash-report-info-v1 0.2.5+aeb40ebe90 via fabric-api
- fabric-data-generation-api-v1 5.1.9+a680b9b490 via fabric-api
- fabric-dimensions-v1 2.1.31+0dd10df690 via fabric-api
- fabric-entity-events-v1 1.4.18+9ff28f4090 via fabric-api
- fabric-events-interaction-v0 0.4.28+aeb40ebe90 via fabric-api
- fabric-events-lifecycle-v0 0.2.28+df3654b390 via fabric-api
- fabric-game-rule-api-v1 1.0.21+aeb40ebe90 via fabric-api
- fabric-item-api-v1 1.5.7+35a03c4390 via fabric-api
- fabric-item-groups-v0 0.3.29+4e8ca3fd90 via fabric-api
- fabric-key-binding-api-v1 1.0.20+aeb40ebe90 via fabric-api
- fabric-keybindings-v0 0.2.18+df3654b390 via fabric-api
- fabric-lifecycle-events-v1 2.1.2+aeb40ebe90 via fabric-api
- fabric-loot-api-v2 1.1.3+83a8659290 via fabric-api
- fabric-loot-tables-v1 1.1.6+9e7660c690 via fabric-api
- fabric-message-api-v1 5.0.3+176380a290 via fabric-api
- fabric-mining-level-api-v1 2.1.14+33fbc73890 via fabric-api
- fabric-models-v0 0.3.17+aeb40ebe90 via fabric-api
- fabric-networking-api-v1 1.2.4+5eb68ef290 via fabric-api
- fabric-networking-v0 0.3.21+df3654b390 via fabric-api
- fabric-object-builder-api-v1 4.0.11+aeb40ebe90 via fabric-api
- fabric-particles-v1 1.0.10+aeb40ebe90 via fabric-api
- fabric-registry-sync-v0 0.9.25+726b652090 via fabric-api
- fabric-renderer-api-v1 1.0.10+aeb40ebe90 via fabric-api
- fabric-renderer-indigo 0.6.12+aeb40ebe90 via fabric-api
- fabric-renderer-registries-v1 3.2.20+df3654b390 via fabric-api
- fabric-rendering-data-attachment-v1 0.3.14+aeb40ebe90 via fabric-api
- fabric-rendering-fluids-v1 3.0.7+aeb40ebe90 via fabric-api
- fabric-rendering-v0 1.1.22+df3654b390 via fabric-api
- fabric-rendering-v1 1.10.16+aeb40ebe90 via fabric-api
- fabric-resource-conditions-api-v1 2.0.11+e62f51a390 via fabric-api
- fabric-resource-loader-v0 0.6.1+aeb40ebe90 via fabric-api
- fabric-screen-api-v1 1.0.26+f05effaf90 via fabric-api
- fabric-screen-handler-api-v1 1.3.0+1cc24b1b90 via fabric-api
- fabric-textures-v0 1.0.20+aeb40ebe90 via fabric-api
- fabric-transfer-api-v1 2.1.0+8f88597390 via fabric-api
- fabric-transitive-access-wideners-v1 1.3.0+42d99c3290 via fabric-api
- fabricloader 0.14.9
- java 18
- minecraft 1.19.2
- moonlight 1.19.2-2.0.31
- supplementaries 1.19.2-2.2.3
Full log:
2022-10-03-3.log
I did in part look into this and I come back to the conclusion that it is not something I should/could fix. Seems like they are somehow changing model bakery and the models I'm loading always turn into a missing block
It's not on my end obviously. Also if you are using sodium you need rubidium(I think that's what it's called) since sodium alone breaks fabric rendering API and I'm using it
That's kind of a strange response.
Firstly, this is a mod incompatibility issue, meaning that this is an issue on the end of both mods - supplementaries and CTM. Since CTM is a generic connected textures mod, it makes more sense to report the incompatability here in this specific implementation of a mod.
Second, sodium was not mentioned anywhere in this issue. The only mods used are Fabric API, Supplementaries, Moonlight Lib, and CTM, as seen in the mod list. I'm not sure where this comment even came from?
If you are simply unwilling to look into incompatabilities with other mods, that's completely understandable. I can look into this issue on my own, and just wanted to report it for visibilities sake. Hand-waving it as "not my end" comes off as pretty derisive though.
I see. I'll try it out then hopefully it's not something like the similar issue with sodium otherwise like that one I won't be able to fix.
I also notice from the log that it complains that it can't find those models in the data file while I clearly have there
I had a similar issue with Chipped and installing Indium fixed the issue. Have you tried that?
I had a similar issue with Chipped and installing Indium fixed the issue. Have you tried that?
Having the same issue still, Indium did not fix the issue.
I'll add more info i found. I dont know much about how ctm works but it does things different than vanilla and seems to initialize models eariler with different parameters. With my limited understanding i tracked this down to this piece of code which gets send to the unbakedModel getMaterial method instead of what it usually would get (ModelBakery::getModel) https://github.com/CodexAdrian/ConnectedTexturesMod-Fabric/blob/1.19/src/main/java/team/chisel/ctm/client/handler/ModelsAddedCallbackHandler.java#L41
This reuslts in those models somehow geting initialized with an empty parent model instead. This does not happen in vanilla so I'm almost sure issue isnt some of my oversight but due to the internals of CTM itself