V0idWa1k3r

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.

Don't include the .json extension in your path either.

Don't include the loot_tables folder in your resource path when registering the table, mc does that for you.

What behaviour do you expect? If you want different block names you need to override Item#getUnlocalizedName(ItemStack) in your ItemBlock. Vanilla does this using ItemMultiTexture as the ItemBlock for the dirt block.

That is how metadata works. You have 1 block ID that can have metadata to differentiate between different variants. You can't have unique registry names for metadata variants, that's not how this works. Code-style issues #1 and #3

No. This is not how java works. register is a static method. You do not need a new instance of LootTableList to register your loot table. You must register your loottable with LootTableList.register.

What are these packages? It should be net.minecraft.world.gen for ChunkProviderServer, not net.minecraft.server.v1_13_R1. And what are these method names? How did you set up your modding environment? What version are you using?

What do you mean by "casting is not possible"? Casting is perfectly possible and is the valid solution in this case.