Cave/tunnel generation may cut tunnels a bit too soon (fix included)
(Possible test cases moved under own heading below.)
Slightly related to MC-7196, same classes and methods in question, almost the same effect, but different bug in the code.
Cave/tunnel generator, both for Nether and overworld, may sometimes cut tunnels of at chunk borders, leaving flat straight walls, or have straight-angle incursions of stone into the tunnel. For this bug I do not have examples, because knowing which particular straight wall is because of this bug (rare) or because of the much more common MC-7196 is difficult.
However, explanation of mistake in the code might suffice...
Background
The tunnel generation algorithm has an optimization which calculates if the distance from the algorithm's current "tunnel digging" point to the generated chunk's center is longer than the remaining length of the tunnel. If the former length is longer, the tunnel can not reach the chunk, so the algorithm can be stopped there.
The bug
The distance between current digging point and chunk center is basically calculated correctly (though kept in the squared value), but the comparison is done with incorrect math, trying to subtract the square of the remaining length from the squared distance, and then compare the result to tunnel's maximum diameter (and a bit more) squared. Squared values can not be subtracted or compared like that.
If one does so (like in this case), the results will (incorrectly) vary depending on which particular relative locations are in question. Thus, at one chunk, the algorithm may think that the tunnel can not reach the chunk, while drawing the neighbour chunk, the algorithm thinks it will easily reach that chunk, and can correctly carve it, right the to edge of that chunk, leaving nasty straight cut at some chunk border.
Here is the bad code, with my variable name interpretations:
double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); if (xDeltaToChunkCenter * xDeltaToChunkCenter + ZDeltaToChunkCenter * ZDeltaToChunkCenter - remainingLength * remainingLength > tunnelDiameterAndMore * tunnelDiameterAndMore) { return; }
Exactly equal bug exists in the MapGenCaves class.
The fix
double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); double directDistanceSquared = xDeltaToChunkCenter * xDeltaToChunkCenter + zDeltaToChunkCenter * zDeltaToChunkCenter; double tunnelsMaximumRemainingReachSquared = (remainingLength + tunnelDiameterAndMore) * (remainingLength + tunnelDiameterAndMore); if (directDistanceSquared > tunnelsMaximumRemainingReachSquared) { return; }
That is, the math has been changed to compare the distance squared against remaining reach squared, which should be valid math.
Possible test cases
From Jens-Oliver Tofahrn, looks like possibly at least 3 "cuts" near each other; tp goes right in there, dark place, get torch:
Demo seed "North Carolina" or -343522682, F3-n, F3-g
/tp @s -48.42 18.94 0.10 -463.95 55.80
Multiple cuts near each other, the first place even has two cuts in the same view:
Seed 1479112774635546442
/tp @p -440 62 11 107 20
/tp @p -457 62 18 -140 19
/tp @p -447 62 -96 114 -12
(Wery Old: Semi-quick test case, though not 100% certain if it is caused by this issue: seed -4542366974610774625, Nether 218, -67, dig down to about 19 and look south east.)
History
This bug has been around for at least since summer 2011. Back then I found it, fixed it, reported it, and provided screenshots for "before and after". I estimated very roughly that in the overworld, about 1/4th of straight wall glitches in tunnels were caused by this bug, the rest by the other bug (MC-7196 when it was still effective for overworld, too), based on observed differences while enabling either fix separately.
Linked Issues
is duplicated by6
MC-190684Caves (and other features) occasionally stop generating at chunk bordersDuplicateMC-216773Some chunks not getting carved by cave carvers / chunks filled with stone or deepslateDuplicateMC-217120Höhlengeneration wird in manchen Chunks nicht übernommenDuplicateMC-217556Chunk errors in cavesDuplicateMC-221609chunk errorDuplicateMC-221692Full chunk filled with Deepslate from -37 downwards, looks unnatural.Duplicate
Created Issue:
Cave/tunnel generation may cut tunnels a bit too soon (fix included)
Slightly related to
MC-7196, same classes and methods in question, almost the same effect, but different bug in the code.Cave/tunnel generator, both for Nether and overworld, may sometimes cut tunnels of at chunk borders, leaving flat straight walls, or have straight-angle incursions of stone into the tunnel. For this bug I do not have examples, because knowing which particular straight wall is because of this bug (rare) or because of the much more common
MC-7196is difficult.However, explanation of mistake in the code might suffice...
Background
The tunnel generation algorithm has an optimization which calculates if the distance from the algorithm's current "tunnel digging" point to the generated chunk's center is longer than the remaining length of the tunnel. If the former length is longer, the tunnel can not reach the chunk, so the algorithm can be stopped there.The bug
The distance between current digging point and chunk center is basically calculated correctly (though kept in the squared value), but the comparison is done with incorrect math, trying to subtract the square of the remaining length from the squared distance, and then compare the result to tunnel's maximum diameter (and a bit more) squared. Squared values can not be subtracted or compared like that.If one does so (like in this case), the results will (incorrectly) vary depending on which particular relative locations are in question. Thus, at one chunk, the algorithm may think that the tunnel can not reach the chunk, while drawing the neighbour chunk, the algorithm thinks it will easily reach that chunk, and can correctly carve it, right the to edge of that chunk, leaving nasty straight cut at some chunk border.
Here is the bad code, with my variable name interpretations:
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); if (xDeltaToChunkCenter * xDeltaToChunkCenter + ZDeltaToChunkCenter * ZDeltaToChunkCenter - remainingLength * remainingLength > tunnelDiameterAndMore * tunnelDiameterAndMore) { return; }Exactly equal bug exists in the MapGenCaves class.
The fix
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); double directDistanceSquared = xDeltaToChunkCenter * xDeltaToChunkCenter + zDeltaToChunkCenter * zDeltaToChunkCenter; double tunnelsMaximumRemainingReachSquared = (remainingLength + tunnelDiameterAndMore) * (remainingLength + tunnelDiameterAndMore); if (directDistanceSquared > tunnelsMaximumRemainingReachSquared) { return; }That is, the math has been changed to compare the distance squared against remaining reach squared, which should be valid math.
History
This bug has been around for at least since summer 2011. Back then I found it, fixed it, reported it, and provided screenshots for "before and after". I estimated very roughly that in the overworld, about 1/4th of straight wall glitches in tunnels were caused by this bug, the rest by the other bug (MC-7196when it was still effective for overworld, too), based on observed differences while enabling either fix separately.Environment
Platform/environment shouldn't matter, as the bug is in the java code.
(Windows 7 64-bit, java 7 64-bit, naturally unmodified Minecraft).
relates to
is duplicated by
relates to
is duplicated by
A comment with security level 'global-moderators' was removed.
![[Bot] Arisa](../../../data/assets/gravatar/mustek2.png){kind=small}
(Semi-quick test case, though not 100% certain if it is caused by this issue: seed -4542366974610774625, Nether 218, -67, dig down to about 19 and look south east.)
Slightly related to
MC-7196, same classes and methods in question, almost the same effect, but different bug in the code.Cave/tunnel generator, both for Nether and overworld, may sometimes cut tunnels of at chunk borders, leaving flat straight walls, or have straight-angle incursions of stone into the tunnel. For this bug I do not have examples, because knowing which particular straight wall is because of this bug (rare) or because of the much more common
MC-7196is difficult.However, explanation of mistake in the code might suffice...
Background
The tunnel generation algorithm has an optimization which calculates if the distance from the algorithm's current "tunnel digging" point to the generated chunk's center is longer than the remaining length of the tunnel. If the former length is longer, the tunnel can not reach the chunk, so the algorithm can be stopped there.The bug
The distance between current digging point and chunk center is basically calculated correctly (though kept in the squared value), but the comparison is done with incorrect math, trying to subtract the square of the remaining length from the squared distance, and then compare the result to tunnel's maximum diameter (and a bit more) squared. Squared values can not be subtracted or compared like that.If one does so (like in this case), the results will (incorrectly) vary depending on which particular relative locations are in question. Thus, at one chunk, the algorithm may think that the tunnel can not reach the chunk, while drawing the neighbour chunk, the algorithm thinks it will easily reach that chunk, and can correctly carve it, right the to edge of that chunk, leaving nasty straight cut at some chunk border.
Here is the bad code, with my variable name interpretations:
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); if (xDeltaToChunkCenter * xDeltaToChunkCenter + ZDeltaToChunkCenter * ZDeltaToChunkCenter - remainingLength * remainingLength > tunnelDiameterAndMore * tunnelDiameterAndMore) { return; }Exactly equal bug exists in the MapGenCaves class.
The fix
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); double directDistanceSquared = xDeltaToChunkCenter * xDeltaToChunkCenter + zDeltaToChunkCenter * zDeltaToChunkCenter; double tunnelsMaximumRemainingReachSquared = (remainingLength + tunnelDiameterAndMore) * (remainingLength + tunnelDiameterAndMore); if (directDistanceSquared > tunnelsMaximumRemainingReachSquared) { return; }That is, the math has been changed to compare the distance squared against remaining reach squared, which should be valid math.
History
This bug has been around for at least since summer 2011. Back then I found it, fixed it, reported it, and provided screenshots for "before and after". I estimated very roughly that in the overworld, about 1/4th of straight wall glitches in tunnels were caused by this bug, the rest by the other bug (MC-7196when it was still effective for overworld, too), based on observed differences while enabling either fix separately.
Platform/environment shouldn't matter, as the bug is in the java code.
(Windows 7 64-bit, java 7 64-bit, naturally unmodified Minecraft).Windows 7 64-bit, java 7 64-bit
relates to
![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
![[Mod] CubeTheThird](../../../data/assets/gravatar/cubethethird.jpeg){kind=small}
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
(Semi-quick test case, though not 100% certain if it is caused by this issue: seed -4542366974610774625, Nether 218, -67, dig down to about 19 and look south east.)
Slightly related to
MC-7196, same classes and methods in question, almost the same effect, but different bug in the code.Cave/tunnel generator, both for Nether and overworld, may sometimes cut tunnels of at chunk borders, leaving flat straight walls, or have straight-angle incursions of stone into the tunnel. For this bug I do not have examples, because knowing which particular straight wall is because of this bug (rare) or because of the much more common
MC-7196is difficult.However, explanation of mistake in the code might suffice...
Background
The tunnel generation algorithm has an optimization which calculates if the distance from the algorithm's current "tunnel digging" point to the generatedchunk's center is longer than the remaining length of the tunnel. If the former length is longer, the tunnel can not reach the chunk, so the algorithm can be stopped there.The bug
The distance between current digging point and chunk center is basically calculated correctly (though kept in the squared value), but the comparison is done with incorrect math, trying to subtract the square of the remaining length from the squared distance, and then compare the result to tunnel's maximum diameter (and a bit more) squared. Squared values can not be subtracted or compared like that.If one does so (like in this case), the results will (incorrectly) vary depending on which particular relative locations are in question. Thus, at one chunk, the algorithm may think that the tunnel can not reach the chunk, while drawing the neighbour chunk, the algorithm thinks it will easily reach that chunk, and can correctly carve it, right the to edge of that chunk, leaving nasty straight cut at some chunk border.
Here is the bad code, with my variable name interpretations:
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); if (xDeltaToChunkCenter * xDeltaToChunkCenter + ZDeltaToChunkCenter * ZDeltaToChunkCenter - remainingLength * remainingLength > tunnelDiameterAndMore * tunnelDiameterAndMore) { return; }Exactly equal bug exists in the MapGenCaves class.
The fix
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); double directDistanceSquared = xDeltaToChunkCenter * xDeltaToChunkCenter + zDeltaToChunkCenter * zDeltaToChunkCenter; double tunnelsMaximumRemainingReachSquared = (remainingLength + tunnelDiameterAndMore) * (remainingLength + tunnelDiameterAndMore); if (directDistanceSquared > tunnelsMaximumRemainingReachSquared) { return; }That is, the math has been changed to compare the distance squared against remaining reach squared, which should be valid math.
History
This bug has been around for at least since summer 2011. Back then I found it, fixed it, reported it, and provided screenshots for "before and after". I estimated very roughly that in the overworld, about 1/4th of straight wall glitches in tunnels were caused by this bug, the rest by the other bug (MC-7196when it was still effective for overworld, too), based on observed differences while enabling either fix separately.(Wery Old: Semi-quick test case, though not 100% certain if it is caused by this issue: seed -4542366974610774625, Nether 218, -67, dig down to about 19 and look south east.)
(Newer possible test case from Jens-Oliver Tofahrn, looks like possibly at least 3 "cuts" near each other; tp goes right in there, dark place, get torch:
Demo seed "North Carolina" or -343522682, F3-n, F3-g
/tp @s -48.42 18.94 0.10 -463.95 55.80)Slightly related to
MC-7196, same classes and methods in question, almost the same effect, but different bug in the code.Cave/tunnel generator, both for Nether and overworld, may sometimes cut tunnels of at chunk borders, leaving flat straight walls, or have straight-angle incursions of stone into the tunnel. For this bug I do not have examples, because knowing which particular straight wall is because of this bug (rare) or because of the much more common
MC-7196is difficult.However, explanation of mistake in the code might suffice...
Background
The tunnel generation algorithm has an optimization which calculates if the distance from the algorithm's current "tunnel digging" point to the generated chunk's center is longer than the remaining length of the tunnel. If the former length is longer, the tunnel can not reach the chunk, so the algorithm can be stopped there.The bug
The distance between current digging point and chunk center is basically calculated correctly (though kept in the squared value), but the comparison is done with incorrect math, trying to subtract the square of the remaining length from the squared distance, and then compare the result to tunnel's maximum diameter (and a bit more) squared. Squared values can not be subtracted or compared like that.If one does so (like in this case), the results will (incorrectly) vary depending on which particular relative locations are in question. Thus, at one chunk, the algorithm may think that the tunnel can not reach the chunk, while drawing the neighbour chunk, the algorithm thinks it will easily reach that chunk, and can correctly carve it, right the to edge of that chunk, leaving nasty straight cut at some chunk border.
Here is the bad code, with my variable name interpretations:
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); if (xDeltaToChunkCenter * xDeltaToChunkCenter + ZDeltaToChunkCenter * ZDeltaToChunkCenter - remainingLength * remainingLength > tunnelDiameterAndMore * tunnelDiameterAndMore) { return; }Exactly equal bug exists in the MapGenCaves class.
The fix
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); double directDistanceSquared = xDeltaToChunkCenter * xDeltaToChunkCenter + zDeltaToChunkCenter * zDeltaToChunkCenter; double tunnelsMaximumRemainingReachSquared = (remainingLength + tunnelDiameterAndMore) * (remainingLength + tunnelDiameterAndMore); if (directDistanceSquared > tunnelsMaximumRemainingReachSquared) { return; }That is, the math has been changed to compare the distance squared against remaining reach squared, which should be valid math.
History
This bug has been around for at least since summer 2011. Back then I found it, fixed it, reported it, and provided screenshots for "before and after". I estimated very roughly that in the overworld, about 1/4th of straight wall glitches in tunnels were caused by this bug, the rest by the other bug (MC-7196when it was still effective for overworld, too), based on observed differences while enabling either fix separately.
relates to
(Wery Old: Semi-quick test case, though not 100% certain if it is caused by this issue: seed -4542366974610774625, Nether 218, -67, dig down to about 19 and look south east.)
(Newer possible test case from Jens-Oliver Tofahrn, looks like possibly at least 3 "cuts" near each other; tp goes right in there, dark place, get torch:
Demo seed "North Carolina" or -343522682, F3-n, F3-g
/tp @s -48.42 18.94 0.10 -463.95 55.80)Slightly related to
MC-7196, same classes and methods in question, almost the same effect, but different bug in the code.Cave/tunnel generator, both for Nether and overworld, may sometimes cut tunnels of at chunk borders, leaving flat straight walls, or have straight-angle incursions of stone into the tunnel. For this bug I do not have examples, because knowing which particular straight wall is because of this bug (rare) or because of the much more common
MC-7196is difficult.However, explanation of mistake in the code might suffice...
Background
The tunnel generation algorithm has an optimization which calculates if the distance from the algorithm's current "tunnel digging" point to the generated chunk's center is longer than the remaining length of the tunnel. If the former length is longer, the tunnel can not reach the chunk, so the algorithm can be stopped there.The bug
The distance between current digging point and chunk center is basically calculated correctly (though kept in the squared value), but the comparison is done with incorrect math, trying to subtract the square of the remaining length from the squared distance, and then compare the result to tunnel's maximum diameter (and a bit more) squared. Squared values can not be subtracted or compared like that.If one does so (like in this case), the results will (incorrectly) vary depending on which particular relative locations are in question. Thus, at one chunk, the algorithm may think that the tunnel can not reach the chunk, while drawing the neighbour chunk, the algorithm thinks it will easily reach that chunk, and can correctly carve it, right the to edge of that chunk, leaving nasty straight cut at some chunk border.
Here is the bad code, with my variable name interpretations:
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); if (xDeltaToChunkCenter * xDeltaToChunkCenter + ZDeltaToChunkCenter * ZDeltaToChunkCenter - remainingLength * remainingLength > tunnelDiameterAndMore * tunnelDiameterAndMore) { return; }Exactly equal bug exists in the MapGenCaves class.
The fix
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); double directDistanceSquared = xDeltaToChunkCenter * xDeltaToChunkCenter + zDeltaToChunkCenter * zDeltaToChunkCenter; double tunnelsMaximumRemainingReachSquared = (remainingLength + tunnelDiameterAndMore) * (remainingLength + tunnelDiameterAndMore); if (directDistanceSquared > tunnelsMaximumRemainingReachSquared) { return; }
That is, the math has been changed to compare the distance squared against remaining reach squared, whichshould be valid math.History
This bug has been around for at least since summer 2011. Back then I found it, fixed it, reported it, and provided screenshots for "before and after". I estimated very roughly that in the overworld, about 1/4th of straight wall glitches in tunnels were caused by this bug, the rest by the other bug (MC-7196when it was still effective for overworld, too), based on observed differences while enabling either fix separately.(Possible test cases moved under own heading below.)
Slightly related to
MC-7196, same classes and methods in question, almost the same effect, but different bug in the code.Cave/tunnel generator, both for Nether and overworld, may sometimes cut tunnels of at chunk borders, leaving flat straight walls, or have straight-angle incursions of stone into the tunnel. For this bug I do not have examples, because knowing which particular straight wall is because of this bug (rare) or because of the much more common
MC-7196is difficult.However, explanation of mistake in the code might suffice...
Background
The tunnel generation algorithm has an optimization which calculates if the distance from the algorithm's current "tunnel digging" point to the generated chunk's center is longer than the remaining length of the tunnel. If the former length is longer, the tunnel can not reach the chunk, so the algorithm can be stopped there.The bug
The distance between current digging point and chunk center is basically calculated correctly (though kept in the squared value), but the comparison is done with incorrect math, trying to subtract the square of the remaining length from the squared distance, and then compare the result to tunnel's maximum diameter (and a bit more) squared. Squared values can not be subtracted or compared like that.If one does so (like in this case), the results will (incorrectly) vary depending on which particular relative locations are in question. Thus, at one chunk, the algorithm may think that the tunnel can not reach the chunk, while drawing the neighbour chunk, the algorithm thinks it will easily reach that chunk, and can correctly carve it, right the to edge of that chunk, leaving nasty straight cut at some chunk border.
Here is the bad code, with my variable name interpretations:
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); if (xDeltaToChunkCenter * xDeltaToChunkCenter + ZDeltaToChunkCenter * ZDeltaToChunkCenter - remainingLength * remainingLength > tunnelDiameterAndMore * tunnelDiameterAndMore) { return; }Exactly equal bug exists in the MapGenCaves class.
The fix
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); double directDistanceSquared = xDeltaToChunkCenter * xDeltaToChunkCenter + zDeltaToChunkCenter * zDeltaToChunkCenter; double tunnelsMaximumRemainingReachSquared = (remainingLength + tunnelDiameterAndMore) * (remainingLength + tunnelDiameterAndMore); if (directDistanceSquared > tunnelsMaximumRemainingReachSquared) { return; }That is, the math has been changed to compare the distance squared against remaining reach squared, which should be valid math.
Possible test cases
From Jens-Oliver Tofahrn, looks like possibly at least 3 "cuts" near each other; tp goes right in there, dark place, get torch:
Demo seed "North Carolina" or -343522682, F3-n, F3-g
/tp @s -48.42 18.94 0.10 -463.95 55.80Multiple cuts near each other, the first place even has two cuts in the same view:
Seed 1479112774635546442
{{/tp @p -440 62 11 107 20
}}/tp @p -457 62 18 -140 19
/tp @p -447 62 -96 114 -12(Wery Old: Semi-quick test case, though not 100% certain if it is caused by this issue: seed -4542366974610774625, Nether 218, -67, dig down to about 19 and look south east.)
History
This bug has been around for at least since summer 2011. Back then I found it, fixed it, reported it, and provided screenshots for "before and after". I estimated very roughly that in the overworld, about 1/4th of straight wall glitches in tunnels were caused by this bug, the rest by the other bug (MC-7196when it was still effective for overworld, too), based on observed differences while enabling either fix separately.
(Possible test cases moved under own heading below.)
Slightly related to
MC-7196, same classes and methods in question, almost the same effect, but different bug in the code.Cave/tunnel generator, both for Nether and overworld, may sometimes cut tunnels of at chunk borders, leaving flat straight walls, or have straight-angle incursions of stone into the tunnel. For this bug I do not have examples, because knowing which particular straight wall is because of this bug (rare) or because of the much more common
MC-7196is difficult.However, explanation of mistake in the code might suffice...
Background
The tunnel generation algorithm has an optimization which calculates if the distance from the algorithm's current "tunnel digging" point to the generated chunk's center is longer than the remaining length of the tunnel. If the former length is longer, the tunnel can not reach the chunk, so the algorithm can be stopped there.The bug
The distance between current digging point and chunk center is basically calculated correctly (though kept in the squared value), but the comparison is done with incorrect math, trying to subtract the square of the remaining length from the squared distance, and then compare the result to tunnel's maximum diameter (and a bit more) squared. Squared values can not be subtracted or compared like that.If one does so (like in this case), the results will (incorrectly) vary depending on which particular relative locations are in question. Thus, at one chunk, the algorithm may think that the tunnel can not reach the chunk, while drawing the neighbour chunk, the algorithm thinks it will easily reach that chunk, and can correctly carve it, right the to edge of that chunk, leaving nasty straight cut at some chunk border.
Here is the bad code, with my variable name interpretations:
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); if (xDeltaToChunkCenter * xDeltaToChunkCenter + ZDeltaToChunkCenter * ZDeltaToChunkCenter - remainingLength * remainingLength > tunnelDiameterAndMore * tunnelDiameterAndMore) { return; }Exactly equal bug exists in the MapGenCaves class.
The fix
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); double directDistanceSquared = xDeltaToChunkCenter * xDeltaToChunkCenter + zDeltaToChunkCenter * zDeltaToChunkCenter; double tunnelsMaximumRemainingReachSquared = (remainingLength + tunnelDiameterAndMore) * (remainingLength + tunnelDiameterAndMore); if (directDistanceSquared > tunnelsMaximumRemainingReachSquared) { return; }That is, the math has been changed to compare the distance squared against remaining reach squared, which should be valid math.
Possible test cases
From Jens-Oliver Tofahrn, looks like possibly at least 3 "cuts" near each other; tp goes right in there, dark place, get torch:
Demo seed "North Carolina" or -343522682, F3-n, F3-g
/tp @s -48.42 18.94 0.10 -463.95 55.80Multiple cuts near each other, the first place even has two cuts in the same view:
Seed 1479112774635546442{{/tp @p -440 62 11 107 20
}}/tp @p -457 62 18 -140 19
/tp @p -447 62 -96 114 -12(Wery Old: Semi-quick test case, though not 100% certain if it is caused by this issue: seed -4542366974610774625, Nether 218, -67, dig down to about 19 and look south east.)
History
This bug has been around for at least since summer 2011. Back then I found it, fixed it, reported it, and provided screenshots for "before and after". I estimated very roughly that in the overworld, about 1/4th of straight wall glitches in tunnels were caused by this bug, the rest by the other bug (MC-7196when it was still effective for overworld, too), based on observed differences while enabling either fix separately.(Possible test cases moved under own heading below.)
Slightly related to
MC-7196, same classes and methods in question, almost the same effect, but different bug in the code.Cave/tunnel generator, both for Nether and overworld, may sometimes cut tunnels of at chunk borders, leaving flat straight walls, or have straight-angle incursions of stone into the tunnel. For this bug I do not have examples, because knowing which particular straight wall is because of this bug (rare) or because of the much more common
MC-7196is difficult.However, explanation of mistake in the code might suffice...
Background
The tunnel generation algorithm has an optimization which calculates if the distance from the algorithm's current "tunnel digging" point to the generated chunk's center is longer than the remaining length of the tunnel. If the former length is longer, the tunnel can not reach the chunk, so the algorithm can be stopped there.The bug
The distance between current digging point and chunk center is basically calculated correctly (though kept in the squared value), but the comparison is done with incorrect math, trying to subtract the square of the remaining length from the squared distance, and then compare the result to tunnel's maximum diameter (and a bit more) squared. Squared values can not be subtracted or compared like that.If one does so (like in this case), the results will (incorrectly) vary depending on which particular relative locations are in question. Thus, at one chunk, the algorithm may think that the tunnel can not reach the chunk, while drawing the neighbour chunk, the algorithm thinks it will easily reach that chunk, and can correctly carve it, right the to edge of that chunk, leaving nasty straight cut at some chunk border.
Here is the bad code, with my variable name interpretations:
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); if (xDeltaToChunkCenter * xDeltaToChunkCenter + ZDeltaToChunkCenter * ZDeltaToChunkCenter - remainingLength * remainingLength > tunnelDiameterAndMore * tunnelDiameterAndMore) { return; }Exactly equal bug exists in the MapGenCaves class.
The fix
MapGenCavesHell.generateCaveNode(...)double xDeltaToChunkCenter = startX - chunkCenterX; double zDeltaToChunkCenter = startZ - chunkCenterZ; double remainingLength = (double)(fullLength - currentDistance); double tunnelDiameterAndMore = (double)(diameterVariance + 2.0F + 16.0F); double directDistanceSquared = xDeltaToChunkCenter * xDeltaToChunkCenter + zDeltaToChunkCenter * zDeltaToChunkCenter; double tunnelsMaximumRemainingReachSquared = (remainingLength + tunnelDiameterAndMore) * (remainingLength + tunnelDiameterAndMore); if (directDistanceSquared > tunnelsMaximumRemainingReachSquared) { return; }That is, the math has been changed to compare the distance squared against remaining reach squared, which should be valid math.
Possible test cases
From Jens-Oliver Tofahrn, looks like possibly at least 3 "cuts" near each other; tp goes right in there, dark place, get torch:
Demo seed "North Carolina" or -343522682, F3-n, F3-g
/tp @s -48.42 18.94 0.10 -463.95 55.80Multiple cuts near each other, the first place even has two cuts in the same view:
Seed 1479112774635546442
/tp @p -440 62 11 107 20
/tp @p -457 62 18 -140 19
/tp @p -447 62 -96 114 -12(Wery Old: Semi-quick test case, though not 100% certain if it is caused by this issue: seed -4542366974610774625, Nether 218, -67, dig down to about 19 and look south east.)
History
This bug has been around for at least since summer 2011. Back then I found it, fixed it, reported it, and provided screenshots for "before and after". I estimated very roughly that in the overworld, about 1/4th of straight wall glitches in tunnels were caused by this bug, the rest by the other bug (MC-7196when it was still effective for overworld, too), based on observed differences while enabling either fix separately.
relates to
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
is duplicated by
![[Bot] Arisa](../../../data/avatars/users/43007.png){kind=small}
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
Normal
hknibergis duplicated by
![[Mod] Neko](../../../data/avatars/users/92901.png){kind=small}
relates to
is duplicated by
relates to
hkniberg![[Mod] markderickson](../../../data/avatars/users/18946.svg){kind=small}
![[Helper] Michał](../../../data/avatars/users/43368.png){kind=small}
relates to
![[Mojang] slicedlime](../../../data/assets/gravatar/slicedlime.jpeg){kind=small}
The screenshot numbers seem to be mixed up (due to way how JIRA switches order when uploading more or something).
Actually, most screenshots depict a different issue than the MC-6820. I think this issue could be the same or at least related to issue MC-7200 (also reported by me and has a fix).
Would be nice to get seeds and locations if anyone spots similar straight cut surface caves/tunnels. I could easily check the bug then.
I managed to create that same world and gave a bit of surgical knife to the cave generator code...
I first applied the two fixes, but that didn't help, so this issue is NOT related to either MC-7200 or MC-6820.
I then suspected another piece of code and made a specific change to prevent that code working in the relevant coordinates (allowing that tunnel to continue no matter what that suspected code was deciding). And this time the tunnel did continue, like shown in the other screenshot. Thus that suspected piece of code is the reason...
... But the disabled piece of code is an intended feature, though implemented in a bit crude way. Namely, there is specific check in the cave generator code for NOT tunneling into water; it stops the tunnel just before it. It is not perfect, as it makes a sharp cut instead of trying to do some fancy natural shaping (difficult!).
So, this particular case is "intended feature". Changes to it should probably be a feature request along the lines of "more natural caves/tunnels near waters".
Improvement (a.k.a. partial fix)
MCP naming (and a bit of my own)...
...
private int rePathingDelay; // field_75445_i
// part of FIX:
private double pathedTargetX; // Leaving these uninitialized, evul me.
private double pathedTargetY;
private double pathedTargetZ;
private boolean previousPathingOk = false; // Not really needed here, but an idea for future...
...
public void updateTask() {
EntityLivingBase var1 = this.attacker.getAttackTarget();
this.attacker.getLookHelper().setLookPositionWithEntity(var1, 30.0F, 30.0F);
// OLD:
// if ((this.forcePathing || this.attacker.getEntitySenses().canSee(var1)) && --this.rePathingDelay <= 0) {
// this.rePathingDelay = 4 + this.attacker.getRNG().nextInt(7);
// this.attacker.getNavigator().tryMoveToEntityLiving(var1, this.speed);
// }
// NEW:
double targetDistanceSq = this.attacker.getDistanceSq(var1.posX, var1.boundingBox.minY, var1.posZ);
if (this.rePathingDelay > 0)
--this.rePathingDelay;
if (this.forcePathing || this.attacker.getEntitySenses().canSee(var1)) {
boolean repath = false;
double targetMovement = var1.getDistanceSq(pathedTargetX, pathedTargetY, pathedTargetZ);
// Only do a new path search if enough time has passed from the previous search, and the target has moved:
if (rePathingDelay <= 0) {
if (targetMovement >= 1.0D) {
repath = true;
}
}
// Ensure an occasional pathing if it would not be happening otherwise (e.g. to work when world
// changed, or to work around any other unnoticed needs, or effects of future changes in code):
if (!repath && rePathingDelay <= 0 && this.attacker.getRNG().nextInt(200) == 0) {
repath = true;
}
if (repath) {
previousPathingOk = this.attacker.getNavigator().tryMoveToEntityLiving(var1, this.speed);
pathedTargetX = var1.posX;
pathedTargetY = var1.boundingBox.minY;
pathedTargetZ = var1.posZ;
this.rePathingDelay = 4 + this.attacker.getRNG().nextInt(7);
// A longer delay for longer distances, or if the pathing failed
if (targetDistanceSq > 256.0D) { // > 16 blocks
if (targetDistanceSq > 1024.0D) { // > 32 blocks
this.rePathingDelay += 8;
} else {
this.rePathingDelay += 16;
}
} else if (!previousPathingOk) {
this.rePathingDelay += 24;
}
}
}
this.attackTick = Math.max(this.attackTick - 1, 0);
double var2 = (double) (this.attacker.width * 2.0F * this.attacker.width * 2.0F + var1.width);
// if (this.attacker.getDistanceSq(var1.posX, var1.boundingBox.minY, var1.posZ) <= var2) {
if (targetDistanceSq <= var2) {
...
With the above changes, the CPU load gets some peaking when loading a world (as both villagers and zombies will all do AI decisions and pathing again), but it stabilizes in 10-15 seconds to idle levels (for me 10%-12%). The CPU load can still occasionally peak at high values (for me 15%-20%) for 1-2 seconds. The overall average level is much nicer, and observable "lag" was almost totally gone.
The peaks come when the target(s) move and all zombies (that targeted the moving entity) will repath for a moment. In case of a continuously moving target (like fleeing villager/player), the load and lagginess can still be there (though seemed to be helped a bit). However, in a typical case, such situation can not continue for long (villager dies or all involved entities move out of range, player kills zombies, etc.). And also, typically, in such case there is a path from zombie(s) to target, and the lag has been problem with there is no path.
The biggest problem seemed to be with the villagers just standing inside their homes while zombies bash the doors, and the above change handles that situation just fine.
Feedback is welcome, especially if anyone is able to test those modifications with a less beefy (or more heavily loaded) system.
EDIT2: My bad for the part below.
The other change I had made was in the world; the zombies were not without path..
The optimization part below is still a valid one, but doesn't solve anything. The distance squared is apparently just as correct as distance for the algorithm used.
EDIT: Even bigger improvement (a.k.a. a real bug and real fix)
Although this alone makes a huge difference (even bigger/better than the above one) and works also when a bunch of zombies are chasing villager(s), I recommend having both sets of changes.
The real bug is that the method is adding squared distances, and then also comparing those borked values with other squared distances. Can't do that! (It is okay to compare two squared distances to each other, though, as the square-function is monotonic). Changing the calculations to use normal distance (i.e. calculating square roots) made the path finding method work much more efficiently. They still do occasionally produce large point sets (when the zombies are still far away) as expected, but with the fix, when they are near the target, the point set sizes stay less than couple hundred (instead of the non-fixed 40000+).
(This method would be better named (in MCP) as findPath() as that is what it does.)
private PathEntity findPath(Entity entity, PathPoint startPoint, PathPoint endPoint, PathPoint size, float maxDistance) { startPoint.totalPathDistance = 0.0F; //startPoint.distanceToNext = startPoint.distanceSquaredTo(endPoint); startPoint.distanceToNext = startPoint.distanceTo(endPoint); // FIX ... for (int var9 = 0; var9 < optionsCount; ++var9) { ... //float var11 = var7.totalPathDistance + var7.distanceSquaredTo(var10); float var11 = var7.totalPathDistance + var7.distanceTo(var10); // FIX if (!var10.isAssigned() || var11 < var10.totalPathDistance) { //var10.distanceToNext = var10.distanceSquaredTo(endPoint); var10.distanceToNext = var10.distanceTo(endPoint); // FIX ...
And just an optimization, though might actually work for worse, I didn't profile any better than by watching CPU-load, which didn't change in any observable amount, and by console log showing that the game stopped doing tons of grows:
...
// Just changing the initial size to something that reduces the number of grows to
// a tiny fraction.
private transient IntHashMapEntry[] slots = new IntHashMapEntry[128]; // Was 16
...
private int threshold = 96;
...
private Set keySet = new HashSet(128);
Conclusion
Although I consider the issue fixed with those changes, it would still be good to get some feedback, especially confirmations from those who can test them.
P.S. This is not the only issue with the same math mistake, doing +/- with squared distances. See MC-7200. EDIT2: that other issue actually is a bug, while this one apparently wasn't.
EDIT2: Back to square two.
See attached screenshot.
Seed: 2471375372774434640
/execute in minecraft:overworld run tp @s 721.71 25.74 60.22 -49.05 9.15
Potentially the same issue as, or related to, MC-7200.
Careful with the terms.. In this particular case, it belongs to the category of being a bug that is (was) accepted (by Mojang) as (more or less) permanent feature. (An issue can be both, a bug, and a feature, i.e "Won't Fix".) Note also the use of quotes around the word "feature" in earlier comment by Nathan Adams. (It was certainly nice that those particles have been added there, giving a warning about its volatile nature.)
(The part of "been in the game since forever" is one of the common, yet very bad reasons for stating something is not a bug. Been in the game for long might indicate, or at least correlate, on it being a feature (or at least accepted as "wont fix"/"feature"), but... For example, see MC-7200. It is a very obvious bug (incorrect math), been there for around 9 years.)
Btw. my earlier comment about noting to see Dinnerbone's comment (in MC-610).. no idea, I couldn't myself find such any more. However, Nathan Adams once upon a time (2013) resolved it by using state "Won't fix", which implies it being a bug, but just accepted to stay as a "feature"...
... Until years later, Mojang decided to reopen it (meaning they have intent to work at least on some part of it), with priority "important". Does not sound to me like it being a fully accepted "feature" at that point. The problem is, as usual with Mojang, they don't bother much with looking at linked issues, and end up resolving them in different ways. (Or not resolving at all, compare MC-7196 and MC-7200 case, frigging same classes, even same methods, fixes provided, issues linked, and they fix just the other one ><). MC-610 was marked "Won't fix", this one "Working as intended", even though it was clear that both should have been handled the same. And later, MC-610 was reopened, this one was not.
Note, the generic root cause for most of these floating stuff -related issues are sort of same, even if the technical mechanism might have slightly different ways in leaving the floating something in the world. Thus, I'd assume that if Mojang considers one floating weird to be worthy of fixing, they might consider all of them... if they just remembered to look at the linked issues.
Thank you for your report!
We're tracking this issue in MC-7200, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature in the future to see if the issue has already been reported.
Quick Links:
📓 Issue Guidelines – 💬 Community Support – 📧 Customer Support – ✍️ Feedback and Suggestions – 📖 Game Wiki
Probably the same issue as MC-7200
Thank you for your report!
We're tracking this issue in MC-7200, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
Possible duplicate of MC-7200?
Thank you for your report!
We're tracking this issue in MC-7200, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! Please report any issues on Discord or Reddit
Thank you for your report!
We're tracking this issue in MC-7200, so this ticket is being resolved and linked as a duplicate.
If you would like to add a vote and any extra information to the main ticket it would be appreciated.
If you haven't already, you might like to make use of the search feature to see if the issue has already been mentioned.
Quick Links:
📓 Bug Tracker Guidelines – 💬 Community Support – 📧 Mojang Support
📓 Project Summary – ✍️ Feedback and Suggestions – 📖 Game Wiki
– I am a bot. This action was performed automatically! Please report any issues on Discord or Reddit
![[Mod] Avoma](../../../data/avatars/users/86198.png){kind=small}
MC-7200 was resolved as fixed today, but it does not have a fix version. The fix version should be 21w37a. This is inconsistent with other reports that were resolved as fixed, which makes me believe the fix version was just forgotten.
The cave will be cut off by too straight sections,like MC-7200
New terrain generation.
Is this still a concern in the current Minecraft version 1.7.4 / Launcher version 1.3.9 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.Since this bug pretty much requires current source code (or the decompiled one) to be proven, and I seem to be unable to find recent enough MCP version, I can not confirm the status either way for now. However, I attached screenshots (and locations) for some very suspicious looking cuts in tunnels at coordinate divisible by 16 (the hallmark of this bug and couple already fixed ones), which should indicate that either this or some other unknown bug is still affecting.
cut1.png and cut2.png are from 1.7.5 as seen in the debug data of the screenshots. Same tunnels and cuts in same places in 14w11b.
This may be a problem of an invalid terrain generator but it also might be a cause of swap of MC versions that included a different terrain generator which usual happens after a terrain generator update (as for example seen here: http://fc07.deviantart.net/fs70/f/2011/144/d/2/minecraft_chunk_error_by_punkboi102-d3h5hdb.png). which is usual
Way of determaning if this is really a bug or not is to launch a new world and see if the problem remains or if it ocoures only on your older worlds.
The screenshots were taken in a world that were generated after the recent world generator changes (in fact in the latest versions, 1.7.5 or 14w11b). The cuts in those tunnels are only in the tunnel, and the terrain above those areas is completely ok/normal. Do note that I have actually dug this issue down into the source code level, and I've also debugged some of the actual chunk-error issues, so I do take care with trying to ensure I do not accidentally mix other issues to be the cause.
However, by now and in this case it is impossible to be 100% certain that no other cave/tunnel generation bug is doing those just by looking at the symptoms. In fact, to be certain, I'd need to do about 2 days of coding work (and have MCP for either 1.7.5 or 14w11b). I've done it once, but not going to do again, when fixing this would take about few minutes from Mojang. However, the odds are good enough on the side that Mojang hasn't fixed the code I've shown in the report, so I added the versions to affected list on the basis of those cuts I found. (There are more similar cave/tunnel cuts in the same seed and overall area, those just were first ones clear enough to take screenshots of.)
(EDIT: clarification, it takes few hours to make a new decompile and check the code whether it is fixed or not, but it takes that couple days of work to ensure that the exact piece of code is indeed responsible for the particular cuts. This is because the random number generator used needs to be switched to a tweaked one, or otherwise the cave/tunnel generation will change in general and makes confirmation impossible. If I could find my older version of this, I could do it faster... but its been almost 3 years, so finding the archived codes might take that saved time
)
Is this still a concern in the current Minecraft version? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases. If this has been done, we can reopen the issue.
Keep in mind that the "Resolved"-Status on this ticket just means "Answered", and that we are waiting for further information on whether this issue still exists or not. It will be reopened as soon as the requested information has been delivered.
If this is indeed the cause of several cut ravines and caves as well, then this does still exist in 1.14.4 van. on Win10/i7/16GB
Example:
Demo seed "North Carolina" or -343522682, F3-n, F3-g
/tp @s -48.42 18.94 0.10 -463.95 55.80
Can someone please check, if this still applies to 1.15.2 or the latest 1.16 development snapshot (currently that is 20w07a)?
Confirming code analysis on 20w07a. Obviously things are structured slightly differently today, but the check works the same way.
MC-167213- related bug (water caves don’t generate through land biomes)Can confirm in 21w14a.
The seeds provided have the caves next to an ocean, and that issue was already reported in
MC-124988,MC-125033,MC-172944.Do caves still stop generating in places that aren't near water?
The 1479112774635546442 examples had at least one case in orientation and distance from water that makes it unlikely to be caused of the water related bugs.
However, it seems that in 1.17 those seed examples are no longer valid or the bug has been fixed. One example cave/something in the above seed has completely vanished...
At least something related to cave carving has been fixed. Trying to check what exactly.
In the latest snapshot, I could not find the cuts described in the post. Is this still an issue?
I have been trying to find more examples of this particular bug (not near water), and I have only found so few "cuts" that they may very well be just random chance of cave shape matching chunk border, and nothing as obvious as they used to be.
Of course, the final confirmation is to look at the code, if it still has similar optimization; if it still subtracts squared distances or not...
In any case, this is no longer affecting the playing experience the way it used to. (At this point, I would not cry about resolving this as "fixed".)
I was also unable to find this kind of generation in 21w37a. The closest thing I found was
MC-237374, though this isn't the same as the behavior described in this ticket (MC-7200) becauseMC-237374isn't related to chunk borders.The straight walls at chunk borders were last generated in version 21w17a. The next 21w18a produced current nicer caves.