Bryan Wendlberger
Assigned
Reported
Comments
Playing on latest realms version today, I am still encountering this issue.
Bred horses with 12-14 hearts, gave 2 children, both with 13 hearts. 1 took around ~3 hearts of damage, the other took ~1.
Rode each horse, noted that they had 9 and 12 full hearts respectively, with empty black hearts indicating their max of 13.
Tied up both horses by haystacks, and came back after some time when they should be healed. Instead of being healed, their max hearts had been reduced to match their current (reduced) health.
From this I can conclude that the bug is in your healing code. Horses are simply unable to heal damage properly in the current version, and attempting to do so permanently reduces their stats.
This is still not resolved, and it has never been "invalid". It's still an issue, and it needs to be reopened.
Given that this is still an issue years later, I would really appreciate some official commentary/explanation of the underlying issue.
On the surface, this seems incredibly straightforward to fix without major changes to tick processing order. That is, simply have components remember their previous power state, and always queue an update to invert them during the next tick if they received any update that would have changed their state during the previous tick. I.e. This should just require adding a flag(s) to tile entities and an additional step to the block update logic). Maybe I'm wrong, and this would break other things, or harm performance more significantly than I think. And of course, I can think of other (potentially noncompatible) ways to address it.
In either case, a specific, techically comprehensive, explanation of this years-old and wildly frustrating bug would help set expectations for how this will be managed in the future, and what impact it will have on our clumsy workaround designs when it is eventually fixed.
I understand how it appears to you, but this is neither a duplicate of the other issue, nor a feature request.
This is reporting a significant flaw in the Bedrock code as regards internal error/exception handling. Documenting the current behavior outside of the code itself could serve as a workaround, which is why I left some ambiguity on the exact meaning of "document". However, the actual appropriate place to make the change is in the source, by rendering a different error which "explains" the actual problem to the end user.
This error message does not indicate what the plain text suggests it should, and that is a bug. The permanent solution is more ambiguous, because I cannot read the source. There's more than one possible construct that can create this issue, and resolution depends somewhat on Mojang's build system and internal coding style policies. In other words, it's related to the other issue, but not the same, and I can't be more specific without presuming to tell them how to code it directly. It's 100% a bug though.
This is not invalid, it is an appropriate "bug report", as this "error message" clearly fails to accurately describe the conditions which lead to the error. There is also an obscenely long-unresolved bug which breaks the game, and the resolution of which may depend on this issue.
Community support cannot help, because this analysis requires access to the source code.
This is the appropriate place for this - and the only appropriate place for this. If you have any uncertainty about this, I suggest you escalate to someone who has a better understanding of advanced RCA (Root Cause Analysis).
I am a programmer and highly experienced application support analyst with a special emphasis on RCA. You are getting my expertise for free, because I love the game. I would strongly suggest against blowing off this opportunity to help the hundreds/thousands of individuals who are suffering from the original bug.
Suddenly experiencing this error as of 1.18.31 (have not played for several months prior). The only differences in the console state I am aware of since the last time it worked are more available storage space, and no active XBL Gold subscription.
See also MCPE-156488
This is absolutely still an issue, and an incredibly easy fix, as it only requires a bit-flip during the import process.
May be a duplicate of MCPE-32414
Having imported a survival world and put significant additional time into it before finally exploring further and discovering this undocumented "feature", I cannot easily revert. Nor am I particularly interested in recreating all of my maps from scratch. Given the votes on the previous issue, I'm certain I'm not alone. Given that existing maps are already preserved with their original (technically arbitrary) coordinates, there shouldn't be any reason to force this offset, especially since a flag for the desired behavior ('CenterMapsToOrigin') already exists and works in the current release version.
Experiencing the same issue on Xbox One console. World imported to realms from local game that was itself imported from console edition (Xbox One). Tamed dogs and ocelots still behave as normal, but I cannot make them stand. In addition, my friend tamed a new wolf (after the conversion to realms), and it worked fine at first. However, after she left for the night, I made a mistake and had to restore the world from a backup. This morning, her dog is glitched like mine.
To me this suggests that something in the process of "importing worlds" (perhaps to include restoring backups) is breaking animal ownership.
Understood, my apologies. I guess I just missed the '1' in scanning the date field, and read it as 2023, because I thought this was a recent issue. It's actually on the wrong tracker as well, so I'm opening a new issue. Thanks for catching this.