Choonster

Forge's blockstates format may be useful here. You can specify a default model (e.g. builtin/generated ) and transform set (e.g. forge:default-item ) and then specify the textures in each variant. Despite the name, Forge allows it to be used for items as well as blocks. For the ModelResourceLocation passed to ModelLoader.setCustomModelResourceLocation or returned from ItemMeshDefinition#getModelLocation , use the location of the blockstates file as the domain and path (e.g. <modid>:<name> , which maps to assets/<modid>/blockstates/<name>.json) and the variant in the blockstates file as the variant. If you're using an ItemMeshDefinition with ModelLoader.setCustomMeshDefinition , you need to call ModelBakery.registerItemVariants with the same ModelResourceLocation s yourself. If you're using ModelLoader.setCustomModelResourceLocation , ModelBakery.registerItemVariants is called for you.

I use Forge's blockstates format to compose the models for my pipe blocks from two basic JSON models (the centre cube and a side connection). You can see the blockstates file here and the pipe models here here. This is just the basic shape of a pipe, it doesn't have any sort of fancy rendering like Buildcraft pipes do.

I don't know of any tutorials, but I do have working example code. You can see my fluid creation code here, my model registration code here and my blockstates file here. ModFluids.registerFluids is called in preInit from TestMod3 (the class with the @Mod annotation), ModModelManager.registerAllModels is called in preInit from the client proxy (after everything else has been registered).

Have you got a blockstates file that specifies the model for each variant? Forge's blockstates format may be handy here.

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.