I can't say for sure about the latest version but I modified 1.6.4 to generate 10,000 veins on layer 15 in chunk 0,0 with no other ores anywhere else, which resulted in a solid 17x17 area of diamond ore from 7,7 to 23,23 and 4 layers deep (layers 12 to 15), so it appears that veins extend to the north and west of their starting coordinate (ranging from 8,8 to 23,23, which is offset by +8 from the chunk coordinates*), and up to 3 layers below the starting y-coordinate:
*There is evidence that this offset is no longer present in newer versions but this just means that the same test would generate ore from -1 to 15; the reason for the offset in 1.6.4 is because the game only has to check if the chunks to the east and south are loaded before populating the center of a 2x2 chunk area, which allows features to extend up to 8 blocks outside of the center 16x16 area. Presumably, the game currently checks if a 3x3 chunk area is loaded and centers features within the center chunk.
For some reason I had the idea that it would be to the south and east, I was probably confusing it with the old 8 block chunk offset (which of course isn't the same thing at all). So when I came across two veins near each other, one inside the chunk and the other straddling the east border I got confused and wondered if I was misthinking or something.
Btw, is there a relatively simple description of how exactly ore veins are generated and how the "size" variable affects the actual numbers of ores?
There's a guy in the Wiki Talk page for Diamond Ore claiming that diamond veins only generate up to 8 ores based on running the ore generating subroutine (converted to C++) in a loop, outputting the numbers of "spheres" generated and claiming that "spheres" are single blocks.
Btw, is there a relatively simple description of how exactly ore veins are generated and how the "size" variable affects the actual numbers of ores?
There's a guy in the Wiki Talk page for Diamond Ore claiming that diamond veins only generate up to 8 ores based on running the ore generating subroutine (converted to C++) in a loop, outputting the numbers of "spheres" generated and claiming that "spheres" are single blocks.
I'm not sure what they did but I directly copied the code from the game (still in Java) and adapted it to read/write to a 16x16x16 array with the following results, counting actual blocks placed by counting 1s in the array (reset to 0s before generating each vein):
This is the code that I used; the ore generation code was modified to optimize it (there are a lot of redundant calculations) but it is functionally identical to vanilla (even the vanilla code took less than 10 seconds to generate 1 million size 8 veins, including counting up and clearing the 16x16x16 array each time, so I don't know why they used C++):
Notably, "average iterations" is the average number of times the innermost of 4 loops was executed; the outermost loop uses the "size" parameter while the inner three loops generate a spherical blob of blocks, which may each contain more than one block even for much smaller vein sizes; in fact, even lapis can have as many as 10 ores in a single vein in 1.6.4, which uses a size of only 6 (7 for diamond, with in-game proof that they do indeed generate up to 10 in a single vein - as far as I can tell such a vein configuration (a 2x2x2 cube with two additional blocks at diagonally opposite corners on the top and bottom) cannot be the result of two veins merged together and I've seen them appear in my simulated data):
Also, it is quite easy to debunk the Wiki's claims that larger veins like dirt/gravel/granite/andesite/diorite ("size 33") only have up to 33 blocks in a single vein - when they actually average 3-4 times larger with 50-150 blocks when fully generated (in this case you can easily tell if you've found a single vein because it will have a relatively uniform ovoid shape):
Dirt can generate in the Overworld in the form of mineral veins. Dirt attempts to generate 10 times per chunk in veins of size 1-33 at any level in all biomes.
I've also used 1.8's world customization and MCEdit to calculate the average size of veins of various sizes (these results are slightly lower than my simulations since veins may overlap):
Does your vein size table mean that the functions actually generate "veins" with no ores, even without overwriting and such?
Are veins that stick out of their chunks accounted for? With the 16X16X16 array. It makes no difference to me since I'm more interested in how veins are generated than in statistics.
What version of the game did your code come from and how much difference does it make?
Does your vein size table mean that the functions actually generate "veins" with no ores, even without overwriting and such?
Are veins that stick out of their chunks accounted for? With the 16X16X16 array. It makes no difference to me since I'm more interested in how veins are generated than in statistics.
What version of the game did your code come from and how much difference does it make?
Yes, there can be "veins" with no ores placed; chunks do not matter here since I generate them in the middle of a 16x16x16 cube so they never extend outside of it (which would crash the code as there are no bounds checks). The version is 1.6.4 (of course!) but I don't know how much may have changed since then; it does seem that the smallest vein sizes now actually work since 1.13 based on the information given here (in older versions sizes 1-2 do not generate any ores, as noted in the last link in my previous reply). Here is a table of the sizes found with each of the three methods (simulated using 1.6.4 code, generated in-game using 1.8's Customized, reported in MC-138946):
That said, I looked at the Talk page for diamond ore in the Wiki and the code they give looks quite different from 1.6.4, with multiple additional loops setting values in an array (the last one looks like the 4 nested loops that 1.6.4 has, but with much less code outside of them and taking values from an array that they initialize) and a separate method being called multiple times by the "generate" method:
Either way, if you can find veins that look like this even after removing the random offset applied to the x and z coordinates (I presume this requires a mod) then veins of 10 are still possible, and in either case some of the other information on the Wiki has to be incorrect, like dirt/gravel/granite/etc only having up to 33 blocks in a vein (or are they now much smaller than before? This reminds me of a major bug that affected 1.13 snapshots which greatly reduced the amounts of ores but it was supposed to have been fixed (the last comment claims that the 1.13 release still had over 40% less diamond than 1.12.2, well outside of the expected normal variation for even a 181x181 block area; this data seems suspect though since redstone was supposedly 33% more common in 1.13 despite only differing in vein count, likewise, gold (nearly doubled) and iron (nearly unchanged) should have the same relative abundance); I'm also curious as to what the average vein size they found was.
Basically as a matter of interest the code was recreated in CPP so I could cross-utilise some raytracing stuff I had setup.
Regardless, I recreated the test in Java so I could utilise the existing code in its exact form with no refactoring so it'd be as accurate as possible.
With this being the case, I ran 100 million cycles for every vein size between 0 and 50, but excluded veins that output 0 ores as that wasn't the goal of the test.
Unfortunately I believe the logging was cut off so I don't have vein sizes 1 & 2, but I might re-test someday for better output.
Note that this code is from 1.16.4, not sure if there's any differences in previous versions.
Results:
Vein Size: 3 Min Ores: 1 Max Ores: 4
Vein Size: 4 Min Ores: 1 Max Ores: 5
Vein Size: 5 Min Ores: 1 Max Ores: 8
Vein Size: 6 Min Ores: 1 Max Ores: 9
Vein Size: 7 Min Ores: 1 Max Ores: 10
Vein Size: 8 Min Ores: 1 Max Ores: 10
Vein Size: 9 Min Ores: 1 Max Ores: 13
Vein Size: 10 Min Ores: 1 Max Ores: 16
Vein Size: 11 Min Ores: 2 Max Ores: 17
Vein Size: 12 Min Ores: 2 Max Ores: 23
Vein Size: 13 Min Ores: 2 Max Ores: 24
Vein Size: 14 Min Ores: 2 Max Ores: 24
Vein Size: 15 Min Ores: 2 Max Ores: 29
Vein Size: 16 Min Ores: 4 Max Ores: 32
Vein Size: 17 Min Ores: 5 Max Ores: 37
Vein Size: 18 Min Ores: 6 Max Ores: 42
Vein Size: 19 Min Ores: 6 Max Ores: 50
Vein Size: 20 Min Ores: 10 Max Ores: 52
Vein Size: 21 Min Ores: 10 Max Ores: 60
Vein Size: 22 Min Ores: 12 Max Ores: 64
Vein Size: 23 Min Ores: 12 Max Ores: 68
Vein Size: 24 Min Ores: 15 Max Ores: 72
Vein Size: 25 Min Ores: 18 Max Ores: 80
Vein Size: 26 Min Ores: 22 Max Ores: 90
Vein Size: 27 Min Ores: 19 Max Ores: 98
Vein Size: 28 Min Ores: 26 Max Ores: 104
Vein Size: 29 Min Ores: 28 Max Ores: 112
Vein Size: 30 Min Ores: 30 Max Ores: 126
Vein Size: 31 Min Ores: 32 Max Ores: 132
Vein Size: 32 Min Ores: 36 Max Ores: 140
Vein Size: 33 Min Ores: 36 Max Ores: 153
Vein Size: 34 Min Ores: 42 Max Ores: 167
Vein Size: 35 Min Ores: 46 Max Ores: 180
Vein Size: 36 Min Ores: 56 Max Ores: 196
Vein Size: 37 Min Ores: 54 Max Ores: 204
Vein Size: 38 Min Ores: 63 Max Ores: 213
Vein Size: 39 Min Ores: 66 Max Ores: 229
Vein Size: 40 Min Ores: 74 Max Ores: 249
Vein Size: 41 Min Ores: 86 Max Ores: 264
Vein Size: 42 Min Ores: 89 Max Ores: 288
Vein Size: 43 Min Ores: 98 Max Ores: 292
Vein Size: 44 Min Ores: 109 Max Ores: 312
Vein Size: 45 Min Ores: 110 Max Ores: 326
Vein Size: 46 Min Ores: 122 Max Ores: 341
Vein Size: 47 Min Ores: 132 Max Ores: 361
Vein Size: 48 Min Ores: 143 Max Ores: 381
Vein Size: 49 Min Ores: 151 Max Ores: 402
Vein Size: 50 Min Ores: 162 Max Ores: 432
So this confirms the 1-10 ores per vein for size 8 (as diamond uses)
I must have made a mistake somewhere in the CPP port, so we can dismiss that as being outright wrong
Test under real-world conditions. I.E. Test the exact code, ingame, in real worlds, randomly generated.
Test with absolutely no modifications to the underlying code at all. This is to ensure no mistakes were made in refactoring
Record all results as a function of the output of per-chunk worldgen. This means that failure to generate a vein in a chunk was also recorded as a 0-ore vein. This gives real-world results in a reliable range for the average user's purposes.
Test under real-world conditions. I.E. Test the exact code, ingame, in real worlds, randomly generated.
Test with absolutely no modifications to the underlying code at all. This is to ensure no mistakes were made in refactoring
Record all results as a function of the output of per-chunk worldgen. This means that failure to generate a vein in a chunk was also recorded as a 0-ore vein. This gives real-world results in a reliable range for the average user's purposes.
What was the altitude range you used? Many of your results, other than diamond/redstone, seem low when compared to a real-world analysis I once did for a 1.8 snapshot after I noticed that ores seemed to be more common than in earlier versions; the area covered was only 1000 chunks but due to the nature of ore generation I wouldn't expect very large differences outside of land vs ocean (for coal/iron):
Note that the value in parenthesis for ores/vein for coal assumes an average of 10 veins in the lower 64 layers of its range (128 layers, I only analyzed the lower 64 layers to minimize effects of terrain variations above sea level). Lapis is also an oddity (smaller vein size but more ores/vein than diamond) since it has a different altitude distribution which reduces losses due to bedrock.
Also, I noticed that all of your results indicate a maximum vein size of 9 for a size of 6, while I get 10 (I've also found a few lapis veins this large in-game in 1.6.4, which uses a size of 6); there does seem to have been a slight change in the code in 1.8, as mentioned in a comment in the aforementioned thread, which is presumably why they increased the size of veins by one, which more than offset the loss of one of the "blobs":
So in 1.7.9, there are "size" cubes distributed along the line. In 14w21b the line is longer in the horizontal plane due to the increased "size", but the last of the "size" cubes that would be there is skipped so there are still the same number of cubes distributed over the same horizontal distance (but not in exactly the same positions) as in 1.7.9. But the maximum size of each cube is a bit larger, and the truncated sine wave might make a difference too.
The feature itself was an exact copy of Diamond. So the range and other values are identical to diamond ore, with all the rest of the data being contained within the code in the link provided.
Keeping in mind my averages are per _attempt_ to generate veins. So every time the feature is called to generate, it logs its result, successful or not.
This lowers the average overall because 0-veins will be counted as well, lowering the overall average.
I went with this approach because it provided the most accurate real-world results for what we'd see ingame
Because I only used a copy of diamond however, it's likely to provide slightly different results to the other ore features, because those use slightly different placement values, and attempting to generate multiple veins per chunk can cause differences as well, whereas diamond only runs once.
Other than that, I don't see how those results could be too off, they're an exact copy of diamond ore & MC's oregen code in 1.16.4, just with some wrapper to handle data collection instead of actually placing the veins in world.
EDIT: I should note that this _was_ a real-world test.
I literally just made a feature that instead of placing blocks, counted them. Then I went into 6 different worlds and had it collect data
Because I only used a copy of diamond however, it's likely to provide slightly different results to the other ore features, because those use slightly different placement values, and attempting to generate multiple veins per chunk can cause differences as well, whereas diamond only runs once.
This is still highly misleading though and can only be applied to ores using the same range as diamond since a large fraction of diamond is lost in bedrock (in particular, veins starting on layer 0 never generate at all) - from my own and others measurements of actual world generation there is a lot more coal and most other ores than your results would indicate; you got an average vein size of only 14.174 for coal (size 17) yet there is closer to 200 coal per chunk according to analysis of actual world generation, suggesting a vein size closer to 20; I can't check an actual 1.13+ world due to MCEdit not working on them but others have (IDK what tools they used, maybe WorldEdit?) and found results similar to 1.12:
The charts in the first link excluded air blocks but they only make up a few percent of the underground, so the ~1.3% of blocks being coal is consistent with the Wiki's chart for 1.12 showing around 1.2%. 1.2% of blocks over a 6.4 layer range (128 layers / 20 veins * 256 blocks per layer) is 19.66 ores per vein, 38.7% larger than your results. Likewise, iron averages about 0.7% of blocks over most of its range, with an average of 5.734 ore per vein based on 0.7% * 64 / 20 * 256 compared to your results of only 4.299 for size 9, a difference of 33%.
Think it'd require much more specific per-case testing for that kind of thing.
Either way my main thing was to check diamond for the diamond page, which I've pretty much accomplished, the other data was just for sake of interest for identical gen w/ different values.
Generation very obviously varies based on numerous other conditions, and so I don't intend for those results to be representative of any other ores or conditions.
Hopefully I'm not mis-reading here or there, but from Diamond Ore page:
On average they generate 3.7 ores per chunk. As of Java Edition 1.16.4, on average they generate 3.4 ores per chunk.
I think one of the tests you all had was for 1.16.4, giving 3.6 per chunk, but prior to accounting for some factors? Post-accounting for said factors, would the wiki still hold? If not, maybe you'd wanna either correct the wiki or extra-check the testing, whichever side is awry?
If I may ask the question that led me to browse around in the first place: According to this quite old Reddit thread, ores can generate while being distant by one block on two axes. Does this still hold? Also, is it (or was it ever) able to generate one block far on all three axes?
If I may ask the question that led me to browse around in the first place: According to this quite old Reddit thread, ores can generate while being distant by one block on two axes. Does this still hold? Also, is it (or was it ever) able to generate one block far on all three axes?
Forward thanks.
- KitCat.
Diamond veins can definitely generate with some of the ores connected diagonally. (Like A and B in the reddit post.)
I don't think they can generate completely separated (except maybe if separated by air/water/lava)
Diamond veins could only be separated vertically since they are only 2 blocks wide.
I don't have any statistics to back this up but I have long since changed my tactics for digging around diamond veins to avoid missing any based om my experience.
If the main 2X2X2 lump contains any stone I will mine that so I can see if either of the 2 1X1X1 lumps are there on the top or bottom (if all the ores in the main lump are in a single 1X2X2 plane then I dig out a 1X2X2 plane of rock for a total of 3X2X2) but if I have removed a 2X2X2 (or 3X2X2) block of ore/rock I don't bother digging up or down to see if there is a single ore above the "ceiling" or below the "floor".
--
That was probably pretty confused, what I mean is that if I find ores in 2 layers, I will make sure I have dug out all of the 8 blocks in those layers that could be part of the vein, then I'll look at the 4 blocks above and the four blocks below to see if they are diamond ore but if those 8 blocks are stone I won't bother mining them to see if there is a diamond ore above or below them.
I've just mined so many veins where that wasn't the case that I consider it a waste of time.
(Even if I were wrong it could never be more than 1 ore anyway.)
So, I'm wondering how diamond veins generate, specifically, if they stick out of their own chunk, on which sides of the chunk can they do so?
Just testing.
I can't say for sure about the latest version but I modified 1.6.4 to generate 10,000 veins on layer 15 in chunk 0,0 with no other ores anywhere else, which resulted in a solid 17x17 area of diamond ore from 7,7 to 23,23 and 4 layers deep (layers 12 to 15), so it appears that veins extend to the north and west of their starting coordinate (ranging from 8,8 to 23,23, which is offset by +8 from the chunk coordinates*), and up to 3 layers below the starting y-coordinate:
*There is evidence that this offset is no longer present in newer versions but this just means that the same test would generate ore from -1 to 15; the reason for the offset in 1.6.4 is because the game only has to check if the chunks to the east and south are loaded before populating the center of a 2x2 chunk area, which allows features to extend up to 8 blocks outside of the center 16x16 area. Presumably, the game currently checks if a 3x3 chunk area is loaded and centers features within the center chunk.
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Thank you very much!
For some reason I had the idea that it would be to the south and east, I was probably confusing it with the old 8 block chunk offset (which of course isn't the same thing at all). So when I came across two veins near each other, one inside the chunk and the other straddling the east border I got confused and wondered if I was misthinking or something.
Just testing.
Btw, is there a relatively simple description of how exactly ore veins are generated and how the "size" variable affects the actual numbers of ores?
There's a guy in the Wiki Talk page for Diamond Ore claiming that diamond veins only generate up to 8 ores based on running the ore generating subroutine (converted to C++) in a loop, outputting the numbers of "spheres" generated and claiming that "spheres" are single blocks.
Just testing.
I'm not sure what they did but I directly copied the code from the game (still in Java) and adapted it to read/write to a 16x16x16 array with the following results, counting actual blocks placed by counting 1s in the array (reset to 0s before generating each vein):
This is the code that I used; the ore generation code was modified to optimize it (there are a lot of redundant calculations) but it is functionally identical to vanilla (even the vanilla code took less than 10 seconds to generate 1 million size 8 veins, including counting up and clearing the 16x16x16 array each time, so I don't know why they used C++):
Notably, "average iterations" is the average number of times the innermost of 4 loops was executed; the outermost loop uses the "size" parameter while the inner three loops generate a spherical blob of blocks, which may each contain more than one block even for much smaller vein sizes; in fact, even lapis can have as many as 10 ores in a single vein in 1.6.4, which uses a size of only 6 (7 for diamond, with in-game proof that they do indeed generate up to 10 in a single vein - as far as I can tell such a vein configuration (a 2x2x2 cube with two additional blocks at diagonally opposite corners on the top and bottom) cannot be the result of two veins merged together and I've seen them appear in my simulated data):
Also, it is quite easy to debunk the Wiki's claims that larger veins like dirt/gravel/granite/andesite/diorite ("size 33") only have up to 33 blocks in a single vein - when they actually average 3-4 times larger with 50-150 blocks when fully generated (in this case you can easily tell if you've found a single vein because it will have a relatively uniform ovoid shape):
Vein size: 33
(no veins with 0-49 ores were found)
Ores: 50; count: 1
Ores: 51; count: 0
Ores: 52; count: 0
Ores: 53; count: 0
Ores: 54; count: 1
Ores: 55; count: 0
Ores: 56; count: 2
Ores: 57; count: 0
Ores: 58; count: 1
Ores: 59; count: 4
Ores: 60; count: 7
Ores: 61; count: 3
Ores: 62; count: 8
Ores: 63; count: 6
Ores: 64; count: 18
Ores: 65; count: 8
Ores: 66; count: 28
Ores: 67; count: 14
Ores: 68; count: 60
Ores: 69; count: 34
Ores: 70; count: 97
Ores: 71; count: 61
Ores: 72; count: 145
Ores: 73; count: 98
Ores: 74; count: 233
Ores: 75; count: 147
Ores: 76; count: 338
Ores: 77; count: 244
Ores: 78; count: 541
Ores: 79; count: 367
Ores: 80; count: 817
Ores: 81; count: 515
Ores: 82; count: 1159
Ores: 83; count: 798
Ores: 84; count: 1758
Ores: 85; count: 1120
Ores: 86; count: 2396
Ores: 87; count: 1542
Ores: 88; count: 3509
Ores: 89; count: 2180
Ores: 90; count: 4637
Ores: 91; count: 3017
Ores: 92; count: 6636
Ores: 93; count: 3930
Ores: 94; count: 8698
Ores: 95; count: 5078
Ores: 96; count: 11956
Ores: 97; count: 6684
Ores: 98; count: 15318
Ores: 99; count: 8662
Ores: 100; count: 19997
Ores: 101; count: 10626
Ores: 102; count: 25035
Ores: 103; count: 12993
Ores: 104; count: 31459
Ores: 105; count: 15822
Ores: 106; count: 37316
Ores: 107; count: 18440
Ores: 108; count: 45026
Ores: 109; count: 21395
Ores: 110; count: 49930
Ores: 111; count: 23543
Ores: 112; count: 55967
Ores: 113; count: 25212
Ores: 114; count: 57124
Ores: 115; count: 26267
Ores: 116; count: 57668
Ores: 117; count: 26224
Ores: 118; count: 53408
Ores: 119; count: 25095
Ores: 120; count: 48439
Ores: 121; count: 22592
Ores: 122; count: 39188
Ores: 123; count: 19074
Ores: 124; count: 31119
Ores: 125; count: 15769
Ores: 126; count: 21965
Ores: 127; count: 12082
Ores: 128; count: 15342
Ores: 129; count: 8751
Ores: 130; count: 9476
Ores: 131; count: 5817
Ores: 132; count: 5563
Ores: 133; count: 3671
Ores: 134; count: 3095
Ores: 135; count: 2034
Ores: 136; count: 1592
Ores: 137; count: 1025
Ores: 138; count: 771
Ores: 139; count: 456
Ores: 140; count: 298
Ores: 141; count: 198
Ores: 142; count: 110
Ores: 143; count: 61
Ores: 144; count: 52
Ores: 145; count: 18
Ores: 146; count: 9
Ores: 147; count: 3
Ores: 148; count: 3
Ores: 149; count: 2
Ores: 150; count: 1
Ores: 151; count: 1
Average vein size: 112.92284; average iterations: 964.39954
I've also used 1.8's world customization and MCEdit to calculate the average size of veins of various sizes (these results are slightly lower than my simulations since veins may overlap):
How "spawn size" correlates to actual vein size of ores
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Thanks again!
Still curious,
Does your vein size table mean that the functions actually generate "veins" with no ores, even without overwriting and such?
Are veins that stick out of their chunks accounted for? With the 16X16X16 array. It makes no difference to me since I'm more interested in how veins are generated than in statistics.
What version of the game did your code come from and how much difference does it make?
Just testing.
Yes, there can be "veins" with no ores placed; chunks do not matter here since I generate them in the middle of a 16x16x16 cube so they never extend outside of it (which would crash the code as there are no bounds checks). The version is 1.6.4 (of course!) but I don't know how much may have changed since then; it does seem that the smallest vein sizes now actually work since 1.13 based on the information given here (in older versions sizes 1-2 do not generate any ores, as noted in the last link in my previous reply). Here is a table of the sizes found with each of the three methods (simulated using 1.6.4 code, generated in-game using 1.8's Customized, reported in MC-138946):
That said, I looked at the Talk page for diamond ore in the Wiki and the code they give looks quite different from 1.6.4, with multiple additional loops setting values in an array (the last one looks like the 4 nested loops that 1.6.4 has, but with much less code outside of them and taking values from an array that they initialize) and a separate method being called multiple times by the "generate" method:
https://pastebin.com/kgjt1Nye
Either way, if you can find veins that look like this even after removing the random offset applied to the x and z coordinates (I presume this requires a mod) then veins of 10 are still possible, and in either case some of the other information on the Wiki has to be incorrect, like dirt/gravel/granite/etc only having up to 33 blocks in a vein (or are they now much smaller than before? This reminds me of a major bug that affected 1.13 snapshots which greatly reduced the amounts of ores but it was supposed to have been fixed (the last comment claims that the 1.13 release still had over 40% less diamond than 1.12.2, well outside of the expected normal variation for even a 181x181 block area; this data seems suspect though since redstone was supposedly 33% more common in 1.13 despite only differing in vein count, likewise, gold (nearly doubled) and iron (nearly unchanged) should have the same relative abundance); I'm also curious as to what the average vein size they found was.
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
The person they're talking about is me -
Basically as a matter of interest the code was recreated in CPP so I could cross-utilise some raytracing stuff I had setup.
Regardless, I recreated the test in Java so I could utilise the existing code in its exact form with no refactoring so it'd be as accurate as possible.
You can see my approach here:
https://pastebin.com/fR07c5En
With this being the case, I ran 100 million cycles for every vein size between 0 and 50, but excluded veins that output 0 ores as that wasn't the goal of the test.
Unfortunately I believe the logging was cut off so I don't have vein sizes 1 & 2, but I might re-test someday for better output.
Note that this code is from 1.16.4, not sure if there's any differences in previous versions.
Results:
So this confirms the 1-10 ores per vein for size 8 (as diamond uses)
I must have made a mistake somewhere in the CPP port, so we can dismiss that as being outright wrong
Developer of Advent of Ascension
Come chat with us in the official Discord server!
Please consider supporting my development on Patreon. You might even get some little goodies in return
https://www.patreon.com/Tslat
Alright as a further matter of interest I did a more comprehensive test, this time just for vein sizes 0-20.
Hopefully this is more enlightening for the topic:
Code here: https://pastebin.com/LA3VSrXZ
Results here: https://pastebin.com/HDZn1i3v
So the conditions for this test were;
Developer of Advent of Ascension
Come chat with us in the official Discord server!
Please consider supporting my development on Patreon. You might even get some little goodies in return
https://www.patreon.com/Tslat
What was the altitude range you used? Many of your results, other than diamond/redstone, seem low when compared to a real-world analysis I once did for a 1.8 snapshot after I noticed that ores seemed to be more common than in earlier versions; the area covered was only 1000 chunks but due to the nature of ore generation I wouldn't expect very large differences outside of land vs ocean (for coal/iron):
Note that the value in parenthesis for ores/vein for coal assumes an average of 10 veins in the lower 64 layers of its range (128 layers, I only analyzed the lower 64 layers to minimize effects of terrain variations above sea level). Lapis is also an oddity (smaller vein size but more ores/vein than diamond) since it has a different altitude distribution which reduces losses due to bedrock.
Also, I noticed that all of your results indicate a maximum vein size of 9 for a size of 6, while I get 10 (I've also found a few lapis veins this large in-game in 1.6.4, which uses a size of 6); there does seem to have been a slight change in the code in 1.8, as mentioned in a comment in the aforementioned thread, which is presumably why they increased the size of veins by one, which more than offset the loss of one of the "blobs":
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
The feature itself was an exact copy of Diamond. So the range and other values are identical to diamond ore, with all the rest of the data being contained within the code in the link provided.
Keeping in mind my averages are per _attempt_ to generate veins. So every time the feature is called to generate, it logs its result, successful or not.
This lowers the average overall because 0-veins will be counted as well, lowering the overall average.
I went with this approach because it provided the most accurate real-world results for what we'd see ingame
Because I only used a copy of diamond however, it's likely to provide slightly different results to the other ore features, because those use slightly different placement values, and attempting to generate multiple veins per chunk can cause differences as well, whereas diamond only runs once.
Other than that, I don't see how those results could be too off, they're an exact copy of diamond ore & MC's oregen code in 1.16.4, just with some wrapper to handle data collection instead of actually placing the veins in world.
EDIT: I should note that this _was_ a real-world test.
I literally just made a feature that instead of placing blocks, counted them. Then I went into 6 different worlds and had it collect data
Developer of Advent of Ascension
Come chat with us in the official Discord server!
Please consider supporting my development on Patreon. You might even get some little goodies in return
https://www.patreon.com/Tslat
This is still highly misleading though and can only be applied to ores using the same range as diamond since a large fraction of diamond is lost in bedrock (in particular, veins starting on layer 0 never generate at all) - from my own and others measurements of actual world generation there is a lot more coal and most other ores than your results would indicate; you got an average vein size of only 14.174 for coal (size 17) yet there is closer to 200 coal per chunk according to analysis of actual world generation, suggesting a vein size closer to 20; I can't check an actual 1.13+ world due to MCEdit not working on them but others have (IDK what tools they used, maybe WorldEdit?) and found results similar to 1.12:
https://www.reddit.com/r/Minecraft/comments/bn00cf/ore_distributions_for_specific_biomes/
https://bugs.mojang.com/browse/MC-126373?focusedCommentId=488032&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-488032 (about 198 coal and 105 iron per chunk in 1.13; only the lower 64 layers, averaging 10 veins, was analyzed. I'm not sure what is going on with gold/redstone/diamond in 1.13 but the results for 1.12 look normal)
The charts in the first link excluded air blocks but they only make up a few percent of the underground, so the ~1.3% of blocks being coal is consistent with the Wiki's chart for 1.12 showing around 1.2%. 1.2% of blocks over a 6.4 layer range (128 layers / 20 veins * 256 blocks per layer) is 19.66 ores per vein, 38.7% larger than your results. Likewise, iron averages about 0.7% of blocks over most of its range, with an average of 5.734 ore per vein based on 0.7% * 64 / 20 * 256 compared to your results of only 4.299 for size 9, a difference of 33%.
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Interesting.
Think it'd require much more specific per-case testing for that kind of thing.
Either way my main thing was to check diamond for the diamond page, which I've pretty much accomplished, the other data was just for sake of interest for identical gen w/ different values.
Generation very obviously varies based on numerous other conditions, and so I don't intend for those results to be representative of any other ores or conditions.
Developer of Advent of Ascension
Come chat with us in the official Discord server!
Please consider supporting my development on Patreon. You might even get some little goodies in return
https://www.patreon.com/Tslat
Hopefully I'm not mis-reading here or there, but from Diamond Ore page:
I think one of the tests you all had was for 1.16.4, giving 3.6 per chunk, but prior to accounting for some factors? Post-accounting for said factors, would the wiki still hold? If not, maybe you'd wanna either correct the wiki or extra-check the testing, whichever side is awry?
If I may ask the question that led me to browse around in the first place: According to this quite old Reddit thread, ores can generate while being distant by one block on two axes. Does this still hold? Also, is it (or was it ever) able to generate one block far on all three axes?
Forward thanks.
- KitCat.
Diamond veins can definitely generate with some of the ores connected diagonally. (Like A and B in the reddit post.)
I don't think they can generate completely separated (except maybe if separated by air/water/lava)
Diamond veins could only be separated vertically since they are only 2 blocks wide.
I don't have any statistics to back this up but I have long since changed my tactics for digging around diamond veins to avoid missing any based om my experience.
If the main 2X2X2 lump contains any stone I will mine that so I can see if either of the 2 1X1X1 lumps are there on the top or bottom (if all the ores in the main lump are in a single 1X2X2 plane then I dig out a 1X2X2 plane of rock for a total of 3X2X2) but if I have removed a 2X2X2 (or 3X2X2) block of ore/rock I don't bother digging up or down to see if there is a single ore above the "ceiling" or below the "floor".
--
That was probably pretty confused, what I mean is that if I find ores in 2 layers, I will make sure I have dug out all of the 8 blocks in those layers that could be part of the vein, then I'll look at the 4 blocks above and the four blocks below to see if they are diamond ore but if those 8 blocks are stone I won't bother mining them to see if there is a diamond ore above or below them.
I've just mined so many veins where that wasn't the case that I consider it a waste of time.
(Even if I were wrong it could never be more than 1 ore anyway.)
Just testing.