ChampionAsh5357

Please link a repo holding your code. I'm just gonna go through it in one pass instead of modifying each individual detail with little to go on other than a picture.

You can't really do this. When the class is first called by the event bus loader, it will declare these variables prior to the registry phase. So, it will initialize both of these values to null. Just create the variables locally in the event since you're not using them anywhere else. Two more things, if you need to cast the value to BlockState, you're doing BlockStates wrong. Second, everything must be wrapped in a DeferredWorkQueue as everything you're doing is not thread-safe.

Hopefully you are talking about the latest versions of mc instead of the one this is on. As for how to do it, just append a LayerRenderer to the player and render whatever you want on top of him. Do note that every layer is usually rendered as a cutout which may cause issues with culling depending on how it's ordered.

You can use IRecipe, you just have to be particularly clever about it. Basically, you can just add a new method that returns the IFluidStack instance. You would just need to add to your deserializer how to get an IFluidStack.

Just use a standard TileEntityRenderer.

You need to change the render type to either cutout/cutout mipped(if there's no transparency) or transparent(if there is) via RenderTypeLookup::setRenderLayer. If you're model also isn't a full cube, you should adjust the VoxelShape (via Block::getShape) as well so it encapsulates only the space your model takes up.

I did link the website that shows you exactly how to structure the tag. What do you have so far?

1.7.10 is not supported on this forum. Update at least to LTS 1.15.2 to receive support.

CraftingTableBlock, WorkbenchContainer, and ContainerScreen is a good start. As for the furnace, you're probably gonna need to slap an Abstract in the front and look in the respective packages as the three mentioned including tile entities.

In your result object, create an nbt object that holds your nbt data. If you don't know how nbt data is structured, you can look it up.

I think you can use IBlockReader::getFluidState on the current position of the player and check if its not empty.

That's not a crafting table problem, that's an implementation problem. You can look at ShapedRecipe to know how it gets the information from JSON and WorkbenchContainer on how to apply it.

It's been done a thousand times over. Create the json file as you would any other crafting recipe and set the width and height via ShapedRecipe::setCraftingSize in your common setup event.

This isn't an event, its a pose defining a bounding box for the entity. The pose, coincidentally, is called Pose#SWIMMING and occurs whenever the player gets stuck in ANY SPACE that is too small for the current box. Then you should fix your workspace.

I'm gonna disagree here. If you are creating crafting recipes, it is in fact supported by forge. However, only on the result (which is what I'm assuming you are doing). You should only create a custom implementation if your ingredients hold any nbt data or creating your own crafting system.

That's an issue with synchronization. Whatever data you are calling is not synced to the client most likely. Read up on sides.

That's not a good way to problem solve. Asking for the answer without even showing an attempt is just bad. I'll explain the process that's needed; however, someone else can just give you the code. There are a few things to note. First, you can't use the normal spawn egg method as it doesn't contain supplier for later access. Items are registered before entities so they will not go into a spawn egg. So basically, you need to create your own SpawnEggItem extension that takes in a supplier, passes in a null value for the original, overrides the default entity type gotten from the egg, and adds the unadded eggs to the original list using via reflection after entity types have been registered. You might want to take a look at how SpawnEggs are stored and how their dispenser behavior is handled before attempting this.

1.7.10 is no longer supported. Please update to LTS 1.15.2 to get support.

Wherever you made the reference. Did you even make a reference? Go make a reference that's callable on the client with the correct information.

It should reference an instance of your armor model that's stored in a physical client side reference. I just realized I need to fix my tutorial because calling ClientProxy on the server is a big nono.

wdym? your armor model should extend BipedModel, not be named it. You can name it whatever you want, its a class

No, the generic can specify anything your class is extending. However, its much easier to notice if you have the class being referenced instead of a parent of the class.

Called it. Definitely called it. When you finish posting and stack trace and the repo, you should probably get on creating a custom entity spawn egg that accepts a supplier of an entity type instead of the actual entity type. Items are registered before entities so entities don't exist when you try to register the spawn egg. Any other error location and fix can most likely be determined from the repo and stack trace.

The best guess with a lack of current information is that you tried to make an spawn egg for your entity. If we can't see every time you call PALAEONISCIUM_ENTITY then we cannot help you. Do what Daemon suggested. Otherwise, we're just guessing.

Uhh. When I check PlayerHandler again, I still see capability inject within it. You do have to remove the annotation as well.