Draco18s

Your structure should be laid out with metadata as follows: [ 1] [ 2] [ 3] [ 4] [ 5] [ 6] [ 7] [ 8] [ 9] [10] [11] [12] [13] [14] [15] [16] As your texture should be split up as well.

You are going to need a TileEntity to store the block the player r-clicked with, for one. For two, you're going to need to make the renderer for this block look up, then render, the mesh for the stored block.

I think I have now realized your issue: ItemStacks aren't combining at all (because of your NBT) and you want to force them to combine (rather than, as I initially thought, preventing them from combining). That's tricky, as there are multiple places where this needs to occur, not just at the EntityItemStack level.

IIRC, shouldSideBeRendered is a client-side only method (that is, the vanilla method is marked @SideOnly(CLIENT)) which means you will be able to access Minecraft.getMinecraft() in order to retrieve a reference for the client-side player and check for creative status.

...You realize that when that block gets placed that NBT information is lost...right?

Most of Redstone dust's "state" is based on "what other blocks around me connect to redstone dust?" Your block can't use "world time" as part of its extended state because: 1) World time changes constantly and your block is not asked for its extended state constantly. The game assumes that state is fixed unless the worldstate changes (world time is not part of the world state). 2) You don't encode your color state in metadata, so changing the color state doesn't update the world state: it sees the block and metadata values being unchanged so it does nothing.

I'm looking for the bit where direction comes into this and I don't see any. Your block doesn't have a facing and your TileEntity doesn't give a shit about facing and there's no code to figure out what "front" means so it defaults to Z+

@Override public IIcon getIcon(int meta, int side) { return icons[meta]; } Make sure it's actually overriding a method in Block to make sure I didn't typo something.

int modEntID = 0; EntityRegistry.registerModEntity(MyEntity.class, modEntID, ...)

Properties are a wrapper around metadata. To change the property you need to change the metadata. You would need to get the current IBlockState, change the color ( .withProperty I think), and set it back with world.setBlockState The problem is your current block setup both: a) ignores the fuck out of the color ( getMetaFromState discards the color information) b) has too many total states to encode in metadata (5 colors * 4 facings = 20 states)

You're creating a multiblock structure (don't think of it like a snowman, that's an entity). Once your 16 blocks are in place, replace them with a different block that has metadata from 1 to 16 corresponding to which segment of the texture it should display. You could do it with the existing block, but it would be more difficult and less efficient (the getIcon method would need to validate the structure every time it was called, where as using metadata means it only needs to be done once).

Not for the problem you indicated, but it means that now you won't have a problem running a dedicated server. i.e. I fixed a problem you didn't even know you had and averted the creation of yet another "Crash: ClassNotFoundException on Dedicated Server" thread.

And this, kids, is why you don't define your variables where they're declared and use the constructor method for what it's for.

Show a screenshot that shows the entire folder path structure to the texture.

I think they meant "changing" with a G. But the question still doesn't make any sense. A property is a wrapper around some other value.

No. Bad modder. No cookie. DO NOT USE Minecraft.getMinecraft()! this.worldObj ! Use it!

Go through and deobfuscate that back to readable variable names. It'll be a lot easier for use to help you figure out what's wrong.

Ah, those are clouds, got it. Anyway, you're probably going to end up having to modify the renderer yourself. When I had this problem in 1.7.10 I complained to Lex and he was like "No one uses it anyway." Ended up writing a Pull Request for it and it got merged. I see that its gone and gotten lost again.

getCrop only returns the item, you've attempted to return an ItemStack only without actually wrapping the three values in an ItemStack. So no matter what, that line of code would never compile, never ever ever.

I'd kinda like to see more of your liquid from below. When I had this problem in 1.7 I took a screenshot from a position where it was flowing and you could see some of the side/top faces and the missing underside faces. Your last screenshot is really hard to to tell WTF I'm looking at.

getBlock().canSustainPlant() That's the one. Go look at Block#canSustainPlant

You need to use Capabilities in 1.9

There is a chunk of code somewhere that handles valid placement that wass't in the BlockCrops class, I just don't remember where it was.

Yes. #Unhelpful, but accurate reply.

Possibly, but I would not do it. I would create a separate folder to be the local repository, which will need to push to a branch on your github account (and then you can use Pull Requests to merge with the main), unless you have permissions to push directly to the main. This insures that you don't need to create a .gitignore file in your working directory to exclude a whole ton of stuff* and instead just need to copy the /src directory from one to the other. *If you don't, then those project files might get committed and clutter the git repo.