Closed PepperCode1 closed 1 year ago
I will try it later. btw does it only happen in the 1.19.3+
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.
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.
fine I will fix it later.
LDLib makes all
BlockState
s of allBlock
s that implementIBlockRendererProvider
use the sameModelResourceLocation
(relevant mixin).In vanilla, calling
BlockModelShaper#stateToModelLocation
with two differentBlockState
will never returnModelResourceLocation
s that are equal (using the#equals
method). Continuity uses this assumption to construct anImmutableMap<ModelResourceLocation, BlockState>
to mapModelResourceLocation
s back toBlockState
s during model baking to perform a certain optimization. During construction, theImmutableMap
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 theModelResourceLocation
s.