Involved World Generation Question

[Kuro]

Hey there, I want to change the way worlds are generated (think alternate caves, sky islands, alternate trees, new ground blocks etc.)

 

My first guess was the IWorldGenerator Interface and I made this dumb test class:

public class TestWorldGen implements IWorldGenerator  {

@Override
public void generate(Random random, int chunkX, int chunkZ, World world,
		IChunkProvider chunkGenerator, IChunkProvider chunkProvider) {
	if(world.provider.isSurfaceWorld()) {

		int x = chunkX*16;
		int z = chunkZ*16;

		for(int i =0; i!=16;i++) {
			for(int j =0; j!=16;j++) {
				world.setBlock((x+i), 80, (z+j), Block.tnt.blockID);
			}
		}
	}
}

}

 

Though this crashes the game when it starts generating the map and all the examples I found used it just for simple things like putting a little bit of custom ore here and there.

I also looked at the BetterWorldGeneration source code to find any hints how they do it, but I found nothing.

 

So I guess this must be a completly wrong approach for what I'm trying to do.

Any hints what I have to use instead?

[GotoLink]

Indeed, this is a very dumb way to test this class.

Spawning an entire sky of tnt blocks ? what were you thinking...

 

But this is a good way to start with world generation.

Then you could make custom biomes and then, custom dimensions or world type.

[Kuro]

Well, thats only a mere 256 blocks per chunk.

I dont get it why that would be a problem when the normal world generator has to fill around 15000 blocks per chunk.

Or when using something like WorldEdit I can simply change a complete Chunk to some block in a matter of seconds.

[GotoLink]

The problem is the number of blocks, and the type of said blocks.

TNT is not meant to exist in huge numbers in the entire world.

Sure, that is "only" 256 blocks per chunk. But you generate roughly 200 chunks on world creation.

50.000 tnt blocks.

Even if you allocate more memory to the JVM, it is unlikely to be stable at all.

Pick another block, you'll see the difference.

[MineMaarten]

Plus the fact that you're using the World#setBlock(pars) method without a flag parameter, which gives a call to the World#setBlock(pars) with flag:

public boolean setBlock(int par1, int par2, int par3, int par4)
    {
        return this.setBlock(par1, par2, par3, par4, 0, 3);
    }

When set to 3 this means that you'll cause a block update and a update to every nearby client when you generate every block. So calling the World#setBlock without these flags should also increase performance.

[Kuro]

Both your comments helped and now it at least doesnt crash on startup.

But further looking through the code I found "IChunkProvider".

 

I implemted that and overwrote this method:

public void generateTerrain(int par1, int par2, byte[] par3ArrayOfByte) {
	for(int i = 0;i!=256;i++){
		par3ArrayOfByte[5+i*128] = (byte)Block.tnt.blockID;

	}
}

 

And now it generates the terrain just as fast as a vanilla flatmap, no problem.

But now I'm limited to a build height of 128 and only 127 Blocks (cause i have to cast int to byte).

 

Is there some way to get around these limits without having to use super slow systems?

[Draco18s]

Both your comments helped and now it at least doesnt crash on startup.

But further looking through the code I found "IChunkProvider".

 

I implemted that and overwrote this method:

public void generateTerrain(int par1, int par2, byte[] par3ArrayOfByte) {
	for(int i = 0;i!=256;i++){
		par3ArrayOfByte[5+i*128] = (byte)Block.tnt.blockID;

	}
}

 

And now it generates the terrain just as fast as a vanilla flatmap, no problem.

But now I'm limited to a build height of 128 and only 127 Blocks (cause i have to cast int to byte).

 

Is there some way to get around these limits without having to use super slow systems?

 

IChunkProvider is either not all you're using or you're using something else entirely.  IChunkProvider does not contain that method.