The bug
The End generation is broken at long distances since 18w46a.
In the End, the terrain stops generating and then generates again from a certain distance from the center of the End, according to a ring pattern.
This donut-shaped pattern repeats over and over to the edge of the world on a regular basis, starting at 370,720 blocks from the center of the End.
How to reproduce
Use the following commands to teleport you:
/execute in minecraft:the_end run tp @s 370720 90 0
/execute in minecraft:the_end run tp @s 21007528 90 0
/execute in minecraft:the_end run tp @s 21010807 90 0
/execute in minecraft:the_end run tp @s 21377192 90 0
/execute in minecraft:the_end run tp @s 21380415 90 0Examples
Code analysis
The code is trying to process numbers that are much larger than what Minecraft is actually capable of for its world terrain noise which causes part of the terrain noise to generate numbers that ultimatly get read as NaN (Not a Number) and causes the terrain generation to fail outright.
For more information and a possible fix, see this comment from @unknown.
Source
Here is the source used to complete this ticket (examples, code analysis, visualization of what's going on...): https://youtu.be/91Feq0dHw28
Video by AntVenom.
Linked issues
is duplicated by 20
MC-277515
End Terrain Aburptly Stops at X cord 370719
Resolved
MC-266683
End stops generating chunks 370000 blocks out
Resolved
MC-237251
What are these?!
Resolved
MC-208632
error en el end
Resolved
MC-198184
End Dimension broken (I don’t know if anyone has reported this here)
Resolved
relates to 2
Attachments
Comments 49
I found that these rings get exponentially smaller, approximately generating around a radius of sqrt(x / 2) * 2^15. That would mean that up until the world border of 30,000,000 blocks, there are at least well over 6500 rings, or over 3250 void gaps. That's not counting partial rings in the world's corners. If it's of any help, I documented my findings here, along with a list of coordinates of the first 10 rings for those interested:
https://gist.github.com/Deltanic/b98d005c9025f10a67de9e966fa57ebb
Can the 370720 be added to the main text, so it doesn't appear to be an issue that happens at impossibly high distances?
Honestly a pretty cool concept. Imagine if the End had different “rings“ of terrain that got weirder the further the went. This bug could inspire something awesome.
The issue is in the expression
MathHelper.sqrt((float)(i * i + j * j))here, i * i + j * j can overflow the 231 - 1 limit of a 32-bit signed integer even before getting converted into float. The next 231 values become negative so sqrt returns NaN.
i and j correspond to the terrain generation coordinates, which for The End are x/8 and z/8.
A 32-bit signed integer can take 232 unique values before getting wrapped on itself, which can be interpreted as only the first half being positive.
So terrain generates only when
where n = 0, 1, 2, …
The horizontal distance r from the origin at which terrain generates therefore satisfies
Note that x/8 and z/8 in are evaluated as integers, so the strict inequality can be replaced with the exact upper bounds
Interestingly, the area of the nth ring is approximately
which does not depend on n, meaning that all the rings have equal area.
\[
2^{32} n \le \left(\frac{x}{8}\right)^2 + \left(\frac{z}{8}\right)^2 < 2^{32}\left(n + \frac12\right)
\]
$$
2^{32} n \le \left(\frac{x}{8}\right)^2 + \left(\frac{z}{8}\right)^2 < 2^{32}\left(n + \frac12\right)
$$
in my inequalities above, n = 0, 1, 2, … can be thought of as the number of times the 32-bit signed integer has been overflown. for example, the first ring occurs when it was overflown n = 1 time.
Can confirm. Those appear to be multiple "rings" around the world center that just don't generate terrain.
Also, interestingly enough, they're not chunk borders, they're quarter chunk borders.