Draco18s

You want continue here. You don't want to abort if one item can't be smelted. How would drops not contain drop? You pulled it out of the array in the first place. ItemStack drop = event.getDrops().get(i); And oh yeah, you can't modify an array while looping over it with a for-loop. The game should crash with a ConcurrentModificationException. Seriously? What the fuck. You already had the item stack version of the block. It's drop. You're not trying to smelt the block that got mined, so stop trying to convert to it: you're trying to smelt the dropped item regardless of what that item is. Imagine an ore block that doesn't drop a blockitem, but which drops a chunk of raw ore. Great, now you fucked up the furnace recipes. And you're fucking with fortune in a place you shouldn't be fucking with fortune (again). Fortune already triggered. You should use the size of the smelt stack times the size of the drop stack and assign it to the cloned stack.

You aren't using the contents of the event's drops, you're constructing a new block item based on what was broken. So telepathy comes along, gobbles up the iron ore first, then autosmelt comes along, doesn't look at the drops list, and constructs a new drop (nukes whatever's still in the list) and adds the iron ingot. If you had one event handler in one location and actually used the drops from the event you could control this. But you're running ramshackle all over standard practice and doing whatever you feel like doing and producing barely functional code and then going "huh, I wonder why these two won't play nice together." They don't play nice together because you shat all over the system that makes them play nice together.

entity instanceof PlayerEntity?

You will have to special-case the player. Players are not entities registered with the entity registry. They're special and so you're going to have to treat them as special.

I made a comment about these lines already. You do not need the loop. You shouldn't need to check that block2 isn't air. You should inverse these checks and instead return, it reduces your indentation and makes your code easier to read.

You remember how diesieben07 said something about calling the right methods in the block class, and how I said you're not calling the Forge events? Yeah, this is why. destroyBlock is essentially the same as setBlockToAir. This bypasses all the standard harvesting logic.

Well, you did half of what I said. You're still only checking if things go into the players inventory once (outside the loop no less) and you aren't removing things from event.drops(). And you still haven't posted the 3x3 enchantment's code. You know, the code causing the problem.

1.14 doesn't really allow for doing things like that. There were a few hacks you could put in 1.12 and have a similar effect, but the hook that allowed for doing that is no longer present in 1.14

"Subscribing to" and "firing" are not the same thing. Post your 3x3 mining enchantment code. While true, I have serious doubts about the code calling the correct methods in the block class, as evidenced by the way he generates drops in the telepathy enchantment. So, one way or another, he's not invoking the HarvestDropsEvent (whether he needs to do so manually depends on other factors; there are legitimate reasons to bypass the Block class code, if admittedly rare). Oh, speaking of: This entire function block is completely and utterly irrelevant. After checking the telepathy level, just loop over the event.drops() array and attempt to add them to the player's inventory. If it can be added to the player's inventory, remove it from the array. There's no need to go through all that bullshit your code does.

The HarvestDropsEvent, for one. If you're breaking blocks and generating loot from them and not firing the HarvestDropsEvent, then your other enchantment which relies on the HarvestDropsEvent to do its thing can't run.

Ok, so, you didn't post the 3x3 code and I suspect it doesn't work because, like an idiot, you didn't fire any of the relevant Forge events when you broke those blocks.

I am not understanding your problem.

You are doing way more things in your HarvestDropsEvent than you should be. Fortune and exp dropping should already have been taken care of before any of your code gets called. if (drop.getItem() instanceof ItemAir) That should never occur. if ((drop != null) && (!(drop.getItem() instanceof ItemAir))) { Drop is already not null or the game crashed (assuming you didn't set it to new ItemStack anyway) and you know the item isn't air because you literally just checked for that. if ((fortuneLevel > 0) && (!(drop.getItem() instanceof ItemBlock))) { nItems = event.getDrops().size() + random.nextInt(fortuneLevel + 1); } else if ((fortuneLevel <= 0) && (!(drop.getItem() instanceof ItemBlock))) { nItems = event.getDrops().size(); } This can be simplified. nItems = event.getDrops().size + (fortuneLevel > 0 ? random.nextInt(fortuneLevel + 1) : 0); Of course, why are you using the number of stacks as your baseline value? That seems odd. Whatever. Anyway. Compatibility. if (event.getAttackingPlayer() instanceof EntityPlayer) { ...This isn't the harvest drops event, so I don't see why you even have a problem...

You have a recipe or other data file (achievement, loot table...) that's failed to load and it prevents all data pack data from loading. Check your logs.

You have to place them in the right place (and with the right file name). And you can replace advancements the same way you replace recipes.

Probably by fixing this.

Either: a) one is client side and one is server side b) two separate, unrelated events (tall grass getting broken fires a harvest drops event). There might be a reason for this line in my code... https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/OreEventHandler.java#L74

I am not sure I understand. You do realize you have to clear the drops from the event and then add the new ones, right? For example: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/OreEventHandler.java#L118-L142

BlockBreak is the wrong event. Use HarvestDropsEvent

These don't match. Look at the documentation again.

SlotItemHandler. You can select a class name and either "search for all references" or "open type hierarchy" to get an idea of what alternatives exist or how something's used. Yes No, TileEntity already implements that.

His code (and coding practice) is such garbage it needs to be taken out back, shot, set on fire, and buried, never to be seen again. As in, almost everything he does is wrong in some way. And sure "it works for him" but everyone who watches his crap shows up here with the same garbage code, we've enshrined several of the problems created by him in the Common Issues thread. Problematic Code #4, #5, #14 Code Style #1, #2, #3, #4

Where is your Register<Block> event?

Camel case. As in a camel has humps. Like ClassNamesWithCapitals. You wrote a function with the name "info." If you put the @Override annotation on it, Eclipse (or IntelliJ) will tell you to remove the annotation because you're not overriding anything. You need to be overriding addInformation. If you go to a blank line and hit ctrl-space and type "addInformation" and hit enter, your IDE will create an overridden function for you.

That is also not how tags are meant to be used. Tags are tags that say something about the object, such as "planks" (oak, birch, pine...) or "rails" (powered, straight, curve...) and so on. For entities its probably for things like spider (spider, cave spider), undead (zombie, skeleton...), etc. Capabilities is what you want.