mojira.dev

PrismaticVoid

Assigned

No issues.

Reported

MC-278728 smithing_transform recipes can't set an item's components back to default Fixed MC-278626 Dye tints in custom models are invisible in certain contexts Confirmed MC-268094 `execute if blocks` doesn't recognize subcommands after it Duplicate MC-268093 Breaking a decorated pot with an arrow doesn't affect statistics Confirmed MC-251744 Datapacks cannot change sapling growth Fixed MC-235035 Sleeping in a custom dimension with "natural" set to false causes crash Fixed

Comments

I took another look to check the other tint sources. All the other ones all explicitly ignore alpha before passing their color to the renderer. DyeTintSource is the only one that doesn't do that.

Okay so, looking at the code via Loom: It looks like what's happening here is that the top two bytes are read as an alpha, and the calculator I was using to convert hex colors to Minecraft's decimal color format didn't account for this.

The reason it works via the "dyed_color" item component is because that component is hard-coded to set the top two bytes to 0xFF (equivalent to subtracting -12,569,035) specifically to avoid this happening. Changing the default dye color in the above pack to -12569035 fixes the issue while using the exact same color.

Fix would probably be for the dye tint source to apply the same byte-change to its value as well, since there's no way to get a transparent color from applying dye anyway.