Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

urbanxx001

Members
  • Posts

    181
  • Joined

  • Last visited

Everything posted by urbanxx001

  1. I know enough about Java to code the method above, which would work if it was in the source code. Not knowing one thing (or a few things counting other posts) doesn't invalidate my understanding of everything else about Java.
  2. It's an insult when you're able to explain what the issue is but instead say to look elsewhere for help. This says you don't want to take the time to explain it when it could just take a few sentences to do so. Please don't further this, I don't want it to derail into something bad.
  3. You could have described why it didn't work instead of an insult. I'll look into LivingEntityUseItemEvent though, thanks. I appreciate the help that regular users like you and Draco give in the forum, your names appear a lot when researching old posts.
  4. Yes, it's supposed to check for that...
  5. ? It applies the drinking animation to soup items (those items that have a container with a bowl), since in the base game consuming soup uses the eating animation for whatever reason. So the code is just overriding getUseAction which is built-in the source code.
  6. Yea it should apply to all food items, including vanilla, since the class extends to the Item class. Is the problem that I need to pass something into ItemStack in the ModItems class, or does it already know what to pass based on the Item class?
  7. Title says it all. In my ModItems class, I added the following override (which should be default game behavior tbh): @Override public UseAction getUseAction(ItemStack stack) { UseAction ReturnUseAction; if (stack.getItem().isFood()) { if (stack.hasContainerItem()) { Item stack_container = stack.getContainerItem().getItem(); if (stack_container == Items.BOWL) { ReturnUseAction = UseAction.DRINK;} else { ReturnUseAction = UseAction.EAT;} } else { ReturnUseAction = UseAction.EAT;} } else { ReturnUseAction = UseAction.NONE;} return ReturnUseAction; } For reference, the original is: public UseAction getUseAction(ItemStack stack) { return stack.getItem().isFood() ? UseAction.EAT : UseAction.NONE; } But all foods still return the eating action in-game.
  8. Choonster thank you! That's so much simpler, I had no idea about helper functions. Draco thank you as well, I didn't realize the events were clashing like that. I'll credit you all in the toml file.
  9. Well it's almost done. Even though the code window doesn't throw any errors, the block items don't register in-game. I'll leave it here in case any future modders can resolve it.
  10. Understood. I'll create another array that stores the actual ItemGroups. Think I got this now. Thanks for you and Dracos advice.
  11. Yeah. This would work: public static class RegistryArray { public static void main(DeferredRegister args) { ArrayList<DeferredRegister> block_registries = new ArrayList<DeferredRegister>(); block_registries.add(DECORATIONS); block_registries.add(BUILDING_BLOCKS); } } That's resolved, just need to convert the ith entry: ModBlocks.RegistryArray.get(i) to an ItemGroup name
  12. Sorry I'm using Matlab notation. I just mean some way in Java to get the ith registry from the list of all block registries.The registries in class ModBlocks are: public static final DeferredRegister<Block> DECORATIONS = DeferredRegister.create(ForgeRegistries.BLOCKS, Reference.MOD_ID); public static final RegistryObject<Block> BLOCK_A = DECORATIONS.register("block_a", () -> new Block(Block.Properties.create(WOOD))); public static final DeferredRegister<Block> BUILDING_BLOCKS = DeferredRegister.create(ForgeRegistries.BLOCKS, Reference.MOD_ID); public static final RegistryObject<Block> BLOCK_B = BUILDING_BLOCKS.register("block_b", () -> new Block(Block.Properties.create(WOOD)));
  13. What I'm referring to is passing the block registry into the ModBlocks line (Where the registries are already defined in that class), which will be converted to an item_group name. The item registry ITEMS is already defined in ModItems, i.e.: @SubscribeEvent public static void createBlockItems(final RegistryEvent.Register<Item> event) { final IForgeRegistry<Item> registry = event.getRegistry(); registry_size = size of Block registries for i = 1 : registry_size BLOCK_REGISTRY_I = Registry(i) (where registry name is Building Blocks, Decorations, etc); ModBlocks.BLOCK_REGISTRY_I.getEntries().stream().map(RegistryObject::get).forEach(block -> { GROUP = (convert Block Regsitry to ItemGroup name) BLOCK_NAME = (convert block to BLOCK_NAME) final RegistryObject<Item> BLOCK_NAME = ModItems.ITEMS.register(block, () -> new BlockItem(block, new Item.Properties().group(ItemGroup.GROUP))); }); } Sorry I'm using Matlab notation for some of this
  14. I'm aware it doesn't allow blocks in different tabs still, it requires to: Call the names of registries to pass into it (why I was playing with .findRegistry()) Convert that name to an ItemGroup name Convert block to Block_Name Block_Name is a variable now since it's not the actual name of a block (Instead it would be Block_A, Block_B, etc.). Unless there's a simpler way.
  15. Oops yeah line 8 was from me toying to see how .findRegistry works. Wouldn't any enumeration method create a long list though? Is it a performance issue? I suppose it could be simplified to: @SubscribeEvent public static void createBlockItems(final RegistryEvent.Register<Item> event) { final IForgeRegistry<Item> registry = event.getRegistry(); ModBlocks.BLOCK_REGISTRY.getEntries().stream().map(RegistryObject::get).forEach(block -> { final RegistryObject<Item> BLOCK_NAME = ModItems.ITEMS.register(block, () -> new BlockItem(block, new Item.Properties().group(ItemGroup.GROUP))); }); } Where the Item Register is already defined in ModItems. But there would need to be some way to make BLOCK_NAME a dynamic variable, which I don't see happening (or maybe with a hashmap?)
  16. You mean just settle for one tab? (I know one could duplicate the code and manually change the fields that way, but a dynamic solution seems better)
  17. Many tutorials use this nifty event to create block items for a given Deferred Registry: 1 @SubscribeEvent 2 public static void createBlockItems(final RegistryEvent.Register<Item> event) { 3 4 final IForgeRegistry<Item> registry = event.getRegistry(); 5 6 ModBlocks.BLOCK_REGISTRY.getEntries().stream().map(RegistryObject::get).forEach(block -> { 7 8 IForgeRegistry blockRegistry = GameRegistry.findRegistry(Block.class).getRegistrySuperType(); 9 10 final Item.Properties properties = new Item.Properties().group(ItemGroup.GROUP); 11 final BlockItem blockItem = new BlockItem(block, properties); 12 blockItem.setRegistryName(Objects.requireNonNull(block.getRegistryName())); 13 registry.register(blockItem); 14 }); 15 } However this only works when registering all the blocks to a single creative tab. I have an idea for multiple tabs. Naming the registries in class ModBlocks after ItemGroups, surround the inside code in a for-loop to enumerate over them in line 6 (for instance, ModBlocks.DECORATIONS, ModBlocks.BUILDING_BLOCKS, etc.). Then convert the name of each registry into an actual ItemGroup to be passed in line 10. I read that GameRegistry.findRegistry(Block.class) may work for getting a registry name from a global registry, but I'm not sure. Is this idea feasible?
  18. Thank you very much! I realized I also had to delete "new" in front of TileEntityType
  19. Trying to create a tile entity in 1.16 with deferred registry is giving errors. I tried the following: public static final DeferredRegister<TileEntityType<?>> TILE_ENTITY_TYPES = DeferredRegister.create(ForgeRegistries.TILE_ENTITIES, Main.MOD_ID); public static final RegistryObject<TileEntityType<ModChestTileEntity>> MOD_CHEST_TE = TILE_ENTITY_TYPES.register("mod_chest", () -> new TileEntityType.Builder.create(ModChestTileEntity::new, ModBlocks.MOD_CHEST))); Which is recommended by 1.15 tutorials, and is even written as such in the 1.16 source code with builder.create. The top line is fine but the second isn't. The .create isn't recognized, and neither is the ModChestTileEntity::new constructor, even though the class exists. I know that: @ObjectHolder("modname:mod_chest") public static final TileEntityType<ModChestTileEntity> MOD_CHEST_TE; static { MOD_CHEST_TE = null; } Still works, but I'd like to avoid it if possible. Thank you in advance.
  20. Ah ok. Thank you you for your advice, I’ll try starting a new project
  21. Of course BlockList FluidList FoodList ItemList PotionList Actually something to mention is that using @Mod.EventBusSubscriber(modid = Main.MOD_ID) in the main class works, even though I'm not 100%. All the tutorials I've seen use: @Mod.EventBusSubscriber(modid = Main.MOD_ID, bus = Bus.MOD) Which doesn't work in 1.16.
  22. Yes, the files exist in Gradle: net.minecraft:client:extra:1.16.1. I wonder if my main class registry is somehow affecting it: Main Class
  23. Ah no luck, still receive the same errors. Thank you anyway though.
  24. I haven’t tried that method yet, will do it later tonight. Thanks!
  25. I'm modding for version 1.16.1-32.0.75 in Intellij. When creating a world, I receive the error that currently selected datapacks prevented the world from loading. I checked the client run window and found many errors that have vanilla minecraft paths, and none are blocks associated with my mod. Some of these are: java.io.FileNotFoundException: minecraft:advancements/recipes/decorations/orange_stained_glass_pane_from_glass_pane.json java.io.FileNotFoundException: minecraft:loot_tables/blocks/stone_pressure_plate.json java.io.FileNotFoundException: minecraft:recipes/purpur_pillar.json java.io.FileNotFoundException: minecraft:advancements/recipes/decorations/painting.json The actual window is shown in this pastebin. This is only a snippet though, as the amount of errors are too large to paste. I had the errors in an older 1.16 version and figured updating the dependencies would help, but did not. Is this an issue with 1.16 being buggy or my mod? Is there a generally accepted stable version? Thanks for any advice.
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.