Choonster

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.

Applaud increases the poster's karma, the Thank You button in the top right of a post displays the thanks under the post.

Are you compiling it with gradlew build (or running the build task through IDEA's Gradle window)? This reobfuscates the mod after compiling it, so setUnlocalizedName is renamed to the appropriate SRG name (the names used outside of the development environment).

This does appear to be a vanilla bug. On the client, PlayerControllerMP#onPlayerDestroyBlock calls Block#removedByPlayer (which sets the block to air) before calling ItemStack#onBlockDestroyed (which ItemTool calls Block#getBlockHardness from). On the server, ItemInWorldManager#tryHarvestBlock calls ItemStack#onBlockDestroyed before calling Block#removedByPlayer . This means that the block still exists on the server when Item#onBlockDestroyed is called; but it's already been set to air on the client.

The "x" and "y" values are the rotation around the x and y axes, respectively. This wiki page explains the vanilla blockstates and block/item model formats. For blocks with many combinations of properties, you may want to use Forge's blockstates format which is explained here. This allows you to specify what effect each value has on the model and combine multiple models.