Choonster

It's possible that your world is corrupt. Does it work if you create a new world and load that?

Post the crash report.

Unless the list exists in vanilla, you'll need to use your own packet. Forge's Read the Docs site has a section on networking (including the Simple Network Implementation, which you should use) here.

Thanks, that was indeed the issue. Vanilla sets this for its own slabs, but this is done in Block.registerBlocks before mods are loaded. You'd think it would do this in the constructor of the appropriate classes. My slabs now render properly. Edit: You can see the working code here: BlockSlabTestMod3, BlockColouredSlab

You have a coremod built for 1.8+ installed (OpenComputers).

Haha, no worries. I tried manually specifying the up , down and side textures (the textures used by the slab models) but nothing changed. I also tried using the vanilla blockstates format with a vanilla model and the issue persisted, so I suspect it's something to do with the Block rather than the model.

My slabs aren't transparent, they use solid textures on a model that doesn't occupy the whole block. I did try returning each layer from Block#getBlockLayer , but nothing changed. Block#getRenderType already returns 3 and neither BlockSlab or my slab classes override it.

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.