Abastro

I didn't notice that =P Then you'll find an ore vain in a chunk with probability of 6/100, since each ore has generation probability of 1/100 in a chunk, and they are mutually exclusive. Do you get more than that? Also there is a minor issue: you need to use 100 instead of 99, as Random::nextInt(x) gives 0~x-1.

I think you should override ItemStackHandler, and call the comparator update on any method which changes the inventory contents. (On drain/fill call when doDrain/doFill is true)

You need to use CUTOUT layer for that. More information about layers, great article from TGG: http://greyminecraftcoder.blogspot.kr/2014/12/block-rendering-18.html?m=1 Even though it was written for 1.8, it shouldn't be changed much.

You're calling runGenerator on every chunk, which will generate at least one vein on the chunk. So just don't call it on 99/100 of the chunk. (Or only call it in 1% chance)

This should be tricky, as items placed in slot are rendered in fixed size. I'm afraid that you might have to override the rendering code of GuiContainer.

Using capability system for the inventory (Hence ItemStackHandler) is highly recommended, but not required. Please post the relevant code. (Block, TileEntity, probably the inventory as well) + here's the explanation on capability system; https://mcforge.readthedocs.io/en/latest/datastorage/capabilities/ There are many utility classes in net.minecraftforge.items package which are useful for setting up inventory as capability.

So it's client->server update from the gui. You need to implement tileentity syncing. I think this post will cover your case. You can manually read the data from the update packet with TileEntity#onDataPacket. Use it if you don't want readFromNBT to do the work. (e.g. update packet has a different format)

Would you check if the method is actually called? It seems that it might not be properly replaced.

It should work on either side, as it sends the update packet. How and where did you call it? Also how are you syncing the tileentity? Please post the relevant code.

Sorry about the blind guess. Would you post your current code? Specifically, did you override MovementInput#updatePlayerMoveState() to block the left/right movement? Also it's about blocking the strafe control input, right?

Override TileEntity::getRenderBoundingBox to return appropriate size of the rendered object. If it's about rendering, you are not marking the TE as updated for rendering. I think you should call World#markAndNotifyBlock. (The flag parameter is explained on World#setBlockState)

So you want to prohibit certain movement of player? Why? If it is for anti-cheat server, there is always a way to break it with another mod or something. It's better to do it on server by checking for it.

It seems that the part of the code is not obfuscated. Could you post your build.gradle file and the log from the gradle build command?

Well, I recalled it incorrectly What did you get as return from the method?

If I recall correctly, the second parameter of the drain method is about whether it'll be simulated(to check the validity) or the change is actually applied. So it should be false in your csse.

It depends on your platform. What's your OS? Do you know the graphic driver manufacturer? Here's what I got with quick Google search: http://m.wikihow.com/Find-Out-What-Graphics-Card-You-Have

1. You should not reference Minecraft on the event like that, especially when it could be called from both client and server. Create an event handler dedicated for client, and register it on the client proxy. 2. The event is called whenever an entity is created. You should check if the entity is a player, and cast the entity as EntityPlayer.(or EntityPlayerSP) 3. What kind of behavior do you want with it? This approach does not look fine.

There are overwhelming amounts of great documentations on opengl lut there, so I guess you won't have much problem with it. I found this post from quick Google search on FastTESR. Based on the answers, you can specify the vertex positions, uvs and colors on FastTESR. (There are more props but these are basically what you would need) Figure out the math for your case, i.e. calculating the positions of each vertice of the block. Then it's just matter of notifying vertexbuffer about the vertices in right order. (Give every information -pos,uv,color- for a vertex and move over to the next one) Don't forget to stitch textures on the texture map. As far as I know, you can't overlap TESR(or FastTESR) and normal model. So I guess you should render other 3 parts with FastTESR as well.

It's usually a bad idea to set the base value of health. Is there a reason you can't do this with multiplier attribute modifier? If you can't to it, setting the event priority to LOWEST might work. It marks the event subscribing method to get called on the last pass.

I think this tutorial will cover your case: It's old tutorial, but the basic concept shouldn't be changed.

You only need tint(color), right? Then it is feasible only with Json model and Block#getColor(Or something similar). Look at the model code of vanilla spawn egg to figure out the tint, and wool code for specifying the color. (As far as I know you can reference world and position there)

That one is obvious, since BlockModelRenderer#renderModelBrightness will call VertexBuffer#begin() in its own, you shouldn't call the begin method yourself. Same will apply for Tessellator#draw(). It seems that there's problem with lighting texture settings while in the TESR.

Use World#notifyBlockUpdate(BlockPos pos, IBlockState oldState, IBlockState newState, int flags) instead of worldObj.scheduleBlockUpdate(pos,this.getBlockType(),0,0); For rendering update, you will need 3 as flag.

Check all part where the casting capability is injected. Client-only code shouldn't be referenced on the same class with the injection.

There is a way with reflection for that, look at how the dynamic texture is managed.