Draco18s

Why are you not using Capabilities?

Just draw something else over the top. I do something similar here: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/industry/client/gui/GuiContainerFilter.java#L67-L71 It draws a section of the gui texture I already have over the slots (and behind items) any time the TE says that it doesn't have any filters (i.e. your "when some condition is true"). The visual ends up looking like this: http://vignette1.wikia.nocookie.net/reasonable-realism/images/7/73/Filter_no.png/revision/latest?cb=20150419162009[/img]

No idea. You might be trying to do something that isn't really supported by the existing hooks.

Subscribe to LivingUpdateEvent.Pre and cancel some.

...give them a speed modifier attribute? It's what the Speed/Slowness potions do (mechanically, they also do other things like particles).

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.