Low-Drag-MC / LDLib-MultiLoader

GNU General Public License v3.0
12 stars 14 forks source link

LDLib Makes Multiple `BlockState`s Use the Same `ModelResourceLocation` #9

Closed PepperCode1 closed 1 year ago

PepperCode1 commented 1 year ago

LDLib makes all BlockStates of all Blocks that implement IBlockRendererProvider use the same ModelResourceLocation (relevant mixin).

In vanilla, calling BlockModelShaper#stateToModelLocation with two different BlockState will never return ModelResourceLocations that are equal (using the #equals method). Continuity uses this assumption to construct an ImmutableMap<ModelResourceLocation, BlockState> to map ModelResourceLocations back to BlockStates during model baking to perform a certain optimization. During construction, the ImmutableMap encounters duplicate keys and throws an error, which causes more issues. Relevant Continuity issue: PepperCode1/Continuity#303. This compatibility issue only occurs with Continuity versions for Minecraft 1.19.3 or newer.

Is it possible to remove the aforementioned mixin and uphold the vanilla assumption? I understand the purpose of the mixin is to make it so those blocks automatically use the same model without requiring a lot of unnecessary blockstate files, but there must be a different way to accomplish this without changing the ModelResourceLocations.

Yefancy commented 1 year ago

I will try it later. btw does it only happen in the 1.19.3+

Yefancy commented 1 year ago

Btw, can you make your map accept the same key? I also want to reduce the mapping. One of its user -- the GregTech has massive blocks are using it. it would be better to avoid unnecessary mapping, tbh.

PepperCode1 commented 1 year ago

Btw, can you make your map accept the same key? I also want to reduce the mapping. One of its user -- the GregTech has massive blocks are using it. it would be better to avoid unnecessary mapping, tbh.

No. It is impossible for Continuity to apply the optimization to models of block states of blocks that implement IBlockRendererProvider with how LDLib works currently. If you do not want to change LDLib's behavior, this issue should be closed, but it would be good if LDLib matched vanilla.

Yefancy commented 1 year ago

fine I will fix it later.