bdm68

The teleport command can be used to face a particular direction. Example:

/tp @p ~ ~ ~ 180 90

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.

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.

Duplicate of MC-119369 .

This is working as intended. The F3 information always prints on top of everything else and it has always been this way, even back in the Alpha days.

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.

The FIRST witch spawns in the swamp hut. This is clearly stated in the description. The spawning of this witch is not affected. One witch spawns with the structure, other witches spawn within the bounding box. Bounding box witches seem to be absent. I am restating this for clarity.

I have spent half an hour in the vicinity of swamp huts in two worlds. Half an hour in a old world with a witch farm: no witch drops on hard difficulty (the same farm would have produced over a stack of redstone dust in that time). Half an hour in a freshly-created world on normal difficulty, no witches. I created a very simple witch trap in this world. No drops. I can rule out the possibility that witches don't produce drops (witches from spawn eggs produced drops).

I have copied a save file here: https://www.dropbox.com/scl/fi/rv3pvm0ajto8ar62wuhu1/MC-276836.zip?rlkey=7sb0rztcaqwfyxvf4nh4axdxr

Difficulty was NOT set to Peaceful. Other hostile mobs spawned nearby.

I have seen this in two worlds: (1) a copy of an old world with a witch farm, (2) a new world created specifically for testing this. I have not seen a single witch spawning in swamp huts in either world except for the single witch that spawns with the structure.

I tried to upload a 22Mb world save of world 2 but couldn't do it due to the low limits on file size.