![[Mojang] Billy Sjöberg](../../../data/avatars/users/42806.png)
[Mojang] Billy Sjöberg
- billy.sjoberg
- billy.sjoberg
- Europe/Stockholm
- Yes
- No
MC-197156![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
Low
![[Mod] tryashtar](../../../data/avatars/users/41963.png){kind=small}
![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
[Mojang] Billy Sjöberg[Mojang] Billy Sjöbergrelates to
relates to
[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg![[Mojang] Timur Nazarov](../../../data/avatars/users/18945.svg){kind=small}
[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöbergduplicates
MC-177400
[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg![[Mojang] Gnembon](../../../data/avatars/users/93709.png){kind=small}
[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg![[Mojang] Markus Gustavsson](../../../data/avatars/users/80677.png){kind=small}
[Mojang] Markus Gustavsson[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Markus Gustavsson[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg
Normal[Mojang] Billy Sjöberg[Mojang] Billy Sjöberg![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
[Mojang] Billy SjöbergI can confirm this in 1.19.2 though I'm inclined to believe that this behavior is working as intended judging by the following comment made by [Mojang] Billy Sjöberg on MC-197156 where they state that empty main hand interactions take precedence over offhand interactions.
Closing this as "working as intended". We had a discussion about this internally and the reason for this behavior is that empty main hand interaction (riding) is a valid interaction which takes precedence.
This unfortunately means interacting with horses is different than i.e pigs who does not have a valid empty main hand interaction.
This issue was discovered when testing MCPE-178015
Relates to MC-263062
[Mojang] Billy Sjöberg said, the block doesn't fall until a neighboring block is updated.
When the sand or gravel is generated floating it never falls no matter how many random gameticks pass.
However, when the suspicious sand or gravel is generated floating it will fall after some random gameticks which is also different from Java Edition
Analysis
Here is a video that shows the issue MCPE-178020.mp4
| Sand generated floating | Sand suspicious generated floating | Gravel generated floating | Gravel suspicious generated floating |
|---|---|---|---|
not fall  |
fall  |
not fall |
fall |
Steps to reproduce:
- Import world ( Suspicious gravel and sand bug.mcworld ) and enter
- teleport in coord
/tp -416 66 -205
- Wait two minutes
Observed behavior:
Gravel and sand suspicious block, falling when passing some random gameticks
Expected behavior:
Gravel and sand suspicious block, never falling when passing some random gameticks
Thank you both for the excellent and highly valuable report and suggestions.
I'll take a closer look at the world + improvements and get back to you asap.
Seems to work as intended. Please reopen with a repro if you experience it again.
The8BitMonkey would you mind uploading your world?
I've failed to reproduce this on 20w18a snapshot even using the exact same cage you built and with both less and more combinations of golems / pillagers.
Seems to have been fixed by
MC-188088The8BitMonkey Just a reminder to send the world for testing. As much as I'd hate to we would otherwise need to resolve this as a no-repro, but I'd love to try out on your world first.
Could well be, but I cannot reproduce the lag the reporter is seeing. We've done a few optimizations to the pathfinding recently which could help out a bit, but I failed to repro even on the 20w18a snapshot was reported on.
That's why I'm interested in seeing the world to see if any of the recent changes we've made fixes this or if we need to do more.
Awesome, will take a look at this today. Thanks for your report!
So I think I got the hang of this. Apparently the pillagers doesn't see the Iron Golem through the fence which in itself is a bit of problem. They could obviously see it at some point in time, otherwise they would not be able to obtain their target.
What this leads to is constant pathfinding trying to get closer to the golem every tick causing the lag.
The quick fix to this is to limit the number of path updates, but in the long run we'd also like to take a look at both the Pillager AI here as well as why they can't see through the fences.
Thanks The8BitMonkey for the detailed report and sending your world!
Erik Gahlin this is extremely valuable feedback. Thanks for sharing and we will address the issues you pointed out.
Happy to hear you're as exited about using the combination of Minecraft and JFR as we are
Thanks all.
This is a known issue when saving ticking blocks and liquids that should be at least somewhat mitigated by a fix in 21w43a snapshot.
Would you mind trying the latest snapshot and comparing the save time duration?
Thanks for the report. This is WAI since it's a command used on both client and server.
Also, since there are no sensible defaults for how to open .jfr files a clipbboard copy makes more sense.
Does this still affect 1.18.1? If so, could you please provide the game log output?
Sam could you please provide more logs for your attempts with Java 17.0.2?
Not only the crash log from the launcher, but also the game logs under /logs as well as crash reports under /crash-reports.
It seems you're experiencing a set of few different crashes. Your latest update (edit 4) is a duplicate of
MC-247871, which is a separate game related concurrency issue we're also investigating. This crash should hopefully be fixed in the latest snapshot (22w06a) so please let us know if you still experience the crash fromMC-247871in the snapshot.For future reference, please first check if there are existing similar open bugs rather than adding on to an existing one with new crash cases. If not, open a new bug report.
It helps our job tremendously if there's only one bug per case rather than several bumped into one.
Snapshot 22W06A contains a potential fix for this issue and we haven't noticed crashes of this bug yet.
If anyone has a recent repro please leave a comment, otherwise we'll mark this as fixed.
Fannic64 I've been trying to reproduce this without luck. Could you upload the affected world and coordinates so we can do some thorough profiling on it?
It appears we managed to fix this in 22w06a since no new crashes has been observed.
Joshua The profiling log was very helpful, thanks for attaching it. There definitely seems to be something weird going on in the Nether chunk loading.
Would you mind attaching the world and optionally a report from JFR as well? You can trigger one using the `/jfr start` command.
Closing this as "working as intended". We had a discussion about this internally and the reason for this behavior is that empty main hand interaction (riding) is a valid interaction which takes precedence.
This unfortunately means interacting with horses is different than i.e pigs who does not have a valid empty main hand interaction.
After discussing with the platform team it was decided that this is a deliberate corner case and we will not fix it.
The player intentionally chose to bypass version lock and this is not part of normal gameplay.
This was a deliberate design decision since we don't want to destroy the books in it.
We've been discussing this internally and came to the conclusion that consistency with the Chiseled Bookshelf is not the end goal in this particular case.
Fixed as part of fix for
MC-260485The "/item" command cannot remove items within chiseled bookshelves - Jira (mojang.com)Discussed internally and will close this as a WAI.
While this example is a bit unfair to the player since the block is not visible at first sight this is a gameplay feature and the block doesn't fall until a neighboring block is updated.
In the cases where this happens it is still possible to save the block by adding a block below it - so there are at least ways to mitigate it.
If this would happen to a large number of blocks in a structure it could be an issue, but currently the cost outweighs the benefits.
In fixing
MC-275834we're changing the Slime block so that sneaking is the intended way to break the bounce.This means players should not take fall damage when sneaking and bouncing.
Rather than fixing this specific bug, we've chosen to remove fall damage when sneaking and falling on a Slime block, which is now the intended way to stop bouncing.