Choonster

World#isRemote is false on the server and true on the client.

I override BlockSlab#isDouble in an anonymous class created in BlockColouredSlab.ColouredSlabGroup#createGroup (this is the actual class used by my slabs, the others are abstract). The isDouble constructor argument was a leftover from my earlier attempts, I've removed it now. Vanilla slabs are rendering without issue, it's only my slabs that have the lighting problem. I'm aware of block layers, but they're not the issue here. None of the vanilla slabs override Block#getBlockLayer and overriding that method does nothing to fix the problem regardless of which layer I return. BlockSlab overrides Block#isOpaqueCube to return the result of BlockSlab#isDouble , which I already override to return the appropriate value. Block#getRenderType only needs to be overridden if you want to use a different renderer to the parent class, which I don't. Both Vanilla slabs and my ones use the baked model system (blockstates file + models).

That looks mostly correct, though you'll crash the dedicated server by using client-only classes in code that needs to run on both sides. Move the model registration code to its own method and call that from your client proxy. If you want a BlockFluidFinite to be at the maximum level, you need to set its LEVEL property to 7. If your fluid is rendering as water, you haven't set the fluid for the model to render in your blockstates file. I posted links to my fluid initialisation and model registration code here.

[url=https://github.com/Choonster/TestMod3/blob/b21d2b20d006af0741ec94823f3675af44f1d068/src/main/java/com/choonster/testmod3/init/ModFluids.java]ModFluids[/url] (fluid initialisation) and [url=https://github.com/Choonster/TestMod3/blob/b21d2b20d006af0741ec94823f3675af44f1d068/src/main/java/com/choonster/testmod3/client/model/ModModelManager.java#L45-L64]ModModelManager[/url] (fluid model registration) are the classes you'll want to look at. This is the blockstates file for my fluids.

I suspect MicdoodleCore is outdated. Update it to the latest version.

MicdoodleCore requires Galacticraft to function. Download Galacticraft Core and Galacticraft Planets from the Galacticraft website. It looks like you may have put some of your mods in minecraft.jar, don't do this. Forge mods only work properly if they're loaded from their own JAR file, putting them in the Minecraft JAR will break things.

You also installed ArmorStatusHUD and StatusEffectHUD on the server. These are client-only mods, but it looks like they just do nothing on the server to avoid crashing it.

You also need to keep this in mind if you use reflection with Minecraft's classes. Every field/method has an SRG (semi-obfuscated) name like field_00120_a / func_12345_b and most fields/methods also have an MCP (deobfuscated) name like thing / getThing . You need to make sure you check both names when using reflection. FML's ReflectionHelper and ObfuscationReflectionHelper have methods to find a field/method with one of several names via reflection. You can find the SRG name of a field/method in the MCP mapping CSVs. If you've set up a ForgeGradle workspace for 1.8+, you can find the mappings it's using in the Gradle cache (~/.gradle/caches/minecraft/de/oceanlabs/mcp/<mappings_channel>/<mappings_version>, replace ~ with %USERPROFILE% on Windows). You can also download them from the MCPBot website. External libraries and Forge/FML code (including new methods/fields in vanilla classes) aren't affected by this, everything just has the one name.

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.