Draco18s

That definitely says that the update packet is not being sent.

Show where your textures are located, using File Explorer (not eclipse).

You should register it in common code. Either: a) main class b) common proxy c) the registration event

Show your common proxy.

By the way, you should be exposing the capability via getCapability. Which is how you should access it yourself. As for why the lava vanishes, I don't know. Try using the debugger.

You should be rendering your renderers in the client proxy. The "difference" is that the client proxy only loads on the CLIENT not the SERVER because the server doesn't know jack about models and textures.

Because the parser is set up to read it that way. When it is two different properties the cartesian product is computed on the fly and it isn't set up to add the values.

Either: Use the vanilla way of specifying block states. Or: Use two models, one of which is pre-rotated upside down.

You don't implement interfaces anymore, that's why the Capability system exists. You need a liquid handling capability, I do not know if Forge has one or not.

Rotations are atomic. By specifying two different rotations for the two different block properties, the one overwrites the other. Yes, you have "x" in one and "y" in the other, but that's just convenience. What you're really saying for both is "rotation":"0,90" or "rotation":"180,0" and they don't add together.

Not easily, no. You'd have to subscribe to the PlayerTickEvent (or EntityLivingTickEvent) and search the 3x4x3 volume around the entity for your fire block.

public class TileEntityStoneCrate extends TileEntity implements ICapabilityProvider{ TileEntity already implements ICapabilityProvider

Because the people here on this community forum know more than Mojang do. 1.11.1 has no set release date. You could have found this out by looking pretty much anywhere else. Namely here: http://minecraft.gamepedia.com/1.11.1

Give yourself a separate registration method that doesn't do items. It's what I did. Also, statemapper stuff is client side.

Getting the pickblock, saving it to a variable, and checking if it is null? Like, how else?

Someone is tired https://encrypted-tbn1.gstatic.com/images?q=tbn:ANd9GcROlbWTJqFGprIkYTopxtQ7BTuaCdEI9YJKPw-lR6SO0doaSzBa[/img]

Which null check, mc.currentScreen == null or .getDisplayName().equals(null) ? Because the latter won't work if the result of getPickBlock() is null, because you're taking null, asking for its name (crash!), then comparing the result to null.

And what is at/around lookGUI.java line 44? (Also, why does that classname start with a lowercase letter?)

Always post the crash log.

Again, though, the method is not marked as @Deprecated.

The problem there is that both: a) the block might not have an ItemBlock (most crops, cake, door, many redstone objects) b) the given state might not correspond to a special item (leaves, for example: the 4th bit is just a "did the player place this" flag) The latter is probably not something that will cause an error (maybe not even unexpected behavior), but the former absolutely will.

No, it doesn't, really...There is no visible relationship between ItemStack damage value and block metadata Let's see...where is getMetaFromState invoked in vanilla... Block#createStackedBlock (creating an ItemStack) which is called by Block#harvestBlock BlockNewLeaf#getItem (creating an ItemStack) BlockSilverfish#getItem (creating an ItemStack) BlockTallGrass#getItem (creating an ItemStack) GuiCreateFlatWorld#drawSlot (creating an ItemStack) And then four different commands (Clone, ExecuteAt, Fill, TestForBlock) as well as writeEntityToNBT in both EntityMinecart and EnttiyFallingBlock (for other purposes). It would appear that block state->meta is correlated with ItemStack metadata (due to the default implementation of harvestBlock and createStackedBlock). getMetaFromState is also not marked @Deprecated. It's getStateFromMeta that's deprecated. As for using it, yes, I agree it should be used as sparingly as possible. But it's not inherently wrong.

Except when you do, such as registering variant ItemBlock models... Mind, that's the only time I've had need of it, and there's currently at least one spot in Custom Ore Gen that uses it (admittedly because it was easier to update by saying "convert back to metadata" than "change the way 44 config files are structured and parsed." Correct? No, but faster so that at least the mod was available on 1.10). And vanilla uses it to create an ItemStack of metadata blocks, which is a Thing that I could see a mod wanting to do (such as the OP is trying to do).

What do you mean by "glow"? "Glow" is not something shaders, or really, any part of rendering does. There are a variety of possible effects to which you could be referring to, I'm trying to suss out which one.

Well, yes, if your resources aren't present, then of course you'll get those errors. That's kind of what they're there for.