Choonster

I've managed to get this working, you can see my code here. I ended up using the Shadow plugin to package and relocate the dependency and just told ForgeGradle to reobfuscate the resulting JAR.

Have you called CapabilityManager#register for your capability interface?

It looks like you've extracted mod JARs into your mods folder, don't do this. Mod JARs should be placed in the mods folder without being extracted.

I think the documentation on Read the Docs is for ForgeGradle 1.2, there doesn't seem to be any documentation for 2.x. I'm looking through ForgeGradle's code, but I don't fully understand how Gradle works. This PR changed the reobfuscation system, so now you need to specify reobfuscation per JAR task (like this). I'll try this myself and see if it works.

Mobs check the light level of their spawn location in EntityMob#isValidLightLevel , you should be able to adapt this to your needs.

Create an anonymous class that extends StateMapperBase and override the getModelResourceLocation method to return a ModelResourceLocation pointing to the variant in your blockstates file. In this case, use the ModelResourceLocation(String resourceName, String variant) constructor with "sbm:spruce_sign" as the resource name (i.e. assets/sbm/blockstates/spruce_sign.json) and "normal" as the variant. Call ModelLoader.setCustomStateMapper from your client proxy in preInit with your Block as the first argument and this anonymous class as the second argument. I do something similar for my fluid blocks here.

It looks like someone has set an invalid value for the font property in the config/splash.properties file. Either delete this property in the file or delete the file entirely.

Use BrewingRecipeRegistry to add brewing recipes.

It looks like Minecraft hardcodes the textures for its blocks that don't use a standard model (e.g. signs, liquids). You can probably create a dummy JSON model and specify its "particle" texture. You'll need a blockstates file that tells Minecraft to use the model (which won't actually be rendered) and an IStateMapper that ignores the state and always maps to the same variant of the blockstates file. Every TileEntity you add must be registered using GameRegister.registerTileEntity . Make sure you include your mod ID in the TileEntity 's ID so you don't conflict with other mods.

Signs are rendered by TileEntitySignRenderer , this only renders a standing sign if the Block is Blocks.standing_sign . I suggest adapting the rendering code from this class into your own TESR that uses instanceof to check whether the sign is standing or not and uses your own texture. Use ClientRegistry.bindTileEntitySpecialRenderer from your client proxy to register the TESR . You'll need to create your own TileEntity class that extends TileEntitySign and Block classes that extend BlockWallSign / BlockStandingSign and override Block#createTileEntity(World, IBlockState) to create your TileEntity instead of TileEntitySign .

I'm not too sure why that would happen, sorry. I don't have much experience with this. Minecraft already uses several of your dependencies (e.g. commons-logging, commons-io, Guava), so I'd recommend removing any that you don't need. I'd also recommend using srgExtra like in the page I linked to move your shaded dependencies into a unique package (e.g. org/apache/commons to mobycraft/repack/org/apache/commons ) to prevent conflicts with other mods that package different versions of the same libraries.

It looks like the shadowJar task uses the compiled output from the main SourceSet , but ForgeGradle handles reobfuscation separately (it assembles the JAR and then reobfuscates that). It may be easier to use the shading method described here than trying to integrate the shadow plugin with ForgeGradle.

What Draco said is true and will definitely crash the dedicated server, but I don't think it's the problem here. It looks like you're trying to use your mod in the obfuscated client without reobfuscating it. Use the build Gradle task to build and reobfuscate your mod.

There's no point in using it, Block itself has methods that allow you to create a TileEntity (i.e. Block#hasTileEntity(IBlockState) and Block#createTileEntity(World, IBlockState) ).

You'll want to look at ISmartItemModel to create a model based on the NBT. I can't help you with it myself, but it's been discussed in various threads on this forum.

As far as I can see, there are no 1.8.9 versions of NEI. CodeChickenCore and CodeChickenLib. Some 1.8 mods may work in 1.8.9, but I wouldn't be surprised if coremods like NEI don't.

ItemColored would work fine, but GameRegistry can't actually instantiate it because of the way it uses reflection to find the constructor. Essentially the ItemColored constructor takes a primitive boolean argument, but passing a primitive boolean value in a vararg boxes it to a Boolean ; so GameRegistry tries (and fails) to find a constructor with a Boolean argument. Vanilla doesn't have this issue because it instantiates its ItemBlock s directly instead of using reflection. You can create your own class that extends ItemColored and has a (Block, Boolean) constructor (like this) and then use this as the item form of your block. You shouldn't actually need to override anything.

Then I'm not too sure what's going on. Try stepping through every line rather than just the invalid one and see if you can figure out where it's reading from.

The objFrom field should contain the ResourceLocation of the file it's parsing, is this your OBJ model?

It looks like Forge's OBJ parser expects each non-empty, non-comment line to consist of a key and some data separated by whitespace; but it encountered a line that didn't match this pattern. I suggest setting a breakpoint on line 220 of ObjModel (where the error occurs) with a condition of fields.length < 2 (i.e. the line couldn't be split into two parts separated by whitespace) and looking at the value of currentLine to see what the offending line is.

Minecraft does this using Block.BLOCK_STATE_IDS , which is the same map returned by GameData.getBlockStateIDMap . I would recommend against implementing IMessage and IMessageHandler in the same class, since it's easy to get confused and use values from this instead of the message argument in IMessageHandler#onMessage . Either move the handler to a separate class or a static inner class. It's not safe to interact with normal Minecraft classes directly in your IMessageHandler , since it's called from a separate thread to the main client/server thread. You need to schedule a task on the main thread using IThreadListener#addScheduledTask , this page explains how to do this.

What's the issue here? Is it crashing? Is it simply not showing the recipe output when you put the ingredients in the crafting grid?

If you look at the code, you'll see that LivingUpdateEvent is called from EntityLivingBase#onUpdate . This is indirectly called from World#updateEntities , which is called on both the client and server. IEEP has been deprecated in favour of the Capability system, so you should consider switching your code to the new system.

If you want to store data per-player, use the new Capability system. In previous versions you'd use IExtendedEntityProperties , but that's been deprecated in favour of Capabilities (which are much more flexible). Even if you used a config file, you could still change values by using the appropriate overload of Configuration#get (which returns a Property ) and the appropriate overload of Property#set or Property#setValue . You could also load and save a file using regular Java IO.

In the first code block, you're using the wrong location for the model. ModelBakery.registerItemVariants , ModelLoader.setCustomModelResourceLocation and ModelLoader.setCustomMeshDefinition / ItemMeshDefinition all expect the ModelResourceLocation 's domain and path to be in the format modid:modelName , which either maps to the assets/<modid>/models/item/<modelName>.json item model or the model specified in the assets/<modid>/blockstates/<modelName>.json blockstates file (this is added by Forge and only used when the item model isn't found). In this case, use minecraft:diamond_sword (i.e. the assets/minecraft/models/item/diamond_sword.json model) instead of minecraft:items/diamond_sword (this is the texture path used in the minecraft:diamond_sword model, not a model path). If you use ItemMeshDefinition , you must actually return the appropriate ModelResourceLocation from the getModelLocation method rather than returning null . I use vanilla models for several of my mod's items here. There are several chained overloads of registerItemModel , but they all boil down to calling ModelBakery.registerItemVariants with the specified ModelResourceLocation and calling ModelLoader.setCustomMeshDefinition with an ItemMeshDefinition that returns a single constant ModelResourceLocation .