quark: 1.11.2-Quark-r1.2-90
forge:1.11.2-2282
log containing issue:http://puu.sh/vp7wT/c3635f01af.log

Quark loaded a new chunk (12, 2 Dimension: 0) during chunk population, causing cascading worldgen lag. Please report this to the mod's issue tracker. This log can be disabled in the Forge config.
[18:27:36] [Server thread/WARN] [FML/]: Quark loaded a new chunk (12, 5 Dimension: 0) during chunk population, causing cascading worldgen lag. Please report this to the mod's issue tracker. This log can be disabled in the Forge config.
[18:27:37] [Server thread/WARN] [FML/]: Quark loaded a new chunk (14, 4 Dimension: 0) during chunk population, causing cascading worldgen lag. Please report this to the mod's issue tracker. This log can be disabled in the Forge config.
[18:27:38] [Server thread/DEBUG] [FML/]: Gathering id map for writing to world save New World

Vazkii Edit:

For a temporary fix and further info on this issue, please check the last comment.

I ended up removing quarks from basic tests. Sadly was using almost double the world gen times I assuming mostly caused due to runaway chunks. Both in 1.10.2 and 1.11.2.

Aslo getting this message while loading a server.

[Server thread/WARN] [FML]: Quark loaded a new chunk (26, 6 Dimension: 0) during chunk population, causing cascading worldgen lag. Please report this to the mod's issue tracker. This log can be disabled in the Forge config.

mezz fixed a similar issue in Actually Additions with Ellpeck/ActuallyAdditions#690 .

Here is an example of a simplex noise cloud being used to generate saltpeter deposits:
https://github.com/CovertJaguar/Railcraft/blob/0280b6013ae6ba553a0729e7daad05e7a9a041dc/src/main/java/mods/railcraft/common/worldgen/WorldGenSaltpeter.java#L53-L53

Here is a more complex three dimensional example using two layers of noise maps:
https://github.com/CovertJaguar/Railcraft/blob/8f4a4b0486e6a99679b10d8161976bc11ea2189a/src/main/java/mods/railcraft/common/worldgen/GeneratorMine.java#L129-L129

Now...I can't say for certain that my offsets are 100% correct, but the individual gen actions are no larger than vanilla ore veins even when generating features that span many chunks.

Vanilla has some noise generators you could tie into as well, but I never bothered to figure out how they worked.

Just stay away from vanilla Emerald World Gen 🤕

I believe the fix is incorrect. Some of the vanilla WorldGenerator implementations already apply the mandatory +8 offset internally, WorldGenMinable is one of them. The biome check however may want to use the offset to sample the center of the decoration.

The problem here is most likely that the feature size is too large, decorators may only touch 2x2 chunks. Considering the 16 block random offset, this leaves 16x16 blocks maximum for the feature, centered where the 4 chunks meet.

The best possible solution is splitting the generation to work like MC's base world generator, i.e. doing a chunk at a time based on top of a continuous 2d/3d noise function.

Alternatively decoration could be delayed similar to net.minecraft.world.chunk.Chunk.populateChunk(IChunkProvider, IChunkGenerator) with a larger area, e.g. checking 3x3 chunks and offsetting by 16 blocks instead of 8 for 32x32 max. feature size. Note that the flag isTerrainPopulated is essential for this to work, you'd need your own persisted flag or possibly check (IChunkProvider.getLoadedChunk() != null || AnvilChunkLoader.chunkExists()) instead of just IChunkProvider.getLoadedChunk() != null.

I recommend Simplex Noise functions.

I recommend checking this out:
https://www.reddit.com/r/feedthebeast/comments/5x0twz/investigating_extreme_worldgen_lag/

@mezz might be able to offer suggestions.

For worldgen bigger than 1 chunk size, you can use simplex noise or structures.

Covert has a good noise example already, it works well for ore distribution. Since it's kind of abstract you'll want to debug it by stripping all the dirt and stone away to look at what you generate, WorldStripper is good for that.

For big (larger than 1 chunk) structures, take a look at how the Ocean Monument is generated. It decides where in the world to try to create monuments ahead of time, so when a chunk in that area loads it will generate just that one chunk's part of the monument at a time.

Radfast from Galaticraft had this to say on the issue...

I think most mod developers don't really understand how Minecraft oregen works.

It's roughly like this.

Stage 1: chunks are generated with basic bedrock, rock, dirt and water, according to the heightmap

Stage 2: already generated chunks are "populated", but the vanilla Minecraft chunkprovider algorithm will only populate a chunk if at least 3 neighbors already populated, maybe it also depends which neighbors those are, you can study the vanilla code. (One exception is underwater temples which have a special rule.)

Therefore, a chunk can be generated but flagged not "populated".

Getting and setting blockstates in the world causes attempts to load those chunks, which causes generation of those chunks if not already generated.

Vanilla populate code - for example vanilla oregen - can use getting and setting to load chunks either side of the current chunk, so x and z in the range { -1, 0, 1 } from the current chunk's position. This is obviously necessary to build complete ore pockets or complete trees. But the oregen and tree code is carefully limited in the range it can cover, if you look at all the vanilla code you'll see it never strays more than around +/-20 blocks from the center of the current chunk. Therefore, it never triggers chunkgen outside the range { -1, 0, 1 }.

Because of the rule about only populating a chunk which has 3 populated neighbors already, this makes it impossible for vanilla worldgen to run away.

If any mod has code which gets or sets outside that tight range, it will cause runaway worldgen, simple as that.

I see Tinker's Construct slime islands mentioned in that code, as well as vanilla emerald gen. There's something about vanilla emerald gen which breaks these rules slightly, I don't remember it.

I found another link addressing this issue that might be more direct....
capnkirok/Inventory-Pets#170

"For any modders reading this:

Fix appears to be to offset your worldgen point to be the center of the chunk... so offset 8 to x and z coordinates so the world gen starts at the center and moves out. Otherwise you overlap with already generated chunks."

Edit: This is not a working solution, please see @sfPlayer1 's comment below.

@Endmateria I'm sorry, but you are not really helping here. Having to generally offset is wrong since some WorldGenerator implementations like WorldGenMineable already apply the offset internally. In this case it's just an excessive feature size going beyond the 4 chunks - with any offset. This issue already contains all relevant information.

@sfPlayer1 That's fine, I'm not a coder... just trying to direct the plethora of modders with cascading worldgen issues to the correct solution (which is a lot), so they don't have to mine up the info the hard way. If I quoted the wrong solution, then by all means correct me so that the others that are linked here see it and don't implement the wrong solution, which obviously seems to be the case on the issue link I just quoted from. Don't assume that everybody knows what you just explained.

I'm more then willing to generate multiple worlds if any logs are needed from some testing builds.

i found a few more mods you can add to the list
toroquest:ToroQuest loaded a new chunk (203, 59 Dimension: 0) during chunk population, causing cascading worldgen lag. Please report this to the mod's issue tracker. This log can be disabled in the Forge config.
inventory pets: Inventory Pets loaded a new chunk (219, 77 Dimension: 0) during chunk population, causing cascading worldgen lag. Please report this to the mod's issue tracker. This log can be disabled in the Forge config.
fml client latest: http://puu.sh/w89mv/288935571f.log
the mods mentioned above are in 1.11.2 using forge 1.11.2-2310
IP: inventorypets-1.11.2-1.4.9.5
TQ: toroquest-1.11.2-3.5

This issue is back for 1.12

21.06 08:48:48 [Server] Server thread/WARN [FML]: Quark loaded a new chunk (-4, 33 Dimension: 0) during chunk population, causing cascading worldgen lag. Please report this to the mod's issue tracker. This log can be disabled in the Forge config.

I am using this version of Quark

And this version of forge.

Current Server log
https://gist.github.com/P3rf3ctXZer0/48893fb3c17f2c1a84a3af470708038b

I just disabled most of the generation in the "world" section except for a couple of things I cared about (like clay underground) and I haven't had issues since. This is in 1.11.2 with the latest version of Quark as of today. When I revert to the default config the cascading is pretty severe.

Thanks Vazkii for working on this! I made the config changes mostly so I could keep Quark (which I really want) in my pack without the cascading. I wasn't trying to tell you something you probably already knew, just helping those who didn't know where in the config to tweak out the problem for now.

@TensorTime Thanks I will use that work around as well :)

I enjoy the marble and limestone in 1.12 as well as the new mobs. which specific config options would i disable to remedy the cascading lag but continue to use the features i enjoy?

I am locking this issue for now, as it pops up far too often with regurgitating that does not help it being solved at all.

I have looked into how to fix this,. I haven't managed to find a good way of doing it yet. If you want a temporary band aid, please check the previous comment.

If you're a modder and want to collaborate in fixing this, or know how to apply noise maps to the problem at hand, please send me a message on discord at http://vazkii.us/discord

Finally fixed in build 105!