billysjoberg

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.

In fixing MC-275834 we'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.

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.

Fixed as part of fix for MC-260485 The "/item" command cannot remove items within chiseled bookshelves - Jira (mojang.com)

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.

This was a deliberate design decision since we don't want to destroy the books in it.

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.

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.

@unknown 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.

It appears we managed to fix this in 22w06a since no new crashes has been observed.

@unknown 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?

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.

@unknown 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 from MC-247871 in 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.

Does this still affect 1.18.1? If so, could you please provide the game log output?

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.

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?

@unknown 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 🙂

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 @unknown for the detailed report and sending your world!

Awesome, will take a look at this today. Thanks for your report!

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.