Draco18s

That is one task in the list. Take a look at the rest of them, go up the inheritance tree, too.

Oops, your right. I'm still pretty sure you need a block texture json to indicate the particle texture.

public class MyBlock extends BlockContainer { public MyBlock() { this.setTextureName("put something here"); } } Block break particles are based off the BLOCK's texture.

And what problem would that be? I can't look at a block of code and magically understand your problem(s)

Look at the AI task list. It should be pretty obvious.

And you started a whole thread for that, good jorb.

i got it, but now i need to know why the block can't be moved by a piston What material is it? Does it have a TileEntity? Both of these are very important questions you should have already asked yourself.

The player will also be able to swim in it. Because both of those features are hard coded by vanilla to only happen inside water (you cannot down in lava, ever). Type best bet is to recreate the effect yourself using IExtendedProperties

Yes. Immerse the player inside a block that is Material.water

That's the client-side world. The server is undoing all of your changes.

Basic. Fucking. Java.

BlockPos.x? Jesus. It might be xpos, or posx, I haven't actually used 1.8 yet, but I can't imagine its that difficult.

Convert "int x, int y, int z" to BlockPos(x, y, z). Fuck. This is basic java.

And thus, your problem truly begins.

Le gasp! Your method signature is wrong and its not being called from anywhere!

Is that function overriding a function from somewhere else? If so, where's your @Override annotation?

Put @Override on the line above the function. What happens?

Just because you typed it out doesn't mean the IDE magically changes the uncompiled code.

No fucking shit. All of the x, y, z position coordinates for blocks changed to BlockPos. Use it.

God damn. I wonder what a BlockPos is...

It might have something to do with getBlockState....

If you (generic) are creating a furnace that "just looks different" you would just have all the Blocks create the same TileEntity. There's no reason to create a new TE class (even one that extends some generic version) just because it belongs to a different block. As for "allowing mods (and MC itself) just to know this thing is a furnace": what value is there in that? Why "furnace" instead of "grinder" "machine" "oven" "a thing that has an inventory and updates every tick and alters that inventory" or some other niche distinction? Why is "furnace" the important distinction to make?

Ok, I'll grant that that is a valid point.

Really though, there doesn't need to be a common furnace. It's a TileEntity (common code) that implements ISidedInventory (probably) or at least IInventory. Which is all that's needed for every mod ever to be able to insert items or extract them (including using the vanilla Hopper). No other mod needs to care about how your CustomFurnace actually smelts inputs into outputs, so having a "common core" for the updateTick method is pointless. Per liquids, I suspect it was originally because creating a new liquid was Hard* and so it was written as a base class that mods could extend in order to easily get a liquid working "like vanilla" and morphed later into the liquid registry (et cetera) due to the number of mods wanting to move liquids around and treat them in common ways without having to do a bunch of special casing. There is IFluidBlock, which is implemented by BlockFluidBase, but it doesn't really supply all of the necessary details, as BlockFluidBase is the class that handles the Fluid object. But sure, feel free to create that library if you want to. Dollars to doughnuts no one will use it. *My first attempt at a liquid, using the Forge liquid base block didn't even work correctly, just to give you an idea of how Hard it actually is!

Also keep in mind that there are other mods out there that modify a chunk long after its been generated. COG, for example, waits until the next chunk over is modified so that it can go in and clean up any coal that bleeds over before placing ores using its own algorithms ("deferred generation +16"; "deferred +32" would be two-chunks-over, etc. although nothing uses anything later than that by default). So yeah, depending on what you're doing, the right place to sit and wait for an event might change.