ChampionAsh5357

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.

You probably shouldn't inject your capability into two locations then. If you look at your PlayerHandler class, you can see that your capability will be injected into this location, calling the class with a bunch of client side only imports.

That's the mistake, never follow a tutorial word for word. Even though you probably just didn't register the DeferredRegister to your mod event bus. I can't see it, you don't have it working, it makes for a great combination of trial and error when this could've been done in a single post. Please post your code next time.

Ah ok. So to answer your question, you would need to put it into a specific tag and then overwrite the vanilla recipe. By default, Forge replaces almost all instances of iron ingot with 'forge:ingots/iron' through their recipe provider. The few that remain are iron block and iron nugget (since they are specific to the block version). So, as long as both items are in the specific tag and the tag is referenced in the recipe, it will take in anything within that tag (which would be your modded item). Do remember though if you plan on using something similar to ForgeRecipeProvider's implementation to replace the item with a tag that you exclude items that would be exclusive to that item set. Else, there will be even more issues with commonalities between recipes. Since the items are more abstract, you might not want to use a forge domain for your tags. One of the examples I can point you towards is endermen holdable blocks. This is a tag used to determine if an enderman can hold a certain block. This has a lot of different items that are not related to each other. However, they are for a unique purpose. In your case, if the items you want inputted cannot be condensed to a common group, then it would be best to just use a unique tag specific to your mod rather than a forge tag. And I assume when you say 'mark their tags manually,' you mean create the variable that holds your tag instance. If you would like to use it in your code then yes. If it's only for reference in recipes or advancements, you don't specifically need to. I do it because I use data generators to create tags for me. And you can add to already existing tags without replacing the data within them as long as "replace" remains false in the json file. Hopefully I have answered your question.