Jump to content
Currently supported: All versions

kiou.23

Members
 View Profile  See their activity

  • Posts

    444

  • Joined

  • Last visited

  • Days Won

    5

 Content Type 

Posts posted by kiou.23

    How to update your mod from 1.16.4 to 1.16.5

    in Modder Support

    Posted

    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)

    • Like 1

    [1.16.5]Attaching an inventory to an item

    in Modder Support

    Posted

    35 minutes ago, Skelyvelocirap said:

    I am really confused tbh. How exactly am I supposed to do that?

    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);
    }
}

     

    [1.16.5]Attaching an inventory to an item

    in Modder Support

    Posted

    11 hours ago, Skelyvelocirap said:

    How do i check the type of capability its returning for with this method though?

    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.

    [1.16.5]Attaching an inventory to an item

    in Modder Support

    Posted

    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.

    How do you find the functions you need to modify (when you know what you want to do)?

    in Modder Support

    Posted

    2 hours ago, InspectorCaracal said:

    Ohhh. Okay! I've been trying to find the vanilla code and also not been able to find anything about where it is, so it sounds like that's the root of my problem. Where is it?

    (And yeah, my best guess is that the check is done on the hive itself, so that's where I wanted to look first.)

    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.

    How do you find the functions you need to modify (when you know what you want to do)?

    in Modder Support

    Posted

    51 minutes ago, InspectorCaracal said:

    I'm specifically looking into campfires, beehives/nests and bees, and I've collected all the relevant information about tags, block states etc. that's available on the official Minecraft wiki, but I was hoping to get a look at how exactly those interact. Is trial and error really the only way?

    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

    Custom Log Stripping

    in Modder Support

    Posted · Edited by DaemonUmbra

    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)

    [1.16.5] Cannot change custom item durability in use()

    in Modder Support

    Posted · Edited by kiou.23

    5 hours ago, Luis_ST said: 
    

playerEntity.getItemInHand(hand).setDamageValue(playerEntity.getItemInHand(hand).getDamageValue() + 1);

    this is the best solution for your problem

    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

    Crafting Table

    in Modder Support

    Posted

    1 hour ago, Blooode said:

    I have block, container and gui. But what I need to do my custom recipes in it?

    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

    RegistryEvents issue

    in Modder Support

    Posted

    25 minutes ago, LuccaPossamai said:

    These things you've said interferes in the problem?

    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

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.

  I accept