V0idWa1k3r

You would need to ray trace the block the player is looking at(World#rayTraceBlocks). This gets you a RayTraceResult that contains the side that has been hit.

The reason it's implemented like is is because it's a forge patch. Vanilla simply did item == Items.SHIELD when checking for a shield in various places. Forge removed those direct checks and instead did this patch to the item class. It's functionally the same, preserves vanilla's functionality and allows anyone to override this when they want to make a custom shield themselves. Or at least I assume it's a forge patch because it's together with the rest of them and has a javadoc.

That is for bedrock entity models. Or obj models. Not a java entity model so no go there. Notice how you used multiple independent models there. Not a single obj/json model but a collection of different ones. If you are rendering them through vanilla's renderers then yes, you do need to stitch a texture since this is where the game will look for it. You would also need to bind the default sprite atlas. However if you simply have a model that is not a IBakedModel you can just bind the texture and as long as your vertices carry the correct texture coordinates everything will just work.

I don't know about FBX but OBJ is a pretty straightforward format. It is easy to write a parser and a vertex uploader for an obj model. Something kinda like I did here. The OP wants to render mob models, not block/item models though. While it is possible to use an item/block model for an entity model it is impractical. Animating it for example would be a nightmare. I also have no idea what you are talking about with this You don't need to stitch anything for rendering an entity.

Well, BlockRendererDispatcher is a dispatcher. When the time comes to redraw a region the game iterates over blocks and sends the blockstates and positions it iterated through to the BlockRendererDispatcher along with the world the rendering is going in + the buffer for the vertices. That's all 4 arguments to the BlockRendererDispatcher#renderBlock. The dispatcher then decides how to render the block. It gets the EnumBlockRenderType from the state passed and checks against it. If it is INVISIBLE the block isn't rendered at all. If it is MODEL then the dispatcher gets the model for the blockstate it was passed and passes the rendering to BlockModelRenderer. If the render type is a LIQUID then it passes the rendering to a BlockFluidRenderer. Otherwise no rendering is done. BlockModelRenderer gets the model and iterates it's quads by side. It checks whether the quad should be rendered and if it is uploads it to the buffer(before that it applies lighting and color multiplier to the quad though). Oh and it also decides whether to render the quads "smooth"(read: with ambient occlusion) or "flat". BlockFluidRenderer is only used for water and lava since forge added fluids actually have a fluid model(kinda). Then it calculates the sides that should be rendered, the heights of the corners of the fluid interpolates the texture and uploads the resulting quads to the buffer. That's about how it all works. Since all methods are public you can invoke any part of the process yourself and render models/quads/blockstates to a custom BufferBuilder.

What exactly are you doing? You don't need to construct a new instance of BlockRendererDispatcher. All you need to do is call BlockRendererDispatcher#renderBlock. You can get an instance of BlockRendererDispatcher from MInecraft#getBlockRendererDispatcher and you can get an instance of Minecraft from Minecraft.getMinecraft(). That's it. However there is an issue with BlockRendererDispatcher#renderBlock where it asks the block for an extended blockstate. If it is a mod block that uses a TileEntity and extended state to pass some properties from the tile entity to the blockstate this will crash the game if the mod assumes that there is a tile entity at the position passed. That's why usually when people want to render blocks that aren't really there a fake world is used.

While it can be as big as you want the selection detection only works when you look at the 1x1.5x1 cube and not anywhere else. If you make your selection box a 10x10x10 you will only be able to see it when mousing over the 1x1x1 cube that produces this box. You will see the whole 10x10x10 box though. But this is not the behaviour you want since you want to see the box when you look at it, not the cube producing it.

As far as I am aware snow doesn't fall on blocks that are not full cubes(return false in Block#isFullCube)

Since the model is an obj model you can't scale it down using json(although you might be able to do something with the forge blockstates format since it allows you to specify transforms but I am no expert on that and whether you can specify your own custom transforms). However the issue here is different. You are trying to use a big model for a 1x1x1 cube. That will not work for a multitude of reasons. One of which you've discovered already - you can't use the same scaled model for an item model. The other issues would be the collision box, the selection box(none of which work with boxes bigger than 1x1.5x1), the block placement(blocks could be placed into your blockspace occupied by the model) and the frustrum culling(look up from your block and the model will dissappear from sight as soon as the block dissappears from sight(will only work in certain positions of the chunk if I understand MC's chunk rendering correctly as it uses and culls 16x16x16 regions, not individual blocks)) The solution to all those issues would be to scale your model down to a 1x1x1 cube and use a TESR to render it with the scale you need it instead. This solves all but 1(block placement, could be solved with transparent placeholder blocks) issues.

I don't think the OP wants to render fluids since they mentioned that they need the sprite for the average color to draw on a minimap. My solution would be to get the fluid associated with the block if it has one. If the block is LAVA or WATER then default to FluidRegistry.WATER/LAVA respectively, otherwise check if the block is an instance of IFluidBlock and use IFluidBlock#getFluid to obtain the fluid. Then once you know the fluid you can querry the sprite name using Fluid#getStill/getFlowing. Lastly you can now use TextureMap#getAtlasSprite to get the actual sprite(like I do here). You can even get the fluid's color from the fluid by using Fluid#getColor.

You can try it out. However if you are changing the player's motion parameters then you need to do so on the client - player movement is controlled by the client.

getLookVec is the direction he is looking at. It's the direction vector.

That gets the helper, not the direction which the OP was asking for. @Niinnnnnn use Entity#getLookVec

Because it is ancient. Do you really expect us to provide support for code that is outdated by 4.5 years at this point? Most of it no longer works since it was heavily changed(models, registries, capabilities, etc).

I just told you how. Ditch it entirely and register your models in the ModelRegistryEvent directly. Like I do here if you need an example. I have yet to see a "good" modding tutorial on youtube. All of them make mistakes like this, or static initializers, or CommonProxy or something else posts on this forum are plagued by. The truth is they don't know much more than you. They've just learned how to make their code not explode in their faces and they are eager to share that knowledge with the world even if their code makes no sense(CommonProxy, IHasModel) or is plain incorrect(static initializers)

IHasModel is stupid. All items need models, all of them, no exceptions. Nothing that is required by model registration is private to your item class either. Just register the model in the ModelRegistryEvent directly. This line screams "I was initialized in a static initializer!". Don't use static initializers. Instantinate your stuff directly in the RegistryEvent.Register. Like this. Not only is this the correct way of registering and instantinating stuff it also shortens your code to a 33% of what it used to be. See above. Don't use static initializers. Ever. fm is a terrible modid. Modids can be up to 64 characters long. Use those characters. No it doesn't. it crashes the game. Not the launcher. There is a big difference. It most likely does that because you are using a wrong super constructor invocation. The one that only takes in the ToolMaterial will crash the game since it does a lookup in an array by the material's index. And since the array isn't big enough it crashes the game. Use the other constructor, the one that takes 2 additional floats. But what do I know. You've never posted the code for the Axe, or the crash report. Apart from that we need the debug.log to figure out the problem. The log will have an error message telling you what exactly is wrong.

1.7.10 is no longer supported on this forum. Update to receive support.

Stop using IHasModel, it is stupid. All items have models. All of them, no exceptions. Nothing that is required by model registering is private to your item class. Model registration needs to happen in ModelRegistryEvent so do it there directly. Al this stack tag compound nonesense is no longer needed. It was a solution to a 1.7 problem. Nowdays the attack speed is controlled by the attack speed attribute modifier. ^This line. The -1.8D is the modifier. Change it to something else. This line screams "I was initialized in a static initializer!". Don't use static initializers. Instantinate your stuff directly in the RegistryEvent.Register. Like this. Not only is this the correct way of registering and instantinating stuff it also shortens your code to a 33% of what it used to be.

AnvilRepairEvent. You can get the "current anvil" from the opened container(event.getEntityPlayer().openContainer). It is likely an instance of ContainerRepair(although it might not be in case of modded anvils so you have to account for that). ContainerRepair has a selfPosition field you can use to get the position of the anvil. Although none of that is needed if you simply want to modify the break chance for the anvil. Just use AnvilRepairEvent#setBreakChance. There is no event for that. If you wish for one you can submit a PR. This is why you are using a EntityJoinWorldEvent in the first place - to replace the falling anvil entity provided by vanilla with your own wrapper/version that has the necessary hook.

Don't necropost. If you have an issue create a new thread instead of digging this 4 year old one. Things changed between versions and ItemStack.stackTagCompound can now be accessed via ItemStack#getTagCompound.

I've debugged your code. What's happening with the tile entity is by your logic first it consumes the items for the operation and sets the cookTime to 1. It also sets the smelting field to the output of the recipe. Everything seems correct so far. Apart from this condition: if(this.isBurning() && this.canSmelt() && cookTime > 0) This checks if the smelter is burning(true), if the cookTime is greater than 0(true) and if the recipe is correct(false)! It shouldn't check for the recipe since it already cached the output. Check whether the output is empty instead. As for the shift-clicking this is your issue: Slot slot1 = this.inventorySlots.get(index + 1); if(!AlloyerRecipes.getInstance().getAlloyerResult(stack1, slot1.getStack()).isEmpty()) You check if the item in the next slot + the item in the current slot make for a recipe. This Only works for one item, the one the player clicks and not the other since now the condition isn't true. Crashes the game if the player attemts to shift-click the item in their last slot You have to change your logic here and instead check if the clicked item can be used in a recipe, and if it can in which position, determine the slot according to that position and attempt to merge. Or just transfer the item in the slot regardless of whether it should be in that slot or not.

It would override any falling block. It doesn't matter whether the anvil is "new" or "old". It should also affect even the falling blocks currently in the process of falling.

I am not sure. With custom BakedModels, resourcepacks and RenderWorldLast event it is not something I can easily make a case for. If you can think of any other use case apart from yours then go for a PR.

If you think that these events will be usefull in any other scenario for modmakers then make a PR. New usefull events are always welcome.

EntityJoinWorldEvent happens every time any entity joins a world. As in every time World#spawnEntity is called. EntityFallingBlock is not an event. It's an entity.