kiou.23

we can't know if everything is in the correct location if you don't provide a repository for us to check. but by the log it seems that this file "emeraldarmor:models/item/testitem.json" does not exist

This is a good tutorial: https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe31_inventory_furnace

make sure the path is correct. you're using intelliJ, so you may have accidently named a single folder "assets.perry.textures.entity", instead of creating multiple nested directories. only use dots for java packages

does it have the same methods? does it serve the same purpose? this sounds like something you could figure out by yourself

Forge 12.18.3 was for 1.10, which is no longer supported. Please update to a modern version of Minecraft to receive support.

you'll need to be more specific than that not a lot has changed from 1.16.4 to 1.16.5, so your code shouldn't be breaking. However, what may be happening is that you were using mcp mappings, but now the project is with mojmaps. You can try to refactor the code to update the mappings, or just switch back to using mcp mappings (given that this is the actual issue, I'm just assuming it is since you didn't provide more info)

the job of the CapabilityProvider is too handle and expose all the capabilities for an object. In the getCapabilities method, it will check for which capability that is being requested, and provide it. in the Item class, the point of the initCapabilities method, is just to say which CapabilityProvider will handle it's data. so if what you need is an Inventory, you'd have an "InventoryProvider", which when the ITEM_STACK_HANDLER capability was requested, would return the Inventory. and in the item which has this inventory data, it would return this InventoryProvider in initCapabilities. Here's an example: public class BackpackCapabilityProvider implements ICapabilitySerializable<INBT> { // BackpackItemStackHandler is just an extension of ItemStackHandler which makes sure no Backpack can be put in the inventory private BackpackItemStackHandler backpackItemStackHandler; // This instantiates the Inventory only when it is first requested, and then caches it @Nonnull private BackpackItemStackHandler getCachedInventory() { if (backpackItemStackHandler == null) backpackItemStackHandler = new BackpackItemStackHandler(); return backpackItemStackHandler; } private final LazyOptional<IItemHandler> lazyInventory = LazyOptional.of(this::getCachedInventory); // Provides the Inventory @Nonnull @Override public <T> LazyOptional<T> getCapability(@Nonnull Capability<T> cap, Direction side) { if (cap == CapabilityItemHandler.ITEM_HANDLER_CAPABILITY) return (LazyOptional<T>)(lazyInventory); // If we needed to provide more than one capability, we'd simply add another check: // if (cap == SOME_OTHER_CAPABILITY) return (otherCapability) return LazyOptional.empty(); } // Saves the Inventory data to an NBT tag, so that it can be saved to disk @Override public INBT serializeNBT() { return CapabilityItemHandler.ITEM_HANDLER_CAPABILITY.writeNBT(getCachedInventory(), null); } // Reads the Inventory data from an NBT tag that was saved to disk @Override public void deserializeNBT(INBT nbt) { CapabilityItemHandler.ITEM_HANDLER_CAPABILITY.readNBT(getCachedInventory(), null, nbt); } }

you don't. You'll check the capability type in the provider; And in your initCapabilities you'll return an instance of said provider. If your item needs more than one capability, just make a Provider which provides multiple capabilties depending on which one is requested.

an IItemStackHandler, not an IInventory, they have a better api

You need a capability, and a capability provider. the capability is just a class which will hold your arbitrary data, for an Inventory, you want an IItemHandler (which handles ItemStacks). forge already has a default implementation of IItemHandler called ItemStackHandler, however you can create your own for custom behaviour. the capability provider is a class which implements ICapabilityProvider (orICapabilitySerializable<INBT> if you need save and load the data between sessions). In it's getCapability method, if the requested capability is your capability (or if it is just an inventory you can use CapabiltiyItemHandler.ITEM_HANDLER_CAPABILITY), and then return a lazy instance of it.

doesn't vanilla already allow you to tp to any player's position?

you're not forced to code in eclipse. other options are IntelliJ, or VSCode (although vscode requires some setup, and therefore is not really recomended)

you can check the code using your IDE, it should have a code navigation feature, which allows you to read class definitions, method references, interface implementations and all that I believe that in IntelliJ you can press double shift to search for files, and in there you can search for the source.

the error points to your FrogEntity constructor: at me.mcartyr.tutorial.entities.FrogEntity.<init>(FrogEntity.java:31) ~[main/:?] {re:classloading} can you post it (and mark what line is line 31)?

I'd start by reading the beehive and the campfire methods... and looking for lines of code that handle the interaction. for instance, does the campfire or the beehive have a tile entity? if so that logic could be handle in the tick method. if not it's probably done through random ticks, which is done in the tickRandomly (iirc) of the block. the beehive was added in a later update, and the logic concerns it's state and doesn't affect the campfire, so I'd assume that it is handled somewhere in beehive related code. reading through the vanilla classes is how to get around and understand, for the most part

Like that.

you need to get the rotation from the current block, and set the same rotation state to the new stripped block you can do so by using BlockState#with, and set the orientation and you can get a state with BlockState#get

Learn basic java, and don't copy and paste code you don't understand. in the onItemUse method, you can get the block the item has been used on through the ItemUseContext. and you can change the block and/or blockstate in a position with World#setBlockState also, when you're posting code in the forums, use the proper code tool, not the quote tool, that way your code won't be a non-monospaced, non-syntax-highlighted hell to read oh, and also also, help with coding should go under the Modder Support forum, not ForgeGradle (Moderator: Thread Moved)

the only way in which this code differs from his, which is storing the ItemInHand in a local variable, is that this is less readable. as Lupicus said, his code works, he's probably just in creative mode. creative mode cancels any attempts at damaging items when using them

do you already have a custom recipe implemented? if not, you'll a class that'l hold the recipe and check for matches, the recipe inventory and the recipe serializer then it's up to you to write the logic in your container. you can use of the world's recipe manager to see if a recipe inventory matches any recipe

the portal is just a block that when the player is inside, teleports him to the nether dimension you can look at the vanilla source code to see how it's done

you can't use of the vanilla recipes for this. you'll need to implement your own. take a look at the special recipes (I think that's what they're called, the recipes for fireworks are like that)

it means that the event fires on the server, not on the client... here's a resource to understand what the server and client are (and how single player also has this client/server distinction): https://forge.gemwire.uk/wiki/Sides

the 3 first no, not really. but you should fix them the last 2 should point you torwards the general direction of how to solve your problem but here is the thing when using RegistryObjects: you can call .get() on static initialization (so since your items are statically initialized, you can't call any RegistryObject#get() in their definition). that's because at static initialization, the RegistryObjects haven't been populated yet, you need to wait until setup to be able to call .get() so the way to work around this, is to just pass the RegistryObject itself (or any other supplier, the RegistryObject is just a fancy supplier). so then the entity won't try to be unpacked when it doesn't exist yet (i.e.: static initialization), and you unpack the Entity registry object whenever you actually need it. Also, if you look at the vanilla spawn egg, you won't see this that I'm talking about, because vanilla doesn't use RegistryObjects

No, forge is not compatible with java 16 it supports java 11, but the recommended is java 8 (as that is what mojang used) I believe that future versions of forge, for MC 1.17+ will support java 16 however, as mojang are updating too