ExamineCat

A year later still an issue on 1.21.80.

See the attached screenshots. Online player profile pictures are as expected, but notice how offline players have their profile pictures mismatched from what their actual Xbox profile pictures are. I show at least two whose profile picture on Xbox does not match what Minecraft shows, though you can see others have profile pictures on Minecraft that are from other Xbox users.

This still affects 1.20.51. Have various friends on Xbox Live, open up your Minecraft world, check the invite list. Notice that offline players have their avatars switched in-game compared to their actual avatars on Xbox. The names are correct, it's the avatars that are wrong.

Affects the latest beta and preview 1.20.60.26

Affects the latest beta and preview 1.20.60.26

Affects 1.20.51.

Ok so loading up a .mcworld from prior to 1.16.220, the signs are as they should be; however, new signs continue to be darker than their UI counterpart. This is as of 1.20.51.

Latest preview is 1.20.10.23 (my bad in the earlier comment), still affected

Affects the latest preview 1.20.10.21

This is still an issue affecting 1.20.

Steps to reproduce:

1. Build a wall of honey blocks to slide by, similar to the one in the screenshot attached below.

2. Try sliding across it, like in the video attached below.

^{Observed Results: Player does not slide across the honey blocks like on Java.}

^{Expected Results: Player should be able to slide across the honey blocks like on Java as evidenced in the video attached below.}

More examples:

^{Minecraft Honey Block Parkour (1.15)
Minecraft Quick Tip: Wall-Running With Honey Blocks}

^{HONEY BLOCK PARKOUR!}

1.20 remains affected.

As of checking in 1.19.83 (might've started happening in an earlier update), all signs placed prior to 1.16.220 have now become darkened. Sign UI text when using § is still lighter than the text on the sign. The fix should be to make the colored text on the signs match the colored text on the UI rather than make the UI text darkened as well.

Ok, very well, my bad. Latest release (1.19.50/1.19.51) and latest beta/preview (1.19.60.24) are affected.

It's fixed as of 1.18.30, but now the color on the placed sign is darker than the color on the UI.

The bug is still not fixed as of 1.18.30. When you use a § color code on a sign, the expected color is different than what you actually get.

Steps to reproduce:

1. Place a sign and write text in it using any of the § color codes to color it.

2. Close the sign to see the finished product. Notice that it is a darker color than the text shown when writing the sign.

As of 1.18.12, it still affects custom skin packs.

Can confirm for Android as well.
 

They fixed this in the 1.16.200.56 beta, but well, that is still in beta, so we will have to wait.
 

I can confirm I've experienced this in the full release of 1.16.100.

I have a chain conditional always on command block with /execute @e[type=snowball] ~ ~ ~ spawnpoint @p 986 85 1064

Despite being correctly written, the execute command fails and it is not because it is set to conditional.

It is linked to a repeating unconditional always on command block with /execute @e[type=snowball] ~ ~ ~ replace item entity @p slot.weapon.mainhand 9 snowball

Both commands are written just fine, and they were working just fine before 1.16.100. The first one fails to execute, but the second one is executed successfully.

The command blocks are in a tickingarea, though I doubt this has anything to do here.