Choonster

Don't check if the item extends ItemSpade , that's not a reliable indicator that the tool functions as a shovel (Tinkers' Construct tools extend ItemTool directly, bypassing ItemSpade and the other subclasses); some tools may not even extend ItemTool . Just use the harvest level check, any tool that can't act as a shovel will simply return -1 from Item#getHarvestLevel . Don't create a new ItemStack to pass to Item#getHarvestLevel , use the player's held ItemStack . Creating a new ItemStack will break any tool that uses metadata or NBT to determine the harvest level (e.g. Tinkers' Construct).

Use Entity#getPosition to get the player's current position, World#getBiomeGenForCoords to get the BiomeGenBase at that position and BiomeGenBase#biomeName to get the biome's name.

Override isValidPipe / isValidConnection to check if the neighbouring block is an instance of a specific pipe class instead of just BlockPipeBase .

The new fluid models were added in Forge 1.8-11.14.3.1464, so make sure you're using that version or a newer one.

You'll want to change canConnectTo to allow valid connections even if the neighbouring block isn't another pipe and then override isValidPipe in the sub class to check if the neighbouring block is a pipe or something that can handle steam. I'd recommend implementing a common interface in your steam-handling blocks or TileEntities and checking for this interface in isValidPipe . If your steam is implemented as a Forge Fluid , your steam-handling TileEntities should implement IFluidHandler and you should check for this interface in isValidPipe . You can see my implementation of a fluid pipe block (plus the changes to BlockPipeBase ) here. Note that this just connects visually to any block with a IFluidHandler TileEntity, it doesn't actually move fluid anywhere.

I can't see any obvious errors in the log. You could try disabling the splash screen in config/splash.properties since some older graphics drivers have problems with it. If that doesn't work, I'm afraid I can't help you any further.

See this thread.

Can you post the logs/fml-client-latest.log file from your Minecraft folder on Gist and link it here? Screenshots of the issue may also help.

Do you both own the game and have your own accounts? Post the logs/fml-client-latest.log file from both clients on Gist and link them here.

You've messed up the dimensions of the side model. You've made them identical to the centre model, so each connected side is just rendering the centre cube again. My side model's element goes from 4,4,0 to 12,12,4 (note the unique z coordinates); yours goes from 5,5,5 to 11,11,11. Edit: On a side note, why is your GitHub repository a bunch of unorganised files without file extensions? Why not use your mod's actual working directory as the repository?

Yes, posting the full code on Gist or Pastebin would help. Could you also take a screenshot of the debug information while looking at a pipe with at least one pipe next to it and post that?

The Watering Can schedules block updates with World#scheduleBlockUpdate when it detects a plant ( IPlantable or IGrowable ) in its area of effect.

That's odd. If you enable debug information with F3 and look at a pipe, are any of the direction properties displayed as true?

Did you override Block#getActualState to set each direction property's value?

The models for the pipe are in the same repository I linked before: pipe_centre, pipe_part. All pipes with the same shape can use these models, the textures are controlled by the blockstates file for each pipe block.

You mean actually moving the steam from point A to point B? I can't really help you much there apart from suggesting you look at open source mods that do this kind of thing, e.g. BuildCraft or Power Advantage.

Look at the blockstates file I linked. It only uses two models (centre cube + side connection) but uses Forge's blockstates format to combine them as needed.

Don't use absolute paths in your build.gradle script (C:/Users/.../src/main/java), use relative paths (src/main/java). This way other people will be able to download your code from a site like GitHub and compile it themselves without having to put it in a specific location. Anyway, you don't need to explicitly set the Java and resources paths if you're using the default ones (src/main/java and src/main/resources), you can delete the sourceSets block.

I have a basic implementation of a pipe-like block here (blockstates file). I use some Java 8 features like streams and lambdas in the code, you'll have to adapt it if you're not compiling against Java 8. I haven't got the bounding boxes working, but the pipes know they're connected to each other and render the model properly. Since your pipe block will likely have a TileEntity , you may want to cache the connection state in it (like BuildCraft pipes do) and make Block#getActualState return the values from that rather than checking each neighbouring block.

You've installed a 1.7.10 mod in 1.8.

Most authors tend to have a thread on minecraftforum.net linking to the mod's download page. A lot of authors host their mods on Curse, which is slightly easier to search.

EntityEvent.EntityConstructing is fired from the Entity constructor, which is called before the EntityPlayer constructor sets the Entity#entityUniqueID field to the player's UUID .

Both of the examples I provided use a single blockstates JSON for all the mod's fluids. Each variant is a single fluid.

You also need to use the forge:fluid model in your blockstates file with the fluid name in the custom data section provided by the Forge blockstates format. You can see examples of this in Forge here (blockstates file) and my mod here (blockstates file). Note that the MeshDefinitionFix interface in my mod is just a workaround that allows a lambda to be used as an ItemMeshDefinition (ForgeGradle doesn't know how to reobfuscate lambdas properly), you can also use an anonymous class like in Forge's example.

I haven't used IDEA's artifacts before, but I don't think they're compiled with the Gradle build task; so they're not reobfuscated by ForgeGradle. You need to run the build task from the command line or IDEA's Gradle window, which will compile and reobfuscate the mod and output it to build/libs.