MC-7196Nether cave/tunnel generator produces incorrect/cut tunnels
The tunnels/caves in Nether can have unnatural looking straight cuts/walls at chunk borders. The reason is an old bug that has been fixed from the overworld cave generator, but not from the Nether one. Such tunnels are easiest to find by using a mapper (due to the difficulty of moving in Nether, low visibility, and of course because tunnels/caves are usually more or less buried inside solid stuff).
Examples of buggy tunnels
See map screenshots; the straight edges of the tunnels are not due to mapping program, but simply because the tunnels have cuts in them, at chunk borders.
Possibly reproducible with world seed -807116175 (with defaults), location x:142, y:98, z:-83 in Nether (place of screenshot cut_tunnel_3 and ...02.24.27). The location is actually two tunnels, both cut at the same place, but just cut on different directions. (The other map screenshots are of the same world, locations are about #1: 187,99,135 and #2 131,94,260 + 60,85,235.)
The bug
Compare classes MapGenCaves and MapGenCavesHell. The overworld version (MapGenCaves) transfers a random generator seed-parameter in the methods, while the Nether-version does not. Due to this, for the Nether version the map generator's one common random number generator gets to different states at different chunks for the generation of the supposedly same tunnel/cave. The different states of course lead to different random shapes of the tunnel.
The fix
Adapt the use of the seed parameter from the MapGenCaves class to MapGenCavesHell class. (I will not show the code here, as the changes are quite spread and are trivial.)
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).
Linked Issues
Created Issue:
Nether cave/tunnel generator produces incorrect/cut tunnels
The tunnels/caves in Nether can have unnatural looking straight cuts/walls at chunk borders. The reason is an old bug that has been fixed from the overworld cave generator, but not from the Nether one. Such tunnels are easiest to find by using a mapper (due to the difficulty of moving in Nether, low visibility, and of course because tunnels/caves are usually more or less buried inside solid stuff).
Examples of buggy tunnels
See map screenshots; the straight edges of the tunnels are not due to mapping program, but simply because the tunnels have cuts in them, at chunk borders.Possibly reproducible with world seed -807116175 (with defaults), location x:142, y:98, z:-83 in Nether (place of screenshot cut_tunnel_3 and ...02.24.27). The location is actually two tunnels, but cut at the same place, but just cut on different directions. (The other map screenshots are of the same world, locations are about #1: 187,99,135 and #2 131,94,260 + 60,85,235.)
The bug
Compare classes MapGenCaves and MapGenCavesHell. The overworld version (MapGenCaves) transfers a random generator seed-parameter in the methods, while the Nether-version does not. Due to this, for the Nether version the map generator's one common random number generator gets to different states at different chunks for the generation of the supposedly same tunnel/cave. The different states of course lead to different random shapes of the tunnel.The fix
Adapt the use of the seed parameter from the MapGenCaves class to MapGenCavesHell class. (I will not show the code here, as the changes are quite spread and are trivial.)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).
Attachments4
relates to
The tunnels/caves in Nether can have unnatural looking straight cuts/walls at chunk borders. The reason is an old bug that has been fixed from the overworld cave generator, but not from the Nether one. Such tunnels are easiest to find by using a mapper (due to the difficulty of moving in Nether, low visibility, and of course because tunnels/caves are usually more or less buried inside solid stuff).
Examples of buggy tunnels
See map screenshots; the straight edges of the tunnels are not due to mapping program, but simply because the tunnels have cuts in them, at chunk borders.Possibly reproducible with world seed -807116175 (with defaults), location x:142, y:98, z:-83 in Nether (place of screenshot cut_tunnel_3 and ...02.24.27). The location is actually two tunnels, b
utcut at the same place, but just cut on different directions. (The other map screenshots are of the same world, locations are about #1: 187,99,135 and #2 131,94,260 + 60,85,235.)The bug
Compare classes MapGenCaves and MapGenCavesHell. The overworld version (MapGenCaves) transfers a random generator seed-parameter in the methods, while the Nether-version does not. Due to this, for the Nether version the map generator's one common random number generator gets to different states at different chunks for the generation of the supposedly same tunnel/cave. The different states of course lead to different random shapes of the tunnel.The fix
Adapt the use of the seed parameter from the MapGenCaves class to MapGenCavesHell class. (I will not show the code here, as the changes are quite spread and are trivial.)The tunnels/caves in Nether can have unnatural looking straight cuts/walls at chunk borders. The reason is an old bug that has been fixed from the overworld cave generator, but not from the Nether one. Such tunnels are easiest to find by using a mapper (due to the difficulty of moving in Nether, low visibility, and of course because tunnels/caves are usually more or less buried inside solid stuff).
Examples of buggy tunnels
See map screenshots; the straight edges of the tunnels are not due to mapping program, but simply because the tunnels have cuts in them, at chunk borders.Possibly reproducible with world seed -807116175 (with defaults), location x:142, y:98, z:-83 in Nether (place of screenshot cut_tunnel_3 and ...02.24.27). The location is actually two tunnels, both cut at the same place, but just cut on different directions. (The other map screenshots are of the same world, locations are about #1: 187,99,135 and #2 131,94,260 + 60,85,235.)
The bug
Compare classes MapGenCaves and MapGenCavesHell. The overworld version (MapGenCaves) transfers a random generator seed-parameter in the methods, while the Nether-version does not. Due to this, for the Nether version the map generator's one common random number generator gets to different states at different chunks for the generation of the supposedly same tunnel/cave. The different states of course lead to different random shapes of the tunnel.The fix
Adapt the use of the seed parameter from the MapGenCaves class to MapGenCavesHell class. (I will not show the code here, as the changes are quite spread and are trivial.)
![[Mojang] Jeb (Jens Bergensten)](../../../data/assets/gravatar/jeb.jpeg){kind=small}
[Mojang] Jeb (Jens Bergensten)![[Mod] Ezekiel (ezfe)](../../../data/assets/gravatar/ezekielelin.jpeg){kind=small}
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
relates to
(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.
May be related to MC-7196. That issue is a closed bug so a new report is needed.
When caves generate in the Nether below the lava level, the caves are not aligned correctly at chunk boundaries. This is easiest to see with an external mapper that can map the world at arbitrary y levels.
The attached screenshot was produced with an external mapper. Seed is 1, mapping the region file at 0,0 to 511,511, at y=16. The chunk boundaries are shown with a lighter colour at x,z mod 0 and mod 15.
The issue can be reproduced as far back as 1.13 and possibly earlier.
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.
Still valid for 13w09b, and even if there is new stuff in Nether, the example seed and location still works.
Fixed as suggested.
this bug used to happen on beta 1.7.3, but got fixed in beta 1.8 which is good as it got annoying.