Choonster

You installed a 1.8 mod on 1.7.10.

The exception on line 82 of ShapedOreRecipe is thrown when the length of the full shape string isn't equal to the width (the length of the last individual shape string) times the height (the number of individual shape strings). All shape strings must be the same length. Shape strings are whitespace-sensitive, so "I" isn't the same as " I " .

Vanilla has no concept of gases, so most gaseous fluids (at least the ones from Thermal Foundation, IC2 and Railcraft) just use MaterialLiquid (which returns true from Material#isLiquid ).

Most mod fluid blocks will extend from BlockFluidBase (which you probably meant), but it's entirely possible that they'll implement IFluidBlock themselves and not use the reference implementation.

I meant pass the player's held ItemStack to getHarvestLevel instead of creating a new one with metadata 0 and no NBT. What you've done looks correct.

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.