bdm68

I was testing something in a superflat world and I forgot that I had the world in Peaceful difficulty. Wither roses are not meant to damage mobs in peaceful difficulty.

This can be closed, working as intended.

I created a test world and summoned a copper golem with this command:

/summon minecraft:copper_golem ~ ~ ~ {NoAI:1}

This allowed me to examine the behaviour of this bug more closely without the copper golem moving. A copper golem is a good test subject because it has many interesting surfaces.

I found the following:

• It behaves like z fighting (but is likely to have a different cause).

• The issue always appears at the edges and corners of the mob, never in the middle.

• Moving the camera (turning the player) causes the location of the issue to move to a different corner.

• The affected corner is often the corner closest to the cross hairs if the copper golem is observed front on. When observed diagonally, the affected corner is often the one furthest from the player.

• The issue always appeared on horizontal surfaces, never vertical ones. This includes bottom surfaces when viewed from below. For the copper golem, these locations included the top of the lightning rod, top of the head, top of the shoulders, top of the nose, and similar flat planes when viewed from below.

A possible fix: zombies become more fussy with held items the longer they hold them. Fussy zombies will drop held items and only pick up items they can use like weapons or armor. Some zombies could spawn as fussy zombies. Fussy zombies that can’t find an item they can use will despawn as normal.

This fix would be better than a long list of items zombies can’t hold. Instead it is a short list of items that fussy zombies can hold and use. Such a list would be short and easy to maintain.

Such a change would break certain contraptions that rely on zombies holding items to make them persistent. The fix is simple: give them something they can use like a wooden sword or leather cap, or give them a name with a name tag.

Some cows that show the visual glitches. Zoom in to see them. These behave like z fighting.

These visual glitches don’t appear randomly but appear in particular places on mobs. On cows they can be seen most easily on the snout, the corners of the back and the tips of the horns. I will attach a screenshot or two.

Duplicate of MC-119369 .

I have also seen these visual glitches.

For a related issue, see: MC-148494

There are three types of entities: persistent entities (these don’t despawn, example: cows), semi-persistent entities (these can despawn, example: zombies), and non-persistent entities (these must despawn, example: skeleton arrows and dropped items). Non-persistent entities include things like items or projectiles.

I have provided those definitions for clarity. The game treats all entities in non-ticking chunks the same, and a case can be made that they should have different rules. Non-persistent entities are a problem for performance because they can be spawned in unlimited numbers, the mechanics of ticking chunks forces them to remain loaded in the world, consuming memory and causing instability.

An example I have seen in-game is where a chicken on the edge of loaded chunks lays eggs that end up in lazy chunks. I have seen hundreds of eggs accumulating in this way in one location after going AFK for several hours. Another example I saw in a Youtube video involved snow golems and snowballs. A third example involved non-persistent entities summoned with commands.

I propose the following mechanism to reduce the number of non-persistent entities in lazy chunks:

1. Projectiles, items or other similar non-persistent entities are given an owner: the entity that created them. Such entities are called “lazy” if they are in lazy chunks. For dropped items, only items that can generate without limit are considered.

2. Every entity that can create non-persistent entities has a limit on the number of lazy entities of that type it can possess at a time. This is calculated by the length of time before those entities normally despawn divided by the rate of production. Examples: Chickens can lay one egg every five minutes and eggs despawn after five minutes, so the number of lazy eggs each chicken can have at a time is 1. Skeletons can shoot arrows every 2 seconds and these despawn after 2 minutes, so the number of lazy arrows a skeleton can have is 60.

3. If an entity creates a non-persistent entity that ends up in lazy chunks and it has already reached its cap of lazy entities of that type, the non-persistent entity despawns immediately.

Would this mechanism cause gameplay problems? Maybe. However, I don’t believe any gameplay problems caused by limiting the accumulation of non-persistent entities are as serious as the instability caused by allowing these entities to accumulate without limit.

Bug reports that may be duplicates of this one: MC-302133, MC-302131.

I believe that this report is a duplicate of MC-4.

Old worlds are not supported in newer versions. Support for loading older worlds has been progressively removed over time. See comment by cat67315 as a way of avoiding this issue.
This report should be closed with a resolution “working as intended” or “invalid”.

Still present in 1.21.8.

The direction of travel of furnace minecarts is affected by this. Refuelling a furnace minecart that is facing the wrong direction as a result of this bug will cause it to reverse its direction of travel. To work around this bug, place minecart tracks so the refuelled furnace minecart can switch direction.

The formula in my previous comment can be simplified slightly:

p = 2 ^ (18.5 + log(t)/(log(4)))

Here is a mathematical formula that predicts the onset of each ring on the x and z axes.

p = 2 ^ (18.5 + log(t)/(2 * log(2)))

where p is an unadjusted position and t is a parameter that are natural numbers (integers starting at 1).

When t is odd, it predicts the location where a void begins. When t is even, it predicts the location where normal terrain generation resumes.

For odd t, the true position of the void starts at:

n = floor(p/8) * 8

for even t, normal terrain resumes at:

n = ceiling(p/8) * 8

Some consequences:

• The rings get progressively narrower as distance from the origin grows larger. This effect is logarithmic as shown above.

• If any part of an 8×8 sub-chunk is out of range, the whole subchunk will not generate.

• At sufficiently large distances, terrain will stop generating completely. This occurs when the step size of each ring reaches the size of a subchunk: 8. This will not occur within the 30 million radius of the world border.

The above formula has been shown to predict correctly the locations of the first 8 rings on the x axis with z = 0. These rings occur at 370720 (void), 524288 (normal), 642112 (void), 741456 (normal), 828968 (void), 908096 (normal), 980848 (void) and 1048576 (normal); all these coordinates were found by empirical observation.

For locations in other coordinates, p should be compared to the result of sqrt(x^2 + z^2), while being careful to avoid integer overflow.

The 32-bit dates are still there in the second chunk of region files (0x1000 to 0x1fff), therefore it is still an issue.

The exact issue concerns the possibility of integer overflow when signed 32-bit dates roll over to negative numbers on 2038-01-19 (13 years from now). I have no knowledge of how these dates in anvil files are used, but if they are ever compared to anything at any time, the comparison could fail after that date due to overflow of signed 32-bit integers.

See Wikipedia article here: https://en.wikipedia.org/wiki/Year_2038_problem

I recommend giving this report a very low priority for the next few years until the need for 2038 compliance checking becomes more relevant.

Additional notes for various mobs.

Wardens - The warden attack is ineffective if the player has the creaking in view. If the player is not watching, the warden can knock back the creaking a couple of blocks with each attack, always away from the warden. It is possible for a warden to knock a creaking out of range of the creaking heart in this way, when the creaking will despawn and then respawn.

Zoglins - The zoglin can knock back the creaking a couple of blocks regardless of whether the player is watching, but this knockback is in a random direction.

Snow golems - Do no damage to creakings and cannot move them.

Iron golems - knock creakings into the air a block or so but cannot move creakings.

Withers - Hover above creakings while throwing skulls at them but cannot move them.

Johnny vindicators and creakings are interesting. A Johnny vindicator will go to attack a creaking and then turn back when it gets within a few blocks. Sometimes the Johnny vindicator will make a few futile attacks before turning away. It's possible that these Vindicators can get stuck in an endless loop of approach, attack and flee.

Post by KBerkay on Reddit showing the futility of a warden attacking a creaking: https://www.reddit.com/r/Minecraft/comments/1funnp2/unstoppable_force_vs_immovable_object_in_the_new/

Also affects Withers.