Setting the "text_opacity" NBT tag in an item display entity to anything less than 4 seemingly renders its text's opacity as 255, and setting it to 4-25 seems to render the text as completely invisible.
Steps to reproduce:
Summon a text display:
/summon text_display ~ ~1.5 ~ {text:'"Text"'}
Set its opacity to something low but still visible:
/data merge entity @e[type=text_display,limit=1] {text_opacity:26b}
Lower it by 1 down to 25:
/data merge entity @e[type=text_display,limit=1] {text_opacity:25b}
Notice the text is now completely invisible.
Set it to 1 where it should barely be visible:
/data merge entity @e[type=text_display,limit=1] {text_opacity:1b}
Notice the text is fully visible.
Linked issues
is duplicated by 1
Attachments
Comments 8
Alpha of 4-25 being invisible is due to how core shaders for text are designed.
If you remove the following code from all text shaders, it will be visible and have the proper opacity. As such, this part of the bug is likely WAI.
if (color.a < 0.1) {
discard;
}You can test this using the attached resource pack https://bugs.mojang.com/secure/attachment/522368/RemoveTextDisplayAlphaDiscard.zip
On the other hand, text_opacity values 0 to 3 still render fully visible. This range of values may be a bug...
Values from -128 to -1 render fully visible, but this is probably undefined behavior and WAI.
The reason why the default value is -1 is that the game uses byte type for text_opacity field and therefore the default value, 255, is overflowed to -1.
Because of this, value between -128 and -1 should work like opacity 128~255, and it does work like that when I test it.
Very annoying with text_display entity interpolation as it doesn’t know how to work around the way this value is stored
Still present in 1.21.4
Update as of 26.3.
Opacity values 0-3 now appear to be completely invisible (so parts of this issue have been resolved).
However, it still interpolates in the wrong direction when going from 127 or below to 128 or above and vice versa (128 is stored as -128, causing it to go the other way around when interpolating). Simply adding 256 to any negative numbers before passing them to the `LinearIntInterpolator` would probably solve that part.
Can confirm.