jeffryfisher

Be careful when looping and removing at the same time. Some of these objects will put you in the wrong place so that you miss something. Check the forum for discussions of when to use an iterator etc.

Be careful when looping and removing at the same time. Some of these objects will put you in the wrong place so that you miss something. Check the forum for discussions of when to use an iterator etc.

Amazing <shakes head>. Whenever Minecraft selects an element from a weighted list (such as the creatures that can spawn in a biome), it adds up the total weight of elements in the collection. Again and again and again. Shouldn't the weight only change when an element is added or removed? If so, then shouldn't total weight be pre-calculated at the moment a random selection is made? More importantly... Am I missing something here? Is total weight sometimes more dynamic than the building of a list at load time?

Amazing <shakes head>. Whenever Minecraft selects an element from a weighted list (such as the creatures that can spawn in a biome), it adds up the total weight of elements in the collection. Again and again and again. Shouldn't the weight only change when an element is added or removed? If so, then shouldn't total weight be pre-calculated at the moment a random selection is made? More importantly... Am I missing something here? Is total weight sometimes more dynamic than the building of a list at load time?

Do you get any crashes running in Eclipse? If so, then run in its debugger so you can step into the errant method to examine variables etc. If not, then it is possible that one mod is not "playing nice" with another. You mentioned "other mods". Create a world without them -- run just your mods. If your problems go away, then isolate the problem mod by process of elimination... then eliminate it (and send a message to the mod's author).

Do you get any crashes running in Eclipse? If so, then run in its debugger so you can step into the errant method to examine variables etc. If not, then it is possible that one mod is not "playing nice" with another. You mentioned "other mods". Create a world without them -- run just your mods. If your problems go away, then isolate the problem mod by process of elimination... then eliminate it (and send a message to the mod's author).

Oh dear... Go learn Java before D7 bans you.

Oh dear... Go learn Java before D7 bans you.

Class fields seed and drop go uninitialized. The constructor takes like-named parameters, but they're never used.

Class fields seed and drop go uninitialized. The constructor takes like-named parameters, but they're never used.

Here's how BlockGrass did its updateTick in 1.8 (several dot-up calls, but using neighbor light instead of seeing sky for some reason): public void updateTick(World worldIn, BlockPos pos, IBlockState state, Random rand) { if (!worldIn.isRemote) { if (worldIn.getLightFromNeighbors(pos.up()) < 4 && worldIn.getBlockState(pos.up()).getBlock().getLightOpacity(worldIn, pos.up()) > 2) { worldIn.setBlockState(pos, Blocks.dirt.getDefaultState()); } else { if (worldIn.getLightFromNeighbors(pos.up()) >= 9) { for (int i = 0; i < 4; ++i) { BlockPos blockpos1 = pos.add(rand.nextInt(3) - 1, rand.nextInt(5) - 3, rand.nextInt(3) - 1); Block block = worldIn.getBlockState(blockpos1.up()).getBlock(); IBlockState iblockstate1 = worldIn.getBlockState(blockpos1); if (iblockstate1.getBlock() == Blocks.dirt && iblockstate1.getValue(BlockDirt.VARIANT) == BlockDirt.DirtType.DIRT && worldIn.getLightFromNeighbors(blockpos1.up()) >= 4 && block.getLightOpacity(worldIn, blockpos1.up()) <= 2) { worldIn.setBlockState(blockpos1, Blocks.grass.getDefaultState()); } } } } } }

Here's how BlockGrass did its updateTick in 1.8 (several dot-up calls, but using neighbor light instead of seeing sky for some reason): public void updateTick(World worldIn, BlockPos pos, IBlockState state, Random rand) { if (!worldIn.isRemote) { if (worldIn.getLightFromNeighbors(pos.up()) < 4 && worldIn.getBlockState(pos.up()).getBlock().getLightOpacity(worldIn, pos.up()) > 2) { worldIn.setBlockState(pos, Blocks.dirt.getDefaultState()); } else { if (worldIn.getLightFromNeighbors(pos.up()) >= 9) { for (int i = 0; i < 4; ++i) { BlockPos blockpos1 = pos.add(rand.nextInt(3) - 1, rand.nextInt(5) - 3, rand.nextInt(3) - 1); Block block = worldIn.getBlockState(blockpos1.up()).getBlock(); IBlockState iblockstate1 = worldIn.getBlockState(blockpos1); if (iblockstate1.getBlock() == Blocks.dirt && iblockstate1.getValue(BlockDirt.VARIANT) == BlockDirt.DirtType.DIRT && worldIn.getLightFromNeighbors(blockpos1.up()) >= 4 && block.getLightOpacity(worldIn, blockpos1.up()) <= 2) { worldIn.setBlockState(blockpos1, Blocks.grass.getDefaultState()); } } } } } }

Unfortunately, I haven't worked with world generation before, so I can only give strategic advice on how to explore the Forge code yourself looking for hooks that Forge has injected. On one end, search the chunk generation source for any mention of forge or event (they often employ fully qualified names, so you can't rely on import statements to expose Forge references). You might also try world's block-placement method or whatever the chunk generator returns to. You'd be looking for a call-back to a Forge method that would let you intervene. At the other end, go to net.minecraftforge.event and browse every event in every class to get an idea what's possible. Terraingen and World look like promising subfolders there. Even after finding an event at a usable intervention point, you would still need to see if it carries enough information each way for you to detect your condition and achieve your goal. I think your chances are good, since this forum has discussed block substitutions before. However, I can't recall whether biome was a factor in any of them.

Unfortunately, I haven't worked with world generation before, so I can only give strategic advice on how to explore the Forge code yourself looking for hooks that Forge has injected. On one end, search the chunk generation source for any mention of forge or event (they often employ fully qualified names, so you can't rely on import statements to expose Forge references). You might also try world's block-placement method or whatever the chunk generator returns to. You'd be looking for a call-back to a Forge method that would let you intervene. At the other end, go to net.minecraftforge.event and browse every event in every class to get an idea what's possible. Terraingen and World look like promising subfolders there. Even after finding an event at a usable intervention point, you would still need to see if it carries enough information each way for you to detect your condition and achieve your goal. I think your chances are good, since this forum has discussed block substitutions before. However, I can't recall whether biome was a factor in any of them.

I recommend walking through the vanilla code that adds chests. See if there's a suitable Forge event called at the end that gives you "last licks" to modify the chest contents. If "lucky", find an empty inventory slot and add your one dynamically generated special item.

I recommend walking through the vanilla code that adds chests. See if there's a suitable Forge event called at the end that gives you "last licks" to modify the chest contents. If "lucky", find an empty inventory slot and add your one dynamically generated special item.

There's more than one way to substitute the vanilla stone. I think there's an event where you can detect vanilla stone and the biome, making the switch whenever you like the combo. You could also hunt down the code that fills most deep areas with stone. Be aware though: Most ores spawn only in vanilla stone; they won't replace anything else, so your biome might not get any diamonds, gold, iron etc. Mobs decide where they want to spawn. There might be some that spawn in any biome. Extending dirt etc will duplicate the intrinsic characteristics, but... Some game behavior is reactive (like plants deciding where they can grow). Therefore, some other objects in the game might not recognize your dirt as dirt (e.g. Plants might refuse to grow on it.)

There's more than one way to substitute the vanilla stone. I think there's an event where you can detect vanilla stone and the biome, making the switch whenever you like the combo. You could also hunt down the code that fills most deep areas with stone. Be aware though: Most ores spawn only in vanilla stone; they won't replace anything else, so your biome might not get any diamonds, gold, iron etc. Mobs decide where they want to spawn. There might be some that spawn in any biome. Extending dirt etc will duplicate the intrinsic characteristics, but... Some game behavior is reactive (like plants deciding where they can grow). Therefore, some other objects in the game might not recognize your dirt as dirt (e.g. Plants might refuse to grow on it.)

I think that "parent" can be set to only one thing. JSON syntax, even with Forge's advanced improvements, is prone to redundancy that grates on programmers (JSONs are crystalizing data for lookup, not making runtime decisions, which is a completely different mindset). Therefore, expect to repeat yourself repeatedly when writing blockstate and model files. BTW, I may be an idiot, but if I had been writing the new (for 1.8 ) system, I would have used a client-side only method that for any block state would have returned a rendering data set (model, texture etc). Then the bakery could have called the method repeatedly during setup, baked all of the results, and nobody would have been the wiser. Forcing coders to elaborate the data, sometimes with Cartesian product output, was moronic. Not only was it tediously voluminous, but text is prone to bugs.

I think that "parent" can be set to only one thing. JSON syntax, even with Forge's advanced improvements, is prone to redundancy that grates on programmers (JSONs are crystalizing data for lookup, not making runtime decisions, which is a completely different mindset). Therefore, expect to repeat yourself repeatedly when writing blockstate and model files. BTW, I may be an idiot, but if I had been writing the new (for 1.8 ) system, I would have used a client-side only method that for any block state would have returned a rendering data set (model, texture etc). Then the bakery could have called the method repeatedly during setup, baked all of the results, and nobody would have been the wiser. Forcing coders to elaborate the data, sometimes with Cartesian product output, was moronic. Not only was it tediously voluminous, but text is prone to bugs.

You might also look at how cactus does its damage. There might be something to learn there.

You might also look at how cactus does its damage. There might be something to learn there.

The class Block relates to blocks taking up space in the world. When a block breaks and drops something, the floater is an item (actually an ItemStack). If the item dropped is the "block itself", then it is the ItemBlock derived from the block. The ItemBlock is also what appears in your hand and in inventory. Almost every block has a related ItemBlock. Exceptions are things like flowing water and lava source blocks. If your block is something that can drop and be picked up, then it needs a related ItemBlock.

The class Block relates to blocks taking up space in the world. When a block breaks and drops something, the floater is an item (actually an ItemStack). If the item dropped is the "block itself", then it is the ItemBlock derived from the block. The ItemBlock is also what appears in your hand and in inventory. Almost every block has a related ItemBlock. Exceptions are things like flowing water and lava source blocks. If your block is something that can drop and be picked up, then it needs a related ItemBlock.

You could spare yourself from some block model files if your blockstates json referred to vanilla models. My own walls mod has a blockstates file that looks like this: { "forge_marker": 1, "variants": { "geometry": { "0": { "model": "wall_post" }, "4": { "model": "wall_n" }, "8": { "model": "wall_n", "y": 90, "uvlock": true }, "2": { "model": "wall_n", "y": 180, "uvlock": true }, "1": { "model": "wall_n", "y": 270, "uvlock": true }, "12": { "model": "wall_ne" }, "10": { "model": "wall_ne", "y": 90, "uvlock": true }, "3": { "model": "wall_ne", "y": 180, "uvlock": true }, "5": { "model": "wall_ne", "y": 270, "uvlock": true }, "6": { "model": "wall_ns" }, "9": { "model": "wall_ns", "y": 90, "uvlock": true }, "14": { "model": "wall_nse" }, "11": { "model": "wall_nse", "y": 90, "uvlock": true }, "7": { "model": "wall_nse", "y": 180, "uvlock": true }, "13": { "model": "wall_nse", "y": 270, "uvlock": true }, "15": { "model": "wall_nsew" }, "16": { "model": "wall_ns_above" }, "17": { "model": "wall_ns_above", "y": 90, "uvlock": true } }, "skin": { "0": { "textures": { "wall": "blocks/stonebrick" }}, "1": { "textures": { "wall": "blocks/stonebrick_mossy" }}, "2": { "textures": { "wall": "blocks/stonebrick_cracked" }}, "3": { "textures": { "wall": "blocks/stonebrick_carved" }}, "4": { "textures": { "wall": "blocks/brick" }}, "5": { "textures": { "wall": "blocks/hardened_clay" }}, "6": { "textures": { "wall": "blocks/netherrack" }}, "7": { "textures": { "wall": "blocks/quartz_block_chiseled" }}, "8": { "textures": { "wall": "blocks/obsidian" }}, "9": { "textures": { "wall": "blocks/sandstone_normal" }}, "10": { "textures": { "wall": "blocks/sandstone_carved" }}, "11": { "textures": { "wall": "blocks/stone" }}, "12": { "textures": { "wall": "blocks/stone_granite_smooth" }}, "13": { "textures": { "wall": "blocks/stone_diorite_smooth" }}, "14": { "textures": { "wall": "blocks/stone_andesite_smooth" }}, "15": { "textures": { "wall": "blocks/end_stone" }} } } }