Jump to content

MC 1.10+ Improving Worldgen


winnetrie

Recommended Posts

While my worldgen is working, i have the feeling something is not right.

I think the way i get the coordinates is wrong.

Why? Because i have a block that needs to be generated in river biomes, now when i dig down in a river i mostly do not find my block, but i do find my block generating the biome next to the river.

It isn't a big deal, people will still find it after all,but when i do something wrong i like to know what and how to improve it.

 

Here is my worldgen code:

 

public class ModWorldGenerator implements IWorldGenerator {

@Override
public void generate(Random random, int chunkX, int chunkZ, World world, IChunkGenerator chunkGenerator, IChunkProvider chunkProvider) {
	// TODO Auto-generated method stub
	switch(world.provider.getDimensionType())
	{
	case NETHER:
		generateNether(world, random, chunkX, chunkZ);
		break;
	case OVERWORLD:
		generateOverworld(world, random, chunkX, chunkZ);
		break;
	case THE_END:
		generateEnd(world, random, chunkX, chunkZ);
		break;
	}
}
public void generateNether(World world, Random rand, int x, int z){
	if (ModConfig.enabledemonite==true){
		generateOre(ModBlocks.demonite.getDefaultState(), world, rand, 0, x, z, 33, 66, 75, 1, 256, BlockMatcher.forBlock(Blocks.NETHERRACK));
		if (ModConfig.enablefeliron==true){
			generateSingleOre(ModBlocks.feliron.getDefaultState(), world, rand, 0, x, z, 100, 1, 256, BlockMatcher.forBlock(ModBlocks.demonite));

		}
	}
}
public void generateOverworld(World world, Random rand, int x, int z){

	int XX = x *16;
	int ZZ = z *16;
	BlockPos pos = new BlockPos(XX, 70, ZZ);
	String biome = world.getBiomeGenForCoords(pos).getBiomeName();//getWorldChunkManager().getBiomeGenAt(XX, ZZ);

	if (ModConfig.enablechalkstone==true){
		if(biome.contains("River")){
			generateOre(ModBlocks.chalkstone.getDefaultState(), world, rand, 0, x, z, 25, 33, 100, 45, 65, BlockMatcher.forBlock(Blocks.STONE));
		}
		if(biome.contains("Ocean")){
			generateOre(ModBlocks.chalkstone.getDefaultState(), world, rand, 0, x, z, 15, 33, 50, 20, 50, BlockMatcher.forBlock(Blocks.STONE));
			generateOre(ModBlocks.chalkstone.getDefaultState(), world, rand, 0, x, z, 15, 33, 50, 10, 50, BlockMatcher.forBlock(Blocks.STONE));
			generateOre(ModBlocks.chalkstone.getDefaultState(), world, rand, 0, x, z, 10, 15, 50, 30, 50, BlockMatcher.forBlock(Blocks.GRAVEL));
		}
	}
	if (ModConfig.enablemarblestone==true){
		if(biome.contains("Hills") || biome.contains("Mountain")){
			generateOre(ModBlocks.marblestone.getDefaultState(), world, rand, 0, x, z, 25, 33, 50, 65, 256, BlockMatcher.forBlock(Blocks.STONE));
		}
	}		
}
public void generateEnd(World world, Random rand, int x, int z){

}
public void generateOre(IBlockState state, World world, Random random, int meta, int chunkX, int chunkZ, int minVienSize, 
		int maxVienSize, int chance, int minY, int maxY, Predicate<IBlockState> generatedIn){
	int vienSize = minVienSize + random.nextInt(maxVienSize - minVienSize);
	int heightRange = maxY - minY + 1;
	WorldGenMinable gen = new WorldGenMinable(state,vienSize, generatedIn);
	for(int i =0; i < chance; i++){
		int xRand = chunkX * 16 + random.nextInt(16);
		int yRand = random.nextInt(heightRange) + minY;
		int zRand = chunkZ * 16 + random.nextInt(16);
		//Block testblock = world.getBlock(xRand, yRand, zRand);
		BlockPos pos = new BlockPos(xRand, yRand, zRand);	
		gen.generate(world,  random ,pos);		
	}	
}

public void generateSingleOre(IBlockState iBlockState, World world, Random random, int meta, int chunkX, int chunkZ, 
		int chance, int minY, int maxY, BlockMatcher blockMatcher){
	//int vienSize = minVienSize + random.nextInt(maxVienSize - minVienSize);
	int heightRange = maxY - minY + 1;
	WorldGenSingleMinable gen = new WorldGenSingleMinable(iBlockState, meta,  blockMatcher);
	for(int i =0; i < chance; i++){
		int xRand = chunkX * 16 + random.nextInt(16);
		int yRand = random.nextInt(heightRange) + minY;
		int zRand = chunkZ * 16 + random.nextInt(16);
		BlockPos pos = new BlockPos(xRand, yRand, zRand);
		gen.generate(world,  random, pos );	
	}	
}
}

 

Link to comment
Share on other sites

generateOre(ModBlocks.chalkstone.getDefaultState(), world, rand, 0, x, z, 25, 33, 100, 45, 65, BlockMatcher.forBlock(Blocks.STONE));

You should be using

xx

and

zz

instead of

x

and

z

.

Don't PM me with questions. They will be ignored! Make a thread on the appropriate board for support.

 

1.12 -> 1.13 primer by williewillus.

 

1.7.10 and older versions of Minecraft are no longer supported due to it's age! Update to the latest version for support.

 

http://www.howoldisminecraft1710.today/

Link to comment
Share on other sites

@larsgerrits

No, he was using it "correctly". Quotation marks as the method wants the chunk coords, but a chunk can of course contain 1-256 different biomes

 

@winnetrie

The biome next to the river... It doesn't happen to be in the same chunk? Because all you do, is say "[this chunk] has a river. Spawn [block] in this chunk. Where? Randomly."

I recommend that you change your

generateOre

to make use of a blockpos directly, or at least a regular x & z coordinate instead of chunk coords.

This way, you can more easily oversee where they spawn.

I also recommend that you instead for-loop through

BlockPos#getAllInBox(from, to)

and check if the biome is what you want, instead of randomly generating nearby, where the biome can have changed drastically, just 1 block away.

 

Also previously known as eAndPi.

"Pi, is there a station coming up where we can board your train of thought?" -Kronnn

Published Mods: Underworld

Handy links: Vic_'s Forge events Own WIP Tutorials.

Link to comment
Share on other sites

 

@winnetrie

The biome next to the river... It doesn't happen to be in the same chunk? Because all you do, is say "[this chunk] has a river. Spawn [block] in this chunk. Where? Randomly."

Yeah i was already aware that this could be the reason, but i didn't know an alternative or an improvement!

 

I don't know how to use the thing you say, but i will look into that later.

As i said before it isn't yet important, because it works. Improvements are for later when everything is finished.

 

Thank you very much for the info!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • Try deliting feur builder  It caused this issue in my modpack
    • I am not using hardcoded recipes, I'm using Vanilla's already existing code for leather armor dying. (via extending and implementing DyeableArmorItem / DyeableLeatherItem respectively) I have actually figured out that it's something to do with registering item colors to the ItemColors instance, but I'm trying to figure out where exactly in my mod's code I would be placing a call to the required event handler. Unfortunately the tutorial is criminally undescriptive. The most I've found is that it has to be done during client initialization. I'm currently trying to do the necessary setup via hijacking the item registry since trying to modify the item classes directly (via using SubscribeEvent in the item's constructor didn't work. Class so far: // mrrp mrow - mcmod item painter v1.0 - catzrule ch package catzadvitems.init; import net.minecraft.client.color.item.ItemColors; import net.minecraft.world.item.Item; import net.minecraftforge.registries.ObjectHolder; import net.minecraftforge.fml.event.lifecycle.FMLClientSetupEvent; import net.minecraftforge.fml.common.Mod; import net.minecraftforge.eventbus.api.SubscribeEvent; import net.minecraftforge.client.event.ColorHandlerEvent; import catzadvitems.item.DyeableWoolArmorItem; @Mod.EventBusSubscriber(bus = Mod.EventBusSubscriber.Bus.MOD) public class Painter { @ObjectHolder("cai:dyeable_wool_chestplate") public static final Item W_CHEST = null; @ObjectHolder("cai:dyeable_wool_leggings") public static final Item W_LEGS = null; @ObjectHolder("cai:dyeable_wool_boots") public static final Item W_SOCKS = null; public Painter() { // left blank, idk if forge throws a fit if constructors are missing, not taking the chance of it happening. } @SubscribeEvent public static void init(FMLClientSetupEvent event) { new Painter(); } @Mod.EventBusSubscriber private static class ForgeBusEvents { @SubscribeEvent public static void registerItemColors(ColorHandlerEvent.Item event) { ItemColors col = event.getItemColors(); col.register(DyeableUnderArmorItem::getItemDyedColor, W_CHEST, W_LEGS, W_SOCKS); //placeholder for other dye-able items here later.. } } } (for those wondering, i couldn't think of a creative wool helmet name)
    • nvm found out it was because i had create h and not f
    • Maybe there's something happening in the 'leather armor + dye' recipe itself that would be updating the held item texture?
    • @SubscribeEvent public static void onRenderPlayer(RenderPlayerEvent.Pre e) { e.setCanceled(true); model.renderToBuffer(e.getPoseStack(), pBuffer, e.getPackedLight(), 0f, 0f, 0f, 0f, 0f); //ToaPlayerRenderer.render(); } Since getting the render method from a separate class is proving to be bit of a brick wall for me (but seems to be the solution in older versions of minecraft/forge) I've decided to try and pursue using the renderToBuffer method directly from the model itself. I've tried this route before but can't figure out what variables to feed it for the vertexConsumer and still can't seem to figure it out; if this is even a path to pursue.  The vanilla model files do not include any form of render methods, and seem to be fully constructed from their layer definitions? Their renderer files seem to take their layers which are used by the render method in the vanilla MobRenderer class. But for modded entities we @Override this function and don't have to feed the method variables because of that? I assume that the render method in the extended renderer takes the layer definitions from the renderer classes which take those from the model files. Or maybe instead of trying to use a render method I should be calling the super from the renderer like   new ToaPlayerRenderer(context, false); Except I'm not sure what I would provide for context? There's a context method in the vanilla EntityRendererProvider class which doesn't look especially helpful. I've been trying something like <e.getEntity(), model<e.getEntity()>> since that generally seems to be what is provided to the renderers for context, but I don't know if it's THE context I'm looking for? Especially since the method being called doesn't want to take this or variations of this.   In short; I feel like I'm super super close but I have to be missing something obvious? Maybe this insane inane ramble post will provide some insight into this puzzle?
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.