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.

I did further testing last night and found that this isn't consistently reproducible. Sometimes it happens, sometimes it doesn't, and I haven't yet narrowed down any additional factors.

In either case, the sign text will disappear entirely when the chunk reloads (see REALMS-9191).

The net result is that signs are useless on Realms in 1.17. If you can get them to display text at all, never mind display them with the desired formatting, they will go blank the next time you leave the area or log out.

Still occurring in 1.17.40. Text may not disappear immediately, but disappears once the chunk reloads (e.g., from traveling far enough away from the sign, or from all players logging out of the realm).

This is slightly different, but still broken, in 1.17.40.

Signs containing only words now retain manually-entered line breaks as expected.

However, signs containing color formatting codes and/or non-word characters continue to behave as if the user didn't enter any carriage returns at all.

To reproduce:

Create a sign with the text: 

§f-->
§bTunnel 1 East
§fTown 1
§fTown 2

Expected result:

The sign has four lines. The first, third, and fourth lines are white; the second is cyan. This was the behavior prior to 1.17.

Actual result:

The sign appears with the color formatting but without the user-entered line breaks. (In 1.17.30, the sign would appear without the line breaks and without the color formatting, as if the § character was simply omitted.)

We found that the unplayable lag went away almost completely after we all stopped playing on the realm completely for 2-4 weeks. The realm worked without any undue lag, regardless of player load, for a few months thereafter (right up until 1.17.30, which broke Realms in so many other ways as well).

Since the problem persisted across server version upgrades, I don't think the issue was due to a memory leak / long uptime for the server instance. If so, I would've expected improvement after a server version upgrade.

It makes me wonder if the issue is related to specific server hardware instances; possibly, discontinuing use of the realm for several weeks causes it to be stopped and later migrated to another server when accessed again? That sort of thing happens with cloud services, and would explain the results we saw.

Under 1.17.3x, we're seeing some lag, but not as bad as when I originally reported this. Occasionally, block drops are delayed. This is particularly noticeable when mining deepslate coal; when doing so, blocks frequently disappear and then reappear instantly. Travel by minecart is generally smooth, with only minor "hitches" that are barely noticeable. (Before our break, minecart travel would routinely pause for half a second or more every few seconds, frequently resulting in minecart travel being slower than walking speed.)

I've seen this frequently. Often, text formatted a specific color will be censored, but will not be censored if left unformatted or if formatted with a different color. For example, I've frequently found

§cDANGER

gets censored, but other variants, like

§4DANGER

or

§c! Danger !

may not be censored. (Or the censorship may apply to some of the other variants, but not the first example. It seems random.) The other content of the sign may also impact whether or not this censorship occurs, so the individual examples above aren't directly reproducible.

It's as if the censorship mechanism isn't using a text comparison, but some sort of hash algorithm that has way too many collisions in its output space. Sometimes, adding or removing a single character to the sign will be enough to cause it to render without censorship. Most times, changing or omitting color codes will prevent unexpected censorship.

It appears to me that signs are retaining their formatting in 1.17.32... until you move to another chunk and the text disappears entirely when you return. Since that's not exactly the issue reported here, I opened MCPE-143812 to track it. I found a similar (but not identical) report from a BDS user, hence using the MCPE project instead of REALMS.

I'm seeing similar results to @Drew Kaplan, except with cartography tables. I believe this is a different aspect of the same bug.

Since this appears to be an issue with delayed data synchronization generally, it makes me wonder if it's related to REALMS-9078, where realms seem to occasionally stop synchronizing with clients.

Steps to Reproduce:

1. Place a map with a default name (e.g., "map 79") in the input slot of a cartography table. (In my case, a locator map at x4 resolution.)

2. Observe that the action prompt confirms that you're going to rename the map.

3. Type a new name for the map.

4. Drag the renamed map from the output slot to your inventory.

5. Hover the pointer over the map in your inventory.

Expected result:

**The map immediately reflects its new name in the hover-over tooltip text.

Actual result:

The map retains its original name, but if you check again after a brief delay (several seconds to a few minutes) it will show the correct, new name.

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.

Also happens on Realms, and happens even with 1.17.32 (Xbox).

There may be a deeper issue with signs, possibly related to 1.17.30's changes to text handling generally. I noticed in the release notes: "Unicode font now correctly highlights on Signs with glowing text (MCPE-130072)"

I also noticed a different behavior last night, that I suspect may be related to this issue. I'm wondering if both issues are bugs related to Unicode parsing and thus that bug fix. That other issue is that while a sign that contains color codes and carriage returns looks correct immediately upon placement, if one leaves and returns (causing the chunk to reload), the sign renders as if the user hadn't entered any carriage returns, messing up the layout and the coloring. (See MCPE-143813). 

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.

Likewise seeing issue with application of any dye. 

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.

The problem is even worse on 1.16.210.

With 1.16.200, the severity of the issue seemed to vary from day to day. Occasionally, logging out of the realm and then reconnecting a few minutes later (such as after a bathroom break) would improve the problem. Sometimes the improvement was brief, sometimes it was long-lasting.

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