Draco18s

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.

Combining textures is a pain in the ass doing it runtime. Possible, but a huge pain. https://github.com/Draco18s/HarderStuff/blob/master/src/main/java/com/draco18s/hardlib/client/TextureAtlasDynamic.java This class comes with no warranty and if something goes wrong I will not help you figure out what because the errors will not occur in this class. I had to solve several myself when writing it and it involved a lot of backtracking through the stacktrace and examining obfuscated code to figure out what value hadn't been correctly set in order for Vanilla to properly handle the custom sprite loader.

Step 1: Download the Forge MDK Step 2: gradlew setupDecompWorkspace, gradlew eclipse on the MDK directory Step 3: Download the git repository and match the files up (the git will have an /src folder that will be merged with your /src folder, etc.) Note: the github repo will not contain everything which is why Eclipse can't find the project: the repo excluded the Eclipse project files! Step 4: Open in Eclipse.

FFS use pastebin.com

Do this: This way: https://objectpartners.com/2013/07/16/creating-self-contained-executable-jars-with-gradle-and-shadow/

Technically both, but installing Forge gives you a deobf Minecraft. Also, with an obfuscated jar, you can get gradle to deobf that as well, I just don't remember how.