Choonster

The server has the correct item in the output slot, but the client doesn't. I suspect something is wrong with your Container , but I don't know what.

I'd have to see your code to help you any further. Post it using Gist/GitHub or a similar site.

I've added some slabs that use the Stained Clay textures, but the half slabs are rendering completely black in the half they don't occupy (screenshot). The item models are fine. Code: [url=https://github.com/Choonster/TestMod3/blob/b21d2b20d006af0741ec94823f3675af44f1d068/src/main/java/com/choonster/testmod3/block/BlockColouredSlab.java]BlockColouredSlab[/url] , [url=https://github.com/Choonster/TestMod3/blob/b21d2b20d006af0741ec94823f3675af44f1d068/src/main/java/com/choonster/testmod3/block/BlockSlabTestMod3.java]BlockSlabTestMod3[/url] Blockstates files: first colour group, second colour group I've looked at the vanilla slab classes and it seems that BlockSlab determines whether the block is a full/opaque cube based on BlockSlab#isDouble and whether each side should be rendered based on the HALF property's value, so my slabs should render correctly without having to specify that. Am I doing something wrong or missing something obvious?

One way to do this would be to create a custom recipe interface that extends IRecipe . In this interface, you can provide an overload of getCraftingResult that either takes the World (the world that the recipe is being crafted in) or a boolean (is it day in that world?). You can then use this method instead of getCraftingResult(InventoryCrafting) for any recipe that implements the interface. Another way would be to have separate lists of day and night recipes and use the appropriate list for the current time.

Packets are handled on a Netty thread, as N247S said. You need to schedule a task to run on the main thread before you can safely interact with normal Minecraft classes. This tutorial explains how to schedule the task.

I think this patch for WorldGenTaiga2 (the small spruce tree generator) is causing the issue. The original line checks that the neighbouring block is not air and is not leaves. The replacement line checks that the neighbouring block is air and is not leaves.

Each tick event is fired twice per tick of its corresponding system (client, server, world, player or render tick) - once at the start with Phase.START and once at the end with Phase.END . If you don't check the phase, your code will run twice per tick.

Remove HUD but Not Hand is trying to use a class ( GuiIngameModOptions ) that was removed in a Forge 1.8-11.14.3.1549. It needs to updated to work with any version of Forge newer than that.

If you want every variant to use the same model with a different colour multiplier, you can either use Forge's blockstates format and specify the model in the defaults section or register a state mapper (which maps each IBlockState to a blockstates file and variant specified by a ModelResourceLocation ). To create a state mapper that ignores a specific property, create an instance of StateMap.Builder , call StateMap.Builder#ignore with the property and then call StateMap.Builder#build to create the StateMap . To register a state mapper, call ModelLoader#setCustomStateMapper in preInit. I have various examples of Forge's blockstates format here. I have some examples of state mappers that ignore properties here.

If you run gradlew eclipse , ForgeGradle should automatically generate an Eclipse project with Forge and its dependencies as libraries. You don't need to import anything manually.

Block#onEntityCollidedWithBlock(World,BlockPos,IBlockState,Entity) is called every tick while the player is inside the block, not just when they first collide with it. I just added functionality to rotate the player while they're standing on a Block of Iron using Entity#setAngles from TickEvent.ClientTickEvent and it worked without issue. You can see my implementation here. I've tested this on an integrated and dedicated server in the development environment. Edit: I've recorded a video demonstrating the rotation functionality. You can view it .

Calling Entity#setAngles on the client player should add the specified amount of yaw and pitch rotation, which will automatically be synced with the server. I have an example of a block that uses this to rotate the player from the client side here.

You've installed a 1.8.9 version of OpenComputers.

You're trying to use a coremod built for 1.8+ on 1.7.10, this won't work. If you post the actual FML log (logs/fml-client-latest.log), I can probably tell you which mod this is. Upload the log to Gist and link it here.

Look at the vanilla grass model, it overlays a texture on each side that's coloured from BlockGrass#colorMultiplier . The important part is the tintindex value for each quad, which tells Minecraft to colour it (this is passed as the renderPass argument).

I explain how to run mods in the development environment here.

Vanilla stores its KeyBinding s in GameSettings , you can get the instance from the Minecraft#gameSettings field.

An IRenderFactory is just a class that creates a new instance of the appropriate Render class. Instead of creating the Render instance as you register it, you create an IRenderFactory that creates the Render instance later in the load process.

Override Item#getIconIndex to load the InventoryStaff from the ItemStack 's NBT, check for the appropriate item and then return an IIcon based on it.

If you look at the implementation of RenderingRegistry.loadEntityRenderers , you'll see that it copies the renderers from RenderingRegistry#entityRenderers into the entityRenderMap argument. It's called in FMLClientHandler#finishMinecraftLoading to load mod entity renderers into the vanilla map. Use RenderingRegistry#registerEntityRenderingHandler to register an entity renderer.

Surely you know how to access your custom inventory for a particular EntityPlayer ? Once you have a reference to the inventory, you just need to check each slot to see if it contains the item. If the item can only be placed in a particular slot, you only need to check that slot.

Geforce has a tutorial on the system here.

IUpdatePlayerListBox was renamed to ITickable in 1.8.8. You don't implement either of these interfaces, so your TileEntity doesn't tick. You should add @Override to override methods (including interface method implementations) so you get a compiler error if it doesn't override a method of the superclass (or implement an interface method).

You'll need to use an NBT editor like NBTExplorer to remove the item from your inventory in the level.dat file. In the Data -> Player -> Inventory list, the first 0-9 entries will be your hotbar items (empty slots aren't written to NBT). You can find the mapping from item names to IDs in the Data -> FML -> ItemData list.

Item.registerItems instantiates and registers all vanilla items. The static initialiser of Items gets the Item instances from the item registry and assigns them to the static fields. Item creation and registration hasn't really changed in 1.8, only the model system has. BedrockMiner has a tutorial on creating a basic item in 1.8 here. I register my mod's items using this class. I register my models using this class. This code is for 1.8. Switch to the 1.8.8 branch to see the 1.8.9 code.