V0idWa1k3r

The server has no concept of translation(or language at all for that matter). What OP did is the correct way. It send the lang key to the client and the client then translates it with the language the client has selected.

See how the slimes are done, they also have both a transparent and an opaque part. If I recall correctly it uses a separate layer to render the transparent part. I would suggest creating 2 separate models, render the opaque one in the main renderer and render the transcluent one in a separate layer. As for the particles - you will have to go through a lot of trial and error positioning your particles correctly. You can use a client proxy to get the model, then get it's parts and get their offsets and position however due to the way models and their rendering work you can't get any dynamic properties of the model(such as rotation for example) since MC will use 1 model instance for every entity and as such you will only have the rotations of the last entity rendered. An alternative hacky solution would be to spawn the particles directly in the renderer but make sure that you are not spawning the particle each frame but instead each tick. That way you can also get the current rotation of your part. Then you can construct a matrix, translate it by offset, rotate it by rotation, translate it by position and multiply your particle origin vector by that matrix to get the position. That is theoretical though, I've never tried anything like that.

Well, first of all Don't use GL directly. Whatever you are doing can be achieved by different means. In this case a BufferBuilder will do the trick just fine. In other cases use GlStateManager. Secondly, MC expects vertices to be specified CCW, but glRect specifies them CW. You can most likely disable culling(or change the cull method) and see everything working just fine regardless of the order. Also 1.10.x is outdated and you should update to the latest version(1.12.2).

All I can recommend is stop using the BlockEntityTag hack. Do the following: Make your ItemBlock have the capability that stores your values(check) When the block is broken/harvested create the item and then copy the capability data from the TE to your item's cap. When the item is right-clicked open your container-gui pair with the data pulled from the item's capability(check) When the ItemBlock places your block access it's TE and copy the capability data from the item to the block's TE. Currently you are storing the TE's data using BlockEntityTag which is completely detached from your capability.

If the method is static you don't need an instance to invoke it. This is basic java. As long as RegistryHandler is subscribed to the event bus this will work, yes.

A handler can be declared anywhere you want as long as it is registered. Here are the docs on the events and handlers.

As the error message tells you you need a RegistryEvent.Register<EntityEntry> as an argument to your event handler(you currently have no arguments at all). When you declare an event handler you specify the event you listen to by having that event as the argument to the listener method.

No, I use it to call clinit and make the data parameters of the entities initialize so both the client and the server are aware of them. I've had an issue with the client not having the parameters initialized and the corresponding client->server connection crashes. This is just a hacky fix I've implemented to solve that problem.

cb is a terrible modid. Do not use EntityRegistry. Use RegistryEvent.Register<EntityEntry> and build EntityEntries using EntityEntryBuilder similar to how I do here. Apart from that everything looks correct to me. Put a breakpoint in your registerEntities method and see if it is executed at all.

Entity#getRidingEntity

This is not how vectors work. You need to get an angle between your vector and the default unitZ vector to get the rotation you need to apply around the Y axis. As for your direct issue - you must bind the TextureMap.LOCATION_BLOCKS_TEXTURE before rendering your TE otherwise the last bound texture is used.

BufferBuilder is just a way to specify a vertex collection for OpenGL to render. A vertex is ultimately just a collection of data OpenGL uses to draw things. At the very minimum it needs the position in world-space to render anything at all. You start by specifying a format and a draw mode. The draw mode specifies what the vertices mean(ex. 4 means a quad with GL_QUADS) and the format specifies the way the data is aligned in each vertex(ex. POSITION_TEXTURE_COLOR means that each vertex contains 3 floats that specify position, followed by 2 floats that specify the uvs for the texture followed by 4 floats that specify the color). The only thing that might confuse you are BLOCK(3 position, 4 color, 2 texture, 2 lightmap) and ITEM(3 position, 4 color, 2 texture, 3 normal, 1 padding) formats. Then you specify the vertices based on the format you've selected. You do that by calling the respective methods. For example to specify the position you would call BufferBuilder#pos. Keep in mind that the order must be the same as the order defined by the format(ex. if the format is POSITION_TEXTURE_COLOR the vertex definition would be pos(...).tex(...).color(...)). Then you end the definition of each vertex with BufferBuilder#endVertex similar to how you end sentences with a dot. These methods can conviniently be chained to compact the code. So you can do bufferbuilder.pos(...).tex(...).color(...).normal(....).endVertex(); Once you've specified all the vertices needed for your drawing you finally call Tessellator#draw. Knowing that you can easily adapt the BufferBuilder to render a wavefront object. Parse your object in a way that gives you a collection of vertices each containing the data you need(position, uvs, normals) and then simply iterate over the collection adding each vertex to the buffer. As an example here is the way I parse the wavefront into a collection of vertices and upload those vertices to the buffer. As a bonus here is the way I use a FastTESR to render the parsed wavefront into the buffer provided by the FastTESR(with matrix transformations). I hope my explanation and the examples provided help you.

I can't replicate the issue with a test setup. Could you provide more of your code? Providing the texture itself would also be helpful. I have my suspicion on parameters like this: but I can't confirm them since I do not know their values/the way the method you are using is using them.

Don't ever call GL functions directly. Use GlStateManager. You can see how vanilla does that at GuiIngame:L526 but the relevant state manipulations occur at GuiIngameForge:L131||L261. This is fully controlled by the alpha function, if I recall correcly MC uses GREATER 0.1 meaning that anything with less than 10% alpha is discarded. If ALPHA_TEST isn't enabled at all then no fragments are discarded and alpha is simply ignored. OpenGL doesn't do any clipping as far as I am aware.

This must be static and final. And you also must provide a SRG name otherwise this will not work in a non-dev environment. Java's docs on reflection. The get method takes an instance of the class that field belongs to to get the value for that specific instance. Then check if the object you get is an instance of your container/interface. You must set the field to be accessible before getting it's value since it's private using Field#setAccessible.

Alternatively the InventoryCrafting has a Container field named eventHandler that holds the reference to the parent container of the inventory. Reflect that field, get it's value and check if it is your container(or better yet a common interface of some kind to allow other mods to potentially implement custom crafters for your recipes)

Which part of did you not understand?

That is not how you define states in forge blockstates. If you want to use vanilla syntax use vanilla format. This doesn't work the way you think it does. It's not the same as the update method of TileEntities that gets called once per tick. This method gets called once per tick... on one random block in all loaded chunks. public boolean isMaxState(IBlockState state) { return ((Integer)state.getValue(this.getStateProperty())).intValue() >= this.getMaxState(); } This will never be true as your state property is within a [0-1] range and getMaxState returns 7 for whatever reason. Also you don't need half of these methods, they just make your block class bloated. Never copy vanilla code and simply change the names of methods and variables without understanding of what's going on. @Override public int getMetaFromState(IBlockState state) { return ((EnumFacing)state.getValue(FACING)).getHorizontalIndex(); } @Override public IBlockState getStateFromMeta(int meta) { return getDefaultState().withProperty(FACING, EnumFacing.getHorizontal(meta)); } You must include your state property in metadata serialization/deserialization. @Override public BlockStateContainer createBlockState() { return new BlockStateContainer(this, FACING); } You must include your state property in the BlockStateContainer created. public static final PropertyInteger STATE = PropertyInteger.create("state", 0, 1); If your integer is only within a [0-1] range then you don't need an integer, you need a boolean. Here are the docs on the blockstates.

No, I mean properties that you define in your blockstate container. For example the growth of crops, variants of stone, whether the leaves will decay, etc.

This doesn't work the way you think it does. It's not the same as the update method of TileEntities that gets called once per tick. This method gets called once per tick... on one random block in all loaded chunks. This is always true since this sets the isActive field to true. Blocks are singletons. You can't use fields to store per-block data. Use block properties.

Assuming that 1 block is 1 unit 1 pixel would be 1/16 of that unit(0.0625). Also don't use GL functions directly. Use GlStateManager.

Emissive quads are possible with a custom IBakedModel, a TESR isn't needed here. You would need to create and load a custom IBakedModel and generate a list of custom BakedQuads that have their lightmap data set to anything apart from 0, say 240 for full emission. An example can be found here.

Just check if the player's look vector intersects with the entity's AABB like I do here.

No java packages/classes are obfuscated so the build method is irrelevant here. Besides The OP is already using gradle to build their project.

Some(for example beds and shields) items in the game are rendered via a TileEntityItemStackRenderer. Those can't be rendered through a IBakedModel since they don't have one themselves. It also won't work with modded items which use TEISR.