Jay Avery

The basics of blockstates and metadata haven't really changed from 1.8 to 1.11.2, so old tutorials should cover the fundamentals well enough. The forge docs are a good place to start if you want to know how something forge-specific works. And the vanilla code itself should also become your best friend - look for blocks which have variants and states that work in the way you want, and see how they are coded. For blocks with more than 16 bits of data, you can use a TileEntity. This is what vanilla uses for furnaces, chests, signs, and other blocks which hold complex information.

Post the log, it should contain model/render errors.

Wow, I had no idea. Does that also render the top surface if the block doesn't have water on top of it? What about if the block is on its own and not surrounded by any water?

Post the latest log, it should contain model/texture errors.

Assuming the block is a subclass of BlockFluidBase, you can use BlockFluidBase.getDensity(IBlockAccess, BlockPos).

It's not that the method is being executed. It's just that Java (tries to) load all the classes it finds references to when it loads one class - so as soon as it tries to load your ModTE class in order to call the init method, it goes through the whole class and finds references to some which it can't find (because they aren't present on the server) and crashes immediately. @SideOnly is okay to use in the right circumstances, but because of the way Java loads things it's safest to keep client and server side code in completely separate classes - putting a side annotation on a method is not completely reliable.

You need to add the LEVEL property to your block's BlockStateContainer, by overriding createBlockState. Setting your block's material to water won't make any difference to the way it renders though. If you want it to look like water you'll need to model it yourself.

Apologies if this is an obvious question. When a mod has a config, a file will be created/edited/loaded on both the client and dedicated server, right? If so, what happens when the server and client have conflicting config settings? Do modders need to explicitly code to resolve these potential conflicts, and if so, how?

Is the breakpoint in your GUI handler being hit now?

No, you just use a dot in place of the :: or #, like this: player.capabilities.isFlying. It's just that when talking about methods and fields, it's useful to be able to distinguish at a glance whether we're talking about something static where you actually call it on the class (like EntityPlayer.staticVariable), or about something which must be called on an instance (like player.capabilities). Because an instance of something is (usually) stored in a variable, and a variable could have any name, it's potentially ambiguous to invent a variable name without specifying what class the object is an instance of. I could say "you need to use variable.capabilities", and you might rightly ask "but what is variable?". Or I could say "you need to use EntityPlayer.capabilities", and then you might come back and say "my IDE tells me I can't access a non-static field statically", because you'd get errors if you typed in exactly that. So the alternative to these two possibly-confusing approaches is to use the class name (which makes it clear what kind of object we're using) and use a hash or double-colon in place of the dot (which represents the fact that it should be called on an instance of the class).

Thank you so much! That seems to be working exactly as I want.

After swapping those two lines, the block doesn't seem to be visible at all (from any angle). Am I doing something wrong with translation?

Another mystery now. I've got a very basic TESR working - at the moment it just renders one block rotated at 45 degrees. But when I walk around the block, it seems to slide up and down along its axis - here is a gif showing what I mean: My render method: @Override public void renderTileEntityAt(TETrunk te, double x, double y, double z, float ticks, int damage) { GlStateManager.pushMatrix(); GlStateManager.disableLighting(); BlockPos pos = te.getPos(); GlStateManager.rotate(45, 1, 0, 0); GlStateManager.translate(x - pos.getX(), y - pos.getY(), z - pos.getZ()); Tessellator tess = Tessellator.getInstance(); VertexBuffer vb = tess.getBuffer(); vb.begin(GL11.GL_QUADS, DefaultVertexFormats.BLOCK); BlockRendererDispatcher dispatcher = Minecraft.getMinecraft().getBlockRendererDispatcher(); dispatcher.renderBlock(Blocks.STONE.getDefaultState(), pos, te.getWorld(), vb); tess.draw(); GlStateManager.enableLighting(); GlStateManager.popMatrix(); }

Ahh, thanks! Moving the rotate call to before VertexBuffer#begin fixed it, now the models render with rotation. Rendering code is such a mystery to me

I want to make an entity/tileentity (haven't decided yet) which will look similar to a structure made of blocks. I looked at RenderFallingBlock for ideas and found that it uses BlockModelRenderer#renderModel, passing BlockRendererDispatcher#getModelForState. This looks like what I want, but when I tried it I found limitations - it only renders properly when it's not rotated. When I tried adding a GlStateManager.rotate call before rendering it, the model just goes invisible (with no error messages that I could see). I tried looking through the rendering code to see if I could find the reason, but I don't really understand it. It must be theoretically possible to render a block model at an angle to the world axes, right? Because it's possible to define a model with components which are rotated, so the principle is surely similar. But is there a way to do this in code using the block's IBakedModel itself? Otherwise I'll be stuck trying to manually recreate the block model in the form of a ModelBase and render it that way, which would suck. Can anyone help me understand why the block model disappears when rotated, or suggest an alternative way that I can render a rotated block model?

Step through this method and find out why it's getting to the else block.

What does this mean? Where are you finding the ItemStack as 0xtile.air? Ignoring what you see in the code, what happens in the gameplay that is not what you expect? NBT is nothing to do with creating items, it's only about storing data when the world is saved.

Hint: Instead, you should use isPressed on the keybind you want to check. The act of calling this method will unpress the keybind, so you don't need to manually do anything else if all you want to do is cancel the behaviour. Edit: unPressAllKeys is a static method, so your IDE should be warning you about calling it on an instance anyway.

Is your model checking the entity's boolean field when it needs to know the awake status? Can you show where you do this?

You've already got a packet that handles an entity - it finds the correct one using its id. You just need to set the boolean in the entity itself, rather than setting in the entity's model field (which is unused and pointless anyway).

That's it!

It's run on both. But most behaviour is controlled from the server, so if the client needs to know something you have to send it.

Your render class returns a new instance of ModelBeelzebook, but your packet updates the model which you have stored in a field in the entity and which does nothing. Instead you should make the model render depending on the entity's awake status, and use the packet to update the entity itself.

Where do you register the entity's model/renderer?

On the client, you can use Minecraft.getMinecraft().world.