Ore generation height measurement is bugged

[talchas]

In CachedGridEntry findOptimalSpot returns the offset within a chunk that is closest to the the center of the grid, but the return value is used as if it is a global coordinate, not a chunk-relative one. This means that masterEntry is always set to the heights of one of 0,0/15,0/etc, not the height of a block in the chunk in question. This measurement is then used by doGenerateVein to completely eliminate veins early based on this height vs the vein's min_height and size. The most obvious result is that if the 0,0 chunk is deep ocean, any ore with too high of a min_height will never spawn anywhere in the world. With the default settings tin, tetrahedrite, salts, and several others can get hit by this fairly easily.

This bug is easy to fix, just add the missing chunk offset before asking the world for the height.

Even with this fixed there's still a lesser problem, which is that one height measurement is used to abort the entire vein generation, and this height measurement does not even come from inside of the grid cell that the vein is centered in. It usually comes from whichever chunk in whichever neighboring grid cell happens to be generated first, which then triggers CachedGridEntry creation of all its neighbors, but using the current chunk to guess the height. The height/GTWorldGenCapability isn't saved in any of the grid's chunks, so it will get replaced, but the CachedGridEntry and its veinGeneratedMap will remain with these first values until the server restarts.

So for anything next to ocean whether or not a vein gets generated can depend on what direction you are exploring from, since that determines the order chunks are generated in. If you were really careful, you could probably generate some chunks with one veinGeneratedMap, and then restart the server, go back there from a different direction and have a different veinGeneratedMap for generating other chunks in the same grid cell (The list of possible veins for the cell will remain the same, but the early exit of the first vein would also cause the location of any other veins to shift, since there are many more rng values consumed after the abort point).

Fixing this bug without just removing the early abort seems difficult, and that would increase the cost of generating grid cells where veins legitimately fail. Of course, at the moment due to the first bug, worlds either always have them fail or never, so it would be no worse than the current situation in worlds that aren't broken, and it isn't too slow now.

[LAGIdiot]

Thank you for reporting this problem to us. And providing us with all that data. This seems as serious problem and should be investigated soon. I will mark this as unverified until we have data from our side to prove your claims.

[Saereth]

Maybe just a config options for pack makers to set the height instead of it trying to determine it automatically. It's a work around and it's not exactly perfect but it would be performant and address the issue. If config value is 0 default to standard gt method otherwise use the override value this would theoretically be even more performant than gt's metho since it requires no additional calculations to determine the height and is instead just trusting the packdev to figure it out.

[Kaju-Bubanja]

I have also just experienced this issue in GregTech Community Edition 1.10.0.546. I'm playing ftb interactions where this bug happened. Deep ocean world at 0.0 chunk and I don't get any coal ore spawned. Also copper is VERY rare, I found 1 vein while exploring a lot between -10k,-10k and 10k, 10k coordinates. But coal doesn't spawn at all. At least not the plant indicating coal, coal in other veins does spawn. Was there any progress on this issue? According to previous poster on this issue it seems like there could be a "simple" fix.

[Kaju-Bubanja]

For people stumbling upon this. The fix is to fill out the 0,0 chunk with cobblestone(any block works) at y level 70 or higher. It will only affect newly generated chunks though.