I receive a large amount of lag when generating new terrain. And this probably is because I have 29 non vanilla ore types registered.

I am working on attempting to optimize WorldGenCustomOres.java and WorldGenMinableMod.java and I will create a pull request when I am done. I decided to make an issue so that you are aware I am working on optimizing them before struggling to do so yourself.

So an update, I have made pretty good progress on fixing the lag. According to the worldgeneration profile plugin in general each chunk takes about 30 ms down from 100 ms. I also found and fixed a bug introduced by e6db6ad where the default property group does not get set leading to all built in ores not spawning.

The ore generation is a bit different as I made the values more accurately obey vanilla spawnrates. Instead of attempting to spawn a vein of size x for each type of variant, it now attempts to spawn a vein of size x that can go from one variant to another. This makes it so that it does not get cut off and only spawns the total amount specified by the configurations while also cutting processing down significantly.

I am still working on it as there are some other things I can do to it. For example:

I am also going to change how the dense ores spawn to have a % chance of spawning a dense variant over a normal variant rather than going through the entire generation process again and replacing non dense variants with the dense variant. This should also cut down on the processing required as it will roughly half the calculations.

Thanks. Good work so far. I do actually have a slightly updated version of the default properties class that you were referring to that I just hadn't pushed yet. I've uploaded it here. The dense ore changes do make a lot of sense, but I'm not really sure what you mean about the second paragraph. I'm interested to see how things go.

The second paragraph is mainly saying that things like this: https://i.gyazo.com/18990332166de04ebfa37d27965eee8e.png is now possible. That is a single coal vein that continued instead of getting cut off where the stone changed to granite and diorite. This means I only have to attempt to spawn it once instead of worrying about attempting to spawn a vein in each different type of stone.

Ahh. I see. Definitely looks nicer.

I have it working now. It is not perfect but it is extremely smooth compared to how it was before. I am going to take a quick look to see if I can figure out how to fix the other issue I had posted.

One other thing of note is that my console gets spammed with
[17:33:57] [main/INFO] [STDERR]: [personthecat.mod.objects.blocks.BlockOresBase:getNormalRedstoneVariant:337]: Error: tried to retrieve normal redstone from an invalid candidate. Returning null. This was also happening before I modified the world gen at all. Would you like me to create a separate issue for it or do you just want to look into it after I create a pull request for the world gen performance improvements.

Either way. I noticed that as well, though. I changed it to print which parent block it was trying to retrieve a variant from and yet I'm still not really sure why it happens. I'm my case, it hasn't been spam, but only happens occasionally. And I still don't see a link. Feel free to open another issue, but I am aware of this and will keep looking into it, regardless.

Edit: I've just tried generating a new world, though, and after several minutes, I still haven't seen that error again. I've definitely seen it before, but it's not very common in my case.

Pull made I could not figure out how to fix #17 other than it seems that it is an issue with the ZipFile being open when it attempts to save some normal overlays. (My guess is due to saving the blended and non blended back to back that rarely it overlaps.) This then causes the normal overlay to not exist so the dense variant cannot find the base texture.

I took another look at your crash report from the last issue and noticed you were using Thermal Foundation. That has been known to cause issues basically since I added it, unfortunately. I still haven't really been able to figure out why. Definitely try without using that mod to verify if there's a difference first, but regardless, I appreciate it quite a bit and am anxious to see how it goes.

Having tested this for a bit, everything seems to work as it should. I appreciate the effort put into consolidating normal and dense generation. It seems obvious looking at it now, but that was actually pretty clever. I've only made pointless changes to the formatting, for now. Most importantly, the performance has seen a notable improvement.

I did test with Thermal Foundation, which to me still seems to not play nicely with OSV, but the experience is now far superior. Upon exploration, I was able to produce at least one crash, but the stacktrace did not point to OSV. I may still need to investigate this to find out if it could somehow be the culprit.

One change I might make stems from your commentary about having individual ratios for dense variants to spawn. I may change the code to use a multiple which it retrieves from each WorldGenProperties object, but leave them all the same until I can write the keys for them or so.

A final note is that I've reverted the changes made to the build file. While the mod was originally written for 1.12.2, that was shortly changed per-request of at least one user. I feel it makes sense to continue using the dated version for best compatibility until we run into roadblocks.

Thanks again for all of your effort and contribution! I'm both impressed and, again, very appreciative.

Edit: Nice.

The mappings field snapshot_20180622 is for 1.12 not even 1.12.1 or 1.12.2 so it should not matter that I updated. What forge mappings do is map the obfuscated code into unobfuscated names and back so that it is easier to read the code. The reobfuscated code uses the same methods for each of the versions based on the mapping.

Also nice picture it does do a good job of showing how it now spawns one vein cross blocks.

Ahh, I see. I guess I was mainly just focusing on version = "1.12.2-14.23.4.2709". Damn Forge. I wasn't aware there could be a mismatch / that there are no matches. Cool.