Nergalic

• Reproduced in Safari on iOS 18.3.2

  • Safari is built into iOS and so follows the same version.

• The issue persists regardless of using WiFi or cellular data.

• The issue persists regardless of using private browsing mode or not.

Reproduced in version 1.21.5, with some changes:

• Run /tick step 17 in step 4.

• Observed PortalCooldown of both minecarts is now 10.

@cmiceli

I can reproduce the bug in Safari on iPhone running iOS 18.0.1

Safari is tied to iOS and is thus identified by the iOS version.

To be clear, the spyglass is just an aid to see the z-fighting.

Here is an example (without a spyglass) from v1.21.1:

!2024-08-31_17.27.24.png|width=630!

There is no "crash-reports" directory in my "minecraft" directory.
The crash report I attached is the one the launcher directed me to with its "view crash report" button.

On macOS minecraft files are located here, by the way:
/Users/Nergalic/Library/Application Support/minecraft

Hi Hadys3

It is the crash report that I have attached.
The minecraft log file itself only contains three lines, being rather unhelpful:

[^latest.log]

[13:52:00] [Render thread/INFO]: Setting user: Nergalic
[13:52:03] [Render thread/INFO]: Backend library: LWJGL version 3.2.1 build 12
[13:52:05] [Render thread/INFO]: Reloading ResourceManager: Default

This frequently happens when I start Minecraft (on macOS v10.14.5).
I have not been able to figure out under which conditions it occurs, meaning I cannot reproduce it.
When it does occur I can resolve the double-click part by switching in and out of Minecraft.

Since 1.14 came out however, whenever I experience the double-click bug in the menus, another bug accompanies it inside the game: If I ever press "a" while writing text, such as in the chat, the entirety of what I have written gets deleted.

The only work-around I have found is to restart Minecraft until I do not experience the double-click bug in the menus.

Probably relates to MC-150548, if not the same.

I have also observed this (in a XP farm), running v1.14.1.

Can confirm that this bug still is present as of v1.14.1.

Simpler ways to reproduce:

• Walk towards the bed as you enter it and you will slide slightly, becoming misaligned.

• Sprint towards the bed as you enter it and you will slide even more.

• Sprint towards the side of the bed under the Speed II effect and you will slide out of the bed.

I think the same behavior is what is causing the Villagers to become misaligned when they go to sleep.

In 1.14 I am experiencing this with beds as well (MC-150447).

I can also confirm that the problem exists for the other blocks reported above with the note that:

• Hoppers only are a problem when they face a cardinal direction (facing downwards works fine).

• Grindstones only are a problem when they are wall attached (ceiling attachment works fine).

This is probably the same bug as MC-148860.

I can confirm this. The tallest block I have been able to put on top of the wolves and still have them attack the skeletons were top half slabs or stairs facings away from the skeletons. This also works if the skeletons are elevated by a bottom half slab.

An unfortunate consequence of the change is that skeletons surviving the wolf attack now more easily are able to hit the wolf back.

MC-148047 seems to be the same issue.

I would also like to know why this is "works as intended".

Sadly still an issue in 1.13.2 – but the 1.14 snapshot 18w44a looks promising with 60 FPS at v-synced fancy graphics, performing better than 1.12.2!

I also notice considerable improvement in larger contraptions, although the frame rate still is affected. I suggest prior commenters to rerun their tests in the snapshot and write back what they think so we can update the issue accordingly.

My personal experience with smaller circuits is that only light level changes cause a noticeable drop in the frame rate. The redstone circuits themselves have improved; lighting updates such as Tim Fellow's redstone_lamp_13pre6.gif are still problematic.

It would be really handy if tools were compared based on (attack speed)x(attack damage), the behavior which @Roy Sajima expected. This would allow mob-based sorting systems of hoes, axes, pickaxes, and shovels, the tools most commonly used in the game. Bows should ideally also be accounted for; a less damaged bow should be picked up over a more damaged one, for instance.

It would also be nice if enchantments were taken into account when comparing equipment, either on a "actual damage/armor value" basis or maybe the sum of enchanting levels present on the items.

As per 1.13.1 the behavior still exists, albeit under slightly different conditions:

• Item A must have no NBT tags.

• Item B must be damaged.

In 1.13.1 equipment damage appears to be stored as an NBT tag, implying that:

• Item A in the above cannot be enchanted, nor damaged.

• Item B will exhibit its behavior whether it is enchanted or not.

So as per 1.13.1 the reproduction steps are:

• Summon a mob which can pick up items

  /summon husk ~ ~ ~ {CanPickUpLoot:true}

• Set the mobGriefing gamerule to true if it is not already

  /gamerule mobGriefing true

• Throw a slightly undamaged chestplate at the mob

  /give @p diamond_chestplate 1

• Throw a nearly broken damaged chestplate (with NBT) at the mob

  /give @p diamond_chestplate{Damage:1} 1