Choonster

Create a SoundEvent with the ResourceLocation of your sound (i.e. your mod ID as the domain and the event name from sounds.json as the path), subscribe to RegistryEvent.Register<SoundEvent> and then use RegistryEvent.Register#getRegistry to get the registry and IForgeRegistry#register or IForgeRegistry#registerAll to register your SoundEvent . RegistryEvent.Register is fired before preInit, so you need to subscribe to it with a static method annotated with @SubscribeEvent in a class annotated with @Mod.EventBusSubscriber . You can see how I do this here.

Block#getMobilityFlag determines whether a Block can be pushed by a piston. There have been various PRs for piston events in the past, but none have been merged yet. If you need these events, consider submitting a current PR.

If you know you're on the client, you should be able to access the client World through the Minecraft#world field.

ItemStack doesn't override Object#hashCode , so two ItemStack s will only have the same hash code if they're the same object. You shouldn't actually need to override Object#hashCode if your recipe class isn't being used as the key of a HashMap . If you do override it, you need to generate your own hash code for each ItemStack based on the parts your recipe cares about ( Item , metadata, NBT and/or capabilities). Are you sure your updated equals method is correct? You're comparing item1 and item2 , item2 and item2 and item1 and item3 . Should you not be comparing item1 and item1 , item2 and item2 , item3 and item3 ?

Use ItemStack#isItemEqual or ItemStack.areItemsEqual to check if the Item and metadata of the two ItemStack s are equal. Use ItemStack.areItemStacksEqual to check if the Item , metadata and NBT of the two ItemStack s are equal.

The folders are highlighted in red because they've been marked as excluded. This is because they contain internal/auto-generated files that aren't relevant to the project. Gradle will skip tasks if they don't need to be run (e.g. if current and valid output already exists). These are marked with the orange circle with lines through it in IDEA's Gradle Run window. Neither of these are problems.

Immersive Engineering uses OBJ models for its multiblocks, which can be larger than 3x3x3. It's only JSON models that have the size restriction.

Click on the margin between the line numbers and the code.

ItemSword 's override of Item#hitEntity doesn't deal any damage, that's handled by EntityPlayer#attackTargetEntityWithCurrentItem .

You'll probably want to override Item#hitEntity to check if the player is sprinting before dealing the bonus damage.

Post the code where you register your IItemColor . Is your IItemColor#getColorFromItemstack method ever called?

[19:06:56] [Client thread/WARN]: Unable to resolve texture due to upward reference: #cross in oreflowers:models/block/item/flower Don't set layer0 to #cross in the model, do it in the blockstates file. Textures in models can't reference a texture defined in the same model. [19:06:57] [Client thread/ERROR] [FML]: Exception loading model for variant oreflowers:oreflowers1#flower_type=leadplant for blockstates ["oreflowers:oreflowers1[flower_stalk=false,flower_type=leadplant,item=true]", "oreflowers:oreflowers1[flower_stalk=false,flower_type=leadplant,item=false]"] Your blockstates file doesn't include the flower_stalk property. Edit: I see you've fixed this. I've created a sapling that uses the vanilla variants and defines the item models using Forge's blockstates format. You can see it for 1.10.2 here or 1.11 here (there's no difference in the sapling code, but each of these links is for a separate branch of the repository with code for that version).

That's diesieben07's signature. It's not addressed to you.

You'd need to have a property to determine the model that's true for items and false for blocks. Completely ignore it in your Block so it defaults to false , but set it to true for the variant of your Item 's ModelResourceLocation . You then need to create a model that extends item/generated (or the appropriate item model) and put it somewhere in assets/<modid>/models/block so it's accessible from your blockstates file. When the property is true , use this model; else use block/cross . You'll also need to set the layer0 texture to #cross in your defaults section (i.e. use the cross texture as layer0 ).

You can see how I tell Gradle to compile my mod against Java 8 here.

Why do you need an event? Where is it going to be fired from? Who's going to subscribe to it, and why? Create a class that extends net.minecraftforge.fml.common.eventhandler.Event . To fire it, create an instance and call EventBus#post .

I don't know. Post your code.

Create a thread in the Suggestions section or open an issue on GitHub.

If you follow the methods used by CommandLocate , you'll see that it eventually calls IChunkGenerator#getStrongholdGen . ChunkProviderOverworld , ChunkProviderNether and ChunkProviderEnd all implement this using a chain of ternary operators with hardcoded structure names. ChunkProviderFlat implements it with a Map populated from the flat generator settings. What this means is that the /locate command only supports the vanilla structures. You could request for a way for the command to find modded structures, but this may or may not be accepted.

Your post is confusing. Your title mentions 1.10 and your post says that you're updating, but you're referencing classes and methods ( NonNullList and func_190926_b ) that only exist in 1.11. Which version are you updating from and which version are you updating to? func_190926_b was renamed to isEmpty . You can use MCPBot to view the current and previous names of fields and methods.

BlockEvent.HarvestDropsEvent will be fired when leaves decay naturally or are broken by a player. This is the event you should use. Metadata should be considered an implementation detail, don't check for specific values of it. Instead, use IBlockState#getValue to get the value of the appropriate property.

There's a collection of them here.

You need to register a name for your TileEntity class with GameRegistry.registerTileEntity in preInit.

There's a list of tutorials here, but unfortunately none of them cover fluids. It's not a tutorial, but you can see how I've implemented fluids in my mod here: creation/registration, model registration, blockstates file

That looks correct. I believe LexManos is strongly against the Forge documentation containing any "copy-pasta" code, i.e. fully working code blocks with minimal explanation apart from "copy this code into your code to make it work". If you have some well-documented example code, it may be added (though I don't speak for the Forge team).