Robert Levandowski

I've seen this happen intermittently since 18.0, particularly after ending a Realms play session on the iOS client and resuming later on Xbox or vice-versa. (It seems to happen more often after playing on iOS, but not exclusively so.)

When I end a play session, my habit is to:

1. Select "Save and Quit" to end the game session

2. Wait for the main menu to finish loading

3. Use the game platform's method to forcibly quit Minecraft, e.g.,

   1. On iOS, long swipe up to the quick-switch screen, then flick the app up and offscreen to force quit

   2. On Xbox, select Minecraft in the quick guide, then press Menu, then select Quit

Why do I do this? Because it's necessary for the Bedrock client to work properly. 

On iOS, if one exits a game session and then starts a new one without first force-quitting the app, audio doesn't work (MCPE-101027). On both platforms, if one exits a game session and allows the app to be backgrounded, the game loses network connectivity and Realms cannot be loaded. The workaround to these longstanding bugs is to forcibly quit the game app after each play session. This has become an ingrained habit over the years.

When this bug triggers, there's a range of oddities that suggest database corruption in the Realm as a result of the bug:

• If the horse was leashed to a post and it disappeared, the lead may still appear attached to the post. (The horse is nowhere to be found, even after diligent searching in the reasonable vicinity.) When breaking the lead, it does not drop.

• Occasionally, a duplicate of the horse can be found wandering unleashed near a location where the player previously leashed the horse earlier in the previous play session.

  • Sometimes, this cloned horse cannot be attached to a lead; apparently, the game still thinks it's leashed to the post on some level, despite it wandering freely. The player can ride the horse and add or remove its saddle and/or armor.

  • Sometimes, multiple duplicates can appear. If this happens, each duplicate will have the same armor and saddle (if equipped), causing item duplication.

  • Duplicate horses may also appear if the horse is killed during normal gameplay. These duplicates may also be "leashed but not leashed."

Possibly related: 

• If the player, having previously had their horse disappear after logging out, takes the following precautions, item duplication can occur:

  1. Leash the horse to a post.

  2. Remove the horse's armor and saddle.

  3. Immediately save and quit the game as per the above procedure.

• In the above case, upon rejoining the Realm and finding that the horse has not disappeared, the player may find that the horse still has the armor and saddle equipped, and the player also has a copy of the armor and saddle in their inventory.

Still occurring in 1.18.2.

We saw this bug, but in at least one instance while playing on a Realm, the boat disappeared for its original user but NOT for another player on the realm. The other player could interact normally with the boat. When the other player broke the boat, picked it up, and then dropped it, the original player could interact with the dropped item again.

Since the last server side hotfix was deployed, our Realm has become unstable. At some point, the server fails to register event data: blocks break but without making the appropriate sound or dropping anything. Water stops flowing. Mobs stop moving. Once one quits, one may be unable to rejoin; typically, trying to do so hangs at the "Loading resources" prompt. When login is again possible, the world has been rolled back at least to the point where event data stopped registering, sometimes further. This occurs on both Xbox and iOS Bedrock clients. It's as if the Realms server hits a point where it can no longer synchronize world state data with the client.

It's not just signs in Korean.

1. ISSUE

Carriage returns in signs are ignored or removed in certain circumstances.

STEPS TO REPRODUCE

1. Create a multi-line sign that has color codes. For example: §f–>
§bTunnel 20 East
§3To Tunnel 12

2. Note that the sign appears as expected when placed.

3. Travel far enough away from the sign that the chunk it's in will be unloaded.

4. Return to the sign.

EXPECTED RESULT

**The sign appears correctly, as it did immediately upon being placed, with the first line being white, the second line being cyan, and the third line being dark cyan.

ACTUAL RESULT

Upon returning, the sign appears as if the user had not entered any carriage returns. The sign contents wrap accordingly. As a result, the color codes are misinterpreted, with the beginnings of subsequent lines rendering in black (default color) as if the user had entered the text as displayed – the color codes are not at the beginnings of the lines as rendered, so the game renders the beginning of the line using the default color.

This issue may be related to MCPE-142788, whereupon applying any dye to a sign causes the sign's text to disappear completely.

Yes, it’s still an issue. Has been with every version since reported.  And the report is already in the requested format. Is anyone actually reading these things…?

When this happens and you are positive you haven't accidentally typed a string of characters that may be seen as a curse word, you can often work around the bug in the curse-word algorithm by slightly altering the sign. For instance, if you are using colored text via § codes, try using a different color, or adding a different color. I have found something as simple as changing --> 

Definitely a problem if you destroy and remake a multicolored sign that's next to another sign using the same color codes. The newly (re)placed sign will have text that's noticeably less luminant than the existing sign, even though it uses the exact same color codes. 

The fact that you now have to consume glowing ink sacs to get the signs to visually match is one problem.

The fact that it's not at all clear how to even apply a glowing ink sac to a multicolored sign (e.g., the apparent need to dye it first) is another problem.

The combination of these two issues creates substantial user confusion and irritation.

Issue is worse in 1.16.210 release, at least when playing on a Realm.

The issue definitely isn't fixed in 1.16.210. If anything, it's worse, at least when playing on a Realm. Playing last night on an Xbox Series X, over a clean 300/30 Mbps Internet connection with open NAT, there was substantial lag of all the types previously reported. The game was far less playable than it was with 1.16.200 lately, and that's saying something.

At least in 1.16.40 (Xbox), the one exception is if the map stored in the shulker box is applicable to the currently-loaded chunk. That map will display its name when you hover over it; any other map in the box that has not yet been viewed by the user by transferring it to their inventory will appear as unknown.

Can be reproduced consistently.

Step to Reproduce

1. Create a firework star with red dye and gunpowder.

2. Create a firework star with red dye, gunpowder, and glowstone powder.

3. Craft firework rockets from the stars.

4. Load fireworks into an upward-facing dispenser.

5. Trigger the dispenser to launch the fireworks. (For example, one might connect the dispenser to a target block through about 10 blocks of redstone dust, to create a target-practice game.)

Expected Results

Both fireworks launch and explode as expected, with the correct effects. The game continues to run normally.

Actual Results

The rocket crafted without glowstone works as expected and the game continues to run.

The rocket crafted with glowstone launches and explodes with the expected effect, but during the crackle animation, the game freezes. Either the underlying OS will detect the freeze and crash the game, or the user will need to manually force-quit the game.

Observed here with fully updated iPad Pro 11" (2020).

If playing using internal speakers and the no-sound condition starts, putting on a pair of already-paired AirPods will result in sound in the AirPods. Taking the AirPods off may not restore sound from the internal speakers.

It seems like this behavior may have been tweaked. Now, it sometimes randomly discards other mats from your inventory. Really fun when you don't notice the game decided to drop your shulker box and it despawns before you go back to look for it. (Or this one time when a passing fox then picked it up and immediately ran through a nether portal...)

To be clear, completely quitting does not fix the issue; it's a workaround for the issue.

A workaround that isn't required for other games published by Microsoft-owned studios, I might add... one would think that Mojang's parent company could assist with whatever code is needed to refresh the main menu networking code upon wake from sleep.

This bug might be related to (but definitely isn't a duplicate of) MCPE-92410.