jt9

If you really want to set the order, take advantage of the alphabetical ordering of @Name. Like this: @Config.Name("Biomes: Enable Biomes") public boolean enableBiomes = true; @Config.Name("Plants: Enable Overworld Plants") public boolean enableOverworldPlants = true; @Config.Name("Plants: Enable Nether Plants") public boolean enableNetherPlants = true; @Config.Name("Mobs: Enable Passive Mobs") public boolean enablePassiveMobs = true; @Config.Name("Mobs: Enable Neutral Mobs") public boolean enableNeutralMobs = true; @Config.Name("Mobs: Enable Aggressive Mobs") public boolean enableAggressiveMobs = true; This will group them by plants, mobs, etc.

Sidenote: I see that you implement an interface called IHasModel, something a bunch of garbage mod tutorials use. There is no point in doing that, since all registered blocks already have a model. Use the Forge events to register your models, which is ModelRegistryEvent in this case. Also you'd want to keep your package names lowercase.

A user posted a crash log of the mod throwing an Caused by: java.lang.ArrayIndexOutOfBoundsException: 6 The full crash log can be found here: https://paste.dimdev.org/ziliruyota.mccrash I followed the stack trace and cannot figure out why Biome.getSpawnableList() would throw an exception. The mod works fine on its own, but crashes with other mods that add entity spawns. This only happens when I use my own EnumCreatureType, which is for allowing the mod's entities to spawn without interfering with the animal spawn cap. I'm not sure why it throws an ArrayIndexOutOfBoundsException since getSpawnableList() creates a new, empty ArrayList for non-vanilla EnumCreatureTypes, and I'm not sure why it's 6 in particular. In case it's needed, I call initEntities() during preinit and addSpawns() during init. Here's my entity code: And here's both Biome.getSpawnableList() as well as EntityRegistry.addSpawn() for reference.

Yep. Flattened everything and all that, which made me realize how ridiculous it was to cram so many properties into a single block. I searched up all the wood items I would need to add to be consistent with vanilla and saw the buttons, pressure plates, and trapdoors, not realizing they were added in 1.13. The mod has been in development for about a month and is the first one I've worked on for over a year. Its first completed build will be released soon!

Nah, I'll leave it for 1.13. I'm following the 1.12 rules after all I mean it's a button, a pressure plate, and a trapdoor. It's not a big concern for me, it can wait.

Yeah, I figured. Was just hoping to see a workaround, but as I mentioned earlier I'll just leave it be until it gets updated to 1.13.

I thought of doing something similar to this, but then I realized it would result in removing the recipe for the vanilla button. The current vanilla recipe uses "plankWood" from the OreDictionary to make a wooden button. I have my mod's planks registered under "plankWood" so they can be crafted into sticks, chests, etc. However, 1.13 added in buttons for each wood type so I did too. The problem is that now the crafting recipe for the mod's button is overridden by the OreDictionary's recipe, which only exists because 1.12 does not have different wooden buttons yet. It works for doors and boats because there are already different boats for each type of wood in 1.12, so the recipes do not need to access from the OreDictionary. I can't remove the recipe because then you wouldn't be able to craft a wooden button Now I could just change the recipe slightly, but I'll just wait for 1.13 which will take those recipes off the OreDictionary system.

I guess I'll wait until 1.13 as it's not a big issue at the moment.

The problem is that I have planks registered in the OreDictionary to work with vanilla recipes that use planks, but I also have a separate recipe that uses the planks and that recipe matches one of the vanilla recipes, but with a different output. The intention was to have this new recipe replace the vanilla one, but it doesn't. For example, 1.13 adds in buttons for each type of wood. I've done that too in the mod and added in the recipe for that button. However, putting one of the mod's planks gives the vanilla button since the planks are registered in the OreDictionary as "plankWood".

So I have registered a block with the Ore Dictionary for it to work with vanilla recipes, but I also have another recipe using that block that matches the pattern of the vanilla recipe. As a result, the vanilla recipe takes priority over the mod's recipe. Has anyone run into this problem before and found a solution? Here is my GitHub repo if needed: https://github.com/mc-jt9/ProjectVibrantJourneys I've been prepping for 1.13 by adding in unique trapdoors/buttons/pressure plates for some wood types in the mod since vanilla versions were added in 1.13 and ran into this issue.

Having flattened all my mod's blocks, I welcome the removal of metadata! Holding variants and properties in one block and having to deal with that was a total pain. Also hoping for flexibility in waterlogged blockstates, I will be using that a lot. I can definitely see how it might be tough to get used to multiple superinterfaces for the World, but shouldn't be much of an issue once people get used to it. That said, would having world gen on separate threads be much of an issue if you're only dealing with small additions? GameRegistry.registerWorldGenerator() has an argument for generation weight, that should be useful in avoiding issues, yes?

I have not dealt with tile entities in a long time, but iirc you can have a field for the EntityPlayer in your TileEntity class and set it to the player that placed the block by overriding public void onBlockPlacedBy(World worldIn, BlockPos pos, IBlockState state, EntityLivingBase placer, ItemStack stack) { } in your block's class.

Oops! That makes sense. Fixed it, thanks

EntityAmbientCreature

This is the only relevant piece of code in the entity class. Given that System.out.println("despawn"); is constantly being executed, it shows that the if statement isn't working correctly. I can see the mobs die as soon as I spawn them