Worldgen inner workings - how does vanilla oregen not freeze?

[radfast]

Hi guys, first post at minecraftforge.net so please be kind...

 

My question is this:

 

• The standard methods net.minecraft.world.World.getBlock() and net.minecraft.world.World.setBlock() act as temporary chunk loaders - meaning that if the chunk where the block is at is not loaded, then the chunk will be loaded so that the block can be got or set, and that in turn will involve a call to the ChunkProvider if the chunk was not generated before.

• The vanilla oregen method net.minecraft.world.gen.feature.WorldGenMinable.generate() calls World.getBlock() and World.setBlock() plenty, while creating a clump of ore blocks.

• Sometimes the vanilla oregen method will generate a clump of ore blocks close to the edge of the generated chunk, so that it will need to call World.getBlock() and World.setBlock() in the neighbouring chunk.
  

 

So you would think, while generating the Overworld, the server would get itself into a never- ending cycle, adding ores to a chunk, which triggers generation of the neighbouring chunk, which generates its own ore, triggering loading the next neighbouring chunk, and so on recursively ... maybe forever or at least until there is a stack overflow.

 

Why doesn't this happen?  Or maybe it does happen, but the recursion eventually stops when random chance produces a chunk which has none of its ores close to the chunk edges?

 

More explanation on getBlock() and setBlock() loading & generating chunks: see the vanilla methods World.getChunkFromChunkCoords() and ChunkProviderServer.provideChunk().

[GotoLink]

Well, generating ores is a decoration step. Chunks "base" (stone) look is already calculated by then.

There are also basic concurrency fail-fast protections. For example in BiomeDecorator.

[radfast]

That's great, thanks very much for the pointers.

 

I now see that in vanilla the call to the decorator is deferred until IChunkProvider.populate() is called from Chunk.populateChunk() - which very cleverly, only calls the populate() if at least three of the neighbouring chunks are already generated.

 

    public void populateChunk(IChunkProvider par1IChunkProvider, IChunkProvider par2IChunkProvider, int par3, int par4)
    {
        if (!this.isTerrainPopulated && par1IChunkProvider.chunkExists(par3 + 1, par4 + 1) && par1IChunkProvider.chunkExists(par3, par4 + 1) && par1IChunkProvider.chunkExists(par3 + 1, par4))
        {
            par1IChunkProvider.populate(par2IChunkProvider, par3, par4);
        }

        if (par1IChunkProvider.chunkExists(par3 - 1, par4) && !par1IChunkProvider.provideChunk(par3 - 1, par4).isTerrainPopulated && par1IChunkProvider.chunkExists(par3 - 1, par4 + 1) && par1IChunkProvider.chunkExists(par3, par4 + 1) && par1IChunkProvider.chunkExists(par3 - 1, par4 + 1))
        {
            par1IChunkProvider.populate(par2IChunkProvider, par3 - 1, par4);
        }

        if (par1IChunkProvider.chunkExists(par3, par4 - 1) && !par1IChunkProvider.provideChunk(par3, par4 - 1).isTerrainPopulated && par1IChunkProvider.chunkExists(par3 + 1, par4 - 1) && par1IChunkProvider.chunkExists(par3 + 1, par4 - 1) && par1IChunkProvider.chunkExists(par3 + 1, par4))
        {
            par1IChunkProvider.populate(par2IChunkProvider, par3, par4 - 1);
        }

        if (par1IChunkProvider.chunkExists(par3 - 1, par4 - 1) && !par1IChunkProvider.provideChunk(par3 - 1, par4 - 1).isTerrainPopulated && par1IChunkProvider.chunkExists(par3, par4 - 1) && par1IChunkProvider.chunkExists(par3 - 1, par4))
        {
            par1IChunkProvider.populate(par2IChunkProvider, par3 - 1, par4 - 1);
        }
    }

 

Wow that's smart, I never knew that existed before.  Thanks again for prompting me onto the right path for this.