Choonster

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 .

You should be able to register substitution aliases for blocks and items (in fact those are the only things you can register substitution aliases for), but I haven't managed to get it working myself (see this thread). You should always try to use events or hooks before you resort to drastic measures like replacing vanilla classes or modifying them with ASM. If there's no hook or event for your use case, consider suggesting one in the Suggestions section or on GitHub. HarvestDropsEvent lets you change drops from blocks. LivingDropsEvent lets you change drops from living entities (including players). There's no direct way to modify the saturation value of existing food without resorting to some hacky reflection that makes the fields in ItemFood non-final, but you can subscribe to PlayerUseItemEvent.Finish and modify the player's food values through their FoodStats object if they used a particular food item.

Ah, sorry, it's the registerTickable() method that's throwing it. I tried rebuilding all my forge and gradle stuff, as well as a brand new install, but it still throws that error. I'm using Forge 1764, I believe. EDIT: I tried it with a fresh install of 1722, as well. No dice. Still get the same error. The method certainly exists in my installs of 1764 and 1763. Can you see it in the MinecraftServer class in your IDE? Are you running your mod in your IDE or building it and running it in a normal client? Upload the FML log (logs/fml-client-latest.log) to Gist and link it here.

I'm not sure if it's a widely-used convention, but I use ClassName.memberName to denote a static method/field and ClassName#memberName to denote an instance method/field. In this case, registerTickable is an instance method so it needs to be called on an instance of MinecraftServer (returned from the MinecraftServer.getServer method). You already seem to be doing this, though. Could you be more specific about which method the NoSuchMethodError is being thrown for?

I tried this, but it doesn't seem to be working. No errors or anything, just doesn't bother calling the update() function. If you set a breakpoint, is MinecraftServer#registerTickable definitely being called? Are you sure your update method isn't being called?