Cratthorax

Yes, I do that(see my general register file): What I ment to say, I am using the database(or datapack...how is it named? sorry), via .json, to create said files. You'd do that in the register, or main file in the past.

Thank you sirs.

@Luis_ST Yeah, basically what you just said, I've had to learn this week. It's not all outdated though. But using datapacks is quite a hassle, since in the past you could simply copypasta the register code. Creating a new .json for any of my dozens of blocks and items will prolly take 2-3 weeks. There is no more need to use the PlayerEvent.HarvestCheck, since I've reached my goal. But I'll certainly return to this thread, once the need is uprising again. But for now I'm ok with how it's working.

You mean in general? Porting my very ancient mod to 1.16.4 and future MC versions...;)

Hello, in order to create blocks/items etc., the todays standard seems to be the usage of database, with .json files. Is there a way to still register all blocks/items in only one .json, or is there no way around on making a single .json for any of my blocks/items? If not, would you recommend of moving away from using database, and instead using the "old way"?

Sorry. I was busy this week. I watched a different tutorial, and found this hack quite convenient: { "type":"crafting_shapeless", "ingredients": [{ "item": "minecraft:air" }], "result": { "item": "minecraft:barrier" } } I had to change the achievement database accordingly for issues regarding barrier icon issues, in the crafting menu. But to adress your proposal. The correct way to remove vanilla recipes is by adding a simple "false type" condition check?

Well, that's what I said. I would take what you've granted, if I had the time and skills to do so. So it's entirely my fault...but being back in for 7-10 days, insight is slowly returning. The very reason why I would still ask for the reflection method, is simply because I knew what I was doing with it in the past. I had to relearn a whole lot of stuff the couple of last days. I won't use it anymore, I'll promise...;) The way I check for valid tools now looks like this for onBlockBreak, breakSpeed, and playerBlockPunch events: @SubscribeEvent public static void onBlockBreak(BlockEvent.BreakEvent event) { PlayerEntity playerRef = event.getPlayer(); ServerPlayerEntity playerMain = (ServerPlayerEntity) playerRef; GameType gameType = playerMain.interactionManager.getGameType(); ItemStack heldItems = playerRef.getHeldItemMainhand(); Item itemRef = heldItems.getItem(); Material matRef = event.getState().getMaterial(); BlockPos blockPos = event.getPos(); Block blockRef = event.getWorld().getBlockState(blockPos).getBlock(); //BlockState blockState = blockRef.getDefaultState(); System.out.println(blockRef); if(!gameType.isCreative()) { if (itemRef == Items.AIR) { if (matRef == Material.WOOD || matRef == Material.ANVIL || matRef == Material.ROCK || matRef == Material.IRON) { event.setCanceled(true); } } //System.out.println(itemRef.getHarvestLevel(heldItems, ToolType.AXE, playerRef, blockState)); if (matRef == Material.WOOD || matRef == Material.BAMBOO || matRef == Material.NETHER_WOOD) { if (!(itemRef instanceof AxeItem)) { //if (itemRef.getHarvestLevel(heldItems, ToolType.AXE, playerRef, blockState) < 0) { event.setCanceled(true); //} } } if (matRef == Material.EARTH || matRef == Material.SAND || matRef == Material.SNOW || matRef == Material.CLAY || blockRef == Blocks.GRASS_BLOCK) { if (!(itemRef instanceof ShovelItem)) { event.setCanceled(true); } } } } But I do have to admit. I still didn't grew profound with the HarvestCheck. Primarily because there no longer is reason for it? Edit: it actually were the blockState that gave me all sorts of issues when trying to utilize harvestCheck.

Instead of saying "it doesn't work", I say how it is. I fail at doing it. That's what I'm having: { "type": "minecraft:crafting_shaped", "pattern": [ " XX", " #X", " # " ], "key": { "#": { "tag": "forge:rods/wooden" }, "X": { "tag": "minecraft:planks" } }, "result": { "item": "minecraft:wooden_axe" } } It sits inside the data.minecraft.recipes folder. My goal is to entirely remove, or hide the vanilla recipe, so that it does not show up in Survival/Hardcore(Creative is fine). The problem is, trying to remove any of the structure expected by the engine will result in a "Couldn't parse data file minecraft:wooden_axe from minecraft:recipes/wooden_axe.json" error. This technically does what I want, hiding/removing the recipe. But certainly I do not want to do this while at the same time creating an error. In any of those threads users are talking about doing it, but actually never show "how" to do it. I've yet to figure if I can actually achieve it with Datapacks, or have to use the "normal" coding way due to the involvement of Forge, and how it overrides the vanilla datapack with its own. Edit: So in this video the user is actually using what I would call a "hack", by replacing the result with item minecraft:barrier. But I don't want to create a barrier, or Air, or whatever. I want to remove the recipe or hide it. Unless creating a replacer item is the only way to do it?

I prolly don't do that to annoy you. It's more likely I don't do that because I'm not as skilled as you, my time is very limited, I do mods primarily for personal reasons, and have a beast computer that can deal with any quality of code. But yeah, it's primarily because I'm a layman, and Mod games for free. So I'm not at all as sophisticted in Java as you. And I'm returning from a 6 year hiatus to a codebase that has been entirely changed. I mean, it isn't easy for us "hackers" as well. You could just link to Github source, or post the code right away since you know how to do it. Instead you force any noob to spend(waste) hour after hour to figure(google) out how things are working on a codebase, that changes with any new update, and how things were done before. You know how the info/tutorials/etc. on Google is rendered useless for any new update? I don't blame anyone though. Minecraft devs do it as well. I know it doesn't help anyone to pick a fight with a Forge Veteran. But it certainly doesn't help acting from a high horse as well.

I think I've got it. Or at least a base to start working from. if (toolRef.getHarvestLevel(heldItems, ToolType.AXE, playerRef, blockState) <= 0) { event.setCanceled(true); } I've implemented it into my existing onBlockBreak event, because I was having issues to get it working for the HarvestCheck event. For a weird reason it wouldn't accept the BlockState reference inside the getHarvestLevel() method, when I was using it on HarvestCheck event. I'd still prefer any kind of reflection method though. Was way less complicated.

It's not only the tools. Let me explain. I remove some of the vanilla tools, primarily those made of wood, and then only need to check for tools in general. Ontop of that I've build some custom tools, which allows me to define what exactly they are allowed to harvest, and what not, in the specific custom tool class. Then I check against AIR(for having no item in my hands at all), entirely disallowing to harvest anything but for example, DIRT, CROPS, and stuff you'd need no tools to harvest in reality. Which leaves harvest with blocks in my hand open to be addressed. In the past I was just using the "setRequiresTool" reflection method, so I couldn't bypass my prohibition of harvesting anything with only AIR, or random blocks in my hand.

Yeah, I get what you're saying. I do check against AIR already with onBlockBreak, like this: @SubscribeEvent public static void onBlockBreak(BlockEvent.BreakEvent event) { PlayerEntity playerRef = event.getPlayer(); ServerPlayerEntity playerMain = (ServerPlayerEntity) playerRef; GameType gameType = playerMain.interactionManager.getGameType(); ItemStack heldItems = playerRef.getHeldItemMainhand(); Item toolRef = heldItems.getItem(); Material matRef = event.getState().getMaterial(); if(!gameType.isCreative()) { System.out.println(heldItems.getToolTypes()); if (matRef == Material.WOOD || matRef == Material.ANVIL || matRef == Material.ROCK || matRef == Material.IRON) { if (toolRef == Items.AIR) { event.setCanceled(true); } } } } But I'm trying to prevent to check any of the tools, against any of the blocks. That would be a lot of if and ||'s. The problem here is, even if I'd check against AIR, if I hold a, let's say, DIRT block in my hand, it would still allow to harvest the tree. I want to prevent that.

Because I was adding the "requires tool" check to all blocks that didn't had them, and then individually addressed specific tools to allow or disallow to harvest said blocks. If I do what you propose, I'd still need to check any relevant block against any possible tool. That's not what I want. Isn't there something like a "you try to harvest with anything but a tool, so you'll fail"-kind of thing?

Good morning, according to the title. Already figured that ReflectionHelper has been replaced by ObfuscationReflectionHelper, and the findMethod logic has changed to (Class<>, String, Class<>). It also hands out an error upon running, where both, the literal, and the SGM variant of method "setRequiresTool" isn't recognized by the engine. Browsing through the relevant classes I'll have to admit, I did not find anything to solve my issue. It's there, I know, but obviously I'm incapable of finding it. That's the original block of code: //ProperToolUsageCode Method m = ReflectionHelper.findMethod(Material.class, Material.wood, new String[] {"func_76221_f", "setRequiresTool"}); try { m.invoke(Material.wood); } catch (Throwable t) { t.printStackTrace(); } That's the adapted one so far: private void setup(final FMLCommonSetupEvent event) { // some preinit code Method m = ObfuscationReflectionHelper.findMethod(Material.class, Material.WOOD, new String[] {"func_76221_f", "setRequiresTool"}); try { m.invoke(Material.WOOD); } catch (Throwable t) { t.printStackTrace(); } } Further adaption handing out the compilation error: private void setup(final FMLCommonSetupEvent event) { // some preinit code Method m = ObfuscationReflectionHelper.findMethod(Material.class, "setRequiresTool", Material.class); try { m.invoke(Material.WOOD); } catch (Throwable t) { t.printStackTrace(); } } Error report:

Better? @SubscribeEvent public static void onBlockBreak(BlockEvent.BreakEvent event) { PlayerEntity playerRef = event.getPlayer(); ServerPlayerEntity playerMain = (ServerPlayerEntity) playerRef; GameType gameMode = playerMain.interactionManager.getGameType(); //@SuppressWarnings("resource") //GameType gameType = Minecraft.getInstance().playerController.getCurrentGameType(); ItemStack heldItems = event.getPlayer().getHeldItemMainhand(); Item toolRef = heldItems.getItem(); if(!gameMode.isCreative()) { } }

Sorry, I'm out of practice. It's hard for me to comprehend what you're saying. With "reaching across logical sides" you mean I'm utilizing server and client in one sentence? Also, why gameMode? What's the difference to gameType? I was actually referring to this thread, were you gave that example... For the main client player: Minecraft#playerController.getCurrentGameType() ...to get the client side gameType. I want the client side.

Hello, coming from 1.7.2, and 1.12.2 I figured the "old" way of getting game type does no longer work. It took a while and a bit of searching to find an old 2019 thread, were @diesieben07 is giving instructions, that did not work out of the box, but finally did with a bit of fiddling. This is the code block in my event handler: