bdm68

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.

Affects 1.21.1. I have an old world. I have seen bees wandering northwest several times over a few years. Bees typically wander off northwest until they end up in lazy chunks where they can be found later. The only way I can keep bees is in an enclosed space or stored in hives in a chest. It is not possible to populate spawn chunks in old worlds with unenclosed bees without them wandering off.

I can confirm. The easiest way to see this bug is to pick up one salmon in a bucket several times.

A lot of the pathfinding issues with bees seems to happen because the bee is one block lower than it thinks it is. In particular, I have frequently observed bees getting stuck below bee nests and bee hives. Pushing the bee up one block with a piston will make the bee enter the hive or nest.

This one block distance is not a precise measurement. It is possible that it is half a block.

If it's possible to take ownership of a ticket without changing the original reporter of the ticket, then I accept the request to change ownership. I use the "reported by" functionality to track my tickets.

Amended description to account for the effect occurring on chunk borders. Did not change the ice spikes behaviour because I have not observed this.

Icon not showing in trial map

Seed: 8

Cartographer in village at: -1091 -256

Map covers: -1600, -576 to -1089, -65

Only trial chamber within range of map is near -1600, -512 (/locate command) or -1591, -521 (chunkbase) - these coordinates cross the map edge, and very little of the large trail chamber actually generates east of -1600 and south of -512.

Edit to add: inspecting the NBT of the explorer map item shows that the location of the icon for the trial chamber is at -1600, -512 ("minecraft:map_decorations" > "+" > ": "rotation":"180", "type":"minecraft.trial_chambers", "x":"-1600", "z":"-512")

I can confirm some of this. The game seems to softlock when entering a nether portal on horseback (step 4). I could save the game, and when I loaded the game again I was back in the Overworld and there was no Nether portal.

Edited to add: On reload, the horse was also in the Overworld and the player was riding it. Player and horse ended up in an ocean. I used seed 1 for the world.

This can be reproduced in new worlds.

Updated steps to reproduce:

1. Create a new Superflat world. (I used seed 1).
2. Unpack the zip file "MC161477-generated.zip" into the world save. It should create a new folder called "generated".
3. Place a structure block in the world and load the structure "mc161477". It will create a copy of the minecart tracks from the other zip file.
4. Place a minecart on the minecart tracks and get into the minecart.
5. Turn from side to side in the minecart -> the player's legs will snap from side to side and not face forward.

Affects 1.20.6.

Possible fixes:

• Make the spawn target work correctly.

• Clamp values for terrain generation around 0,0 to guarantee that the terrain at the origin is spawnable. This will require an addition to the configuration. This will be similar to the way terrain generates in The End dimension.

Notes on the second part: This could be done by defining a conical "island" at spawn. Values that are needed are a height and radius. Height sets the minimum or maximum value for a parameter, radius defines how far out the influence goes. It is defined for each terrain generation setting. So a "continentalness" height of 0.2 and a radius of 1000 blocks causes the continentalness to be scaled at 0,0 so -1.0 is mapped to 0.2, +1.0 is mapped to +1.0 and other values scale accordingly. The amount of the scaling falls by distance and falls to 0 at 1000 blocks from spawn. If the absolute distance in either x or z direction is farther than the maximum distance this check should be skipped (see MC-159283 for the reason why).

Factorio manipulates terrain generation to guarantee particular terrain at 0,0. On a Factorio map of Nauvis, terrain at 0,0 is always land.

Related: MC-245793

11:32:31.273 anz Server thread Stopping singleplayer server as player logged out
11:32:31.466 net.minecraft.server.MinecraftServer Server thread Stopping server
11:32:31.467 net.minecraft.server.MinecraftServer Server thread Saving players
11:32:31.467 net.minecraft.server.MinecraftServer Server thread Saving worlds
11:32:31.504 net.minecraft.server.MinecraftServer Server thread Saving chunks for level 'ServerLevel[Test Continents 1204]'/minecraft:overworld
11:50:51.472 net.minecraft.server.MinecraftServer Server thread Saving chunks for level 'ServerLevel[Test Continents 1204]'/minecraft:the_nether
11:50:51.473 net.minecraft.server.MinecraftServer Server thread Saving chunks for level 'ServerLevel[Test Continents 1204]'/minecraft:the_end
11:50:51.567 net.minecraft.server.MinecraftServer Server thread ThreadedAnvilChunkStorage (Test Continents 1204): All chunks are saved
11:50:51.567 net.minecraft.server.MinecraftServer Server thread ThreadedAnvilChunkStorage (DIM-1): All chunks are saved
11:50:51.567 net.minecraft.server.MinecraftServer Server thread ThreadedAnvilChunkStorage (DIM1): All chunks are saved
11:50:51.567 net.minecraft.server.MinecraftServer Server thread ThreadedAnvilChunkStorage: All dimensions are saved

After generating a lot of chunks using redstone, I exited to the main menu. It took over 18 minutes to save the Overworld with the disk near 100% most of the time.