Jump to content

deddybones

Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by deddybones

  1. It's an old thread but there is no posted answer and I was experiencing this mysterious error message today as well. The error message in question: java.lang.IllegalStateException: Created block loot tables for non-blocks: This is triggered when a loot table is being generated for a block that is unknown to the builder. To tell the builder a block exists, you need to override the getKnownBlocks method. For example, consider the following class snippet where we define a DeferredRegister for blocks: public class ModBlocks { public static final DeferredRegister<Block> BLOCKS = DeferredRegister.create(ForgeRegistries.BLOCKS, MOD_ID); public static final RegistryObject<Block> MY_BLOCK = registerBlock("my_block", () -> new Block(BlockBehaviour.Properties.ofFullCopy(Blocks.GRANITE))); // ... Other blocks public static void register(IEventBus eventBus) { BLOCKS.register(eventBus); } } We need to then tell the loot table builder that this block should have a loot table generated in our loot table generation class. This might look look like: public class ModBlockLootTables extends BlockLootSubProvider { private final List<Block> VANILLA_BLOCKS_CHANGED = List.of(Blocks.CLAY); public ModBlockLootTables() { super(Set.of(), FeatureFlags.REGISTRY.allFlags()); } @Override protected void generate() { // Some vanilla block with a loot table we are changing: this.add(Blocks.CLAY, block -> createSingleItemTableWithSilkTouch(block, Items.CLAY_BALL, ConstantValue.exactly(9.0F))); // Our block we are also defining a loot table for: this.dropSelf(ModBlocks.MY_BLOCK.get()); // ... Other blocks } @Override protected @NotNull Iterable<Block> getKnownBlocks() { ArrayList<Block> iterableBlocks = new ArrayList<>(); // define empty list // Iterate through each block registered into ModBlocks.BLOCKS and add it into our list: ModBlocks.BLOCKS.getEntries().stream().map(RegistryObject::get).forEach(iterableBlocks::add); // The above line requires that we need to have defined a loot table for every block in ModBlocks.BLOCKS. // Also add the vanilla blocks we are updating: iterableBlocks.addAll(VANILLA_BLOCKS_CHANGED); return iterableBlocks; } } Note that in this example, I demonstrate additionally how if you are overwriting a loot table for a vanilla block, you must also tell the builder that vanilla block exists. This solution does depend on some quirks of a developer's implementation; if you're looking for more detail, feel free to visit my GitHub for where these code snippets originate: Tech++ Hope this helps.
  2. After much experimentation I finally realised why this doesn't work and how to fix it. The critical component to understand here, is that ItemCraftedEvent is called before the crafting ingredients are purged from the crafting slots; this all happens in ResultSlot.java's onTake method: We can see here the first line fires checkTakeAchievements, this is what fires the ItemCraftedEvent (after a few method calls). Then we can see the purge behaviour. I worked around this by creating a CarverItem class, which uses hasCraftingRemainingItem and getCraftingRemainingItem to hook into ResultSlot.onTake: Now, I reconstruct my ItemCraftedEvent handler, and using some smart tags (which I omit for brevity), I handle two cases: 1. When crafting a carved item, I damage the tool used in the recipe 2. When crafting a carving tool from a repair recipe, I manually purge the input tools as with the new CarverItem class, as otherwise items would be duplicated This has now greatly improved implementation, beyond my expectations, for the standard crafting table and the user's inventory crafting grid. A user can now click or shift-click 'carve' items, with no duplication or issues that I have spotted so far.
  3. Hi, Full context, in case of oversight from me: using a @SubscribeEvent for ItemCraftedEvent, I am trying to implement a crafting system for 'carving', where I have tools that are tagged with 'can_carve' and items that are tagged with 'carveable'. A simple example here is a wooden handle item, which I have a recipe that uses a carving tool (I've tagged axes and a custom tool) and a branch item. I have this working to the degree of recipe functionality, hooking into the crafting event, and even duplicating the event carving tool, then damaging it, before reinserting it into the player's inventory. This is fully functioning. My subscriber looks like this: @SubscribeEvent public void itemCrafted(ItemCraftedEvent event) { Player player = event.getEntity(); if (!player.level().isClientSide()) { if (new ItemStack(event.getCrafting().getItem(), 1).is(ModTags.Items.CARVED_ITEM)) { ItemStack carvingTool = new ItemStack(Blocks.AIR, 1); int itemIndex = 0; for (int i = 0; i < event.getInventory().getContainerSize(); i++) { ItemStack thisItem = event.getInventory().getItem(i); if (thisItem.is(ModTags.Items.CAN_CARVE)) { carvingTool = thisItem; itemIndex = i; break; } } ItemStack newTool = new ItemStack(carvingTool.getItem(), 1); // make copy of tool, ... newTool.hurtAndBreak(carvingTool.getDamageValue() + 1, player, entity -> entity.broadcastBreakEvent(EquipmentSlot.MAINHAND)); // ... then damage it, and ... player.getInventory().setItem(1, newTool); // reinsert it into the player's inventory (this presently overwrites whatever is in the slot, as this is not the final intended implementation) if (player.containerMenu.getClass() == CraftingMenu.class) { // using crafting table: // TODO } else if (player.containerMenu.getClass() == InventoryMenu.class) { // using inventory crafting // TODO } } } } I have only been developing mods for minecraft for a (relatively) short period (a couple months), and so it is quite possible I have made a 'high level' error i.e., one alternative implementation I have considered is overriding the onCraftedBy() method in a custom item class. I am unsure if this is the most appropriate place in the eventbus to perform this method. In the code I have provided, you can see the lines where I currently generate the carvingTool, damage it, and then re-insert it into the player's inventory. Under this, I have created a if/else-if block for the two crafting interfaces, as I imagine some nuances exist in the implementation difference. But in essence, I am trying to map the stored itemIndex to the crafting grid, and to insert the newTool instance into the grid at this position. I have tried a variety of commands commands to attempt this, in no particular order: // (containerMenu|inventoryMenu) denotes one or the other // I assume one of these can be used to perform the insertion, but none appear to work: player.(containerMenu|inventoryMenu).setItem(1, player.inventoryMenu.getStateId(), newTool); player.(containerMenu|inventoryMenu).getSlot(1).set(newTool); player.(containerMenu|inventoryMenu).getItems().set(1, newTool); // I assume a command may be needed to reload the crafting grid contents for the player, but none appear to work: player.inventoryMenu.getCraftSlots().setItem(0, newTool); player.(containerMenu|inventoryMenu).broadcastChanges(); player.(containerMenu|inventoryMenu).broadcastFullState(); player.(containerMenu|inventoryMenu).getSlot(1).setChanged(); Hoping to receive guidance on how to achieve this result. Thanks
  4. As an update on this - I was able to use reconstructed classes to add ores in, fully functioning. I did need to reconstruct the RegistrySetBuilder, RegistryPatchGenerator, and DatapackBuiltinEntriesProvider though. Good luck!
  5. It appears this was in-error, you can find the file has been deleted in a commit. It is planned to be re-added soon: https://github.com/MinecraftForge/MinecraftForge/pull/9848 https://github.com/MinecraftForge/MinecraftForge/pull/9848/files/13785854f678a08c7c43c6953bddc3d619013d11 In the meantime, you can reconstruct the class contents: https://github.com/MinecraftForge/MinecraftForge/pull/9848/files/13785854f678a08c7c43c6953bddc3d619013d11#diff-54d34c579bf88853bc427e7c0137d9dad58856f4ce9372a7cf342f3c898e387f
×
×
  • Create New...

Important Information

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