Draco18s

Rename it to something else, completely unrelated, push that to github, then rename it back and push that. 1) Windows doesn't give a fuck about case, so its lying to you 2) Git does care about case and for some reason it saw the change on only some of the files. Rename, push, rename will fix it

Your lang file is still in an Upper Case folder: https://github.com/aliteraryhigh/FruitBushes/tree/11-04-19/src/main/resources/assets/FruitBushes As are your block models and block textures

Oh sorry, 1.12 You're looking for ItemSeeds

Whoops, it didn't copy correctly. Valid json is valid. Hmm.

You know, there's already a class that seeds use and you don't need to extend it. BlockNamedItem

Any reason you decided not to show your CropCornBottom class?

...or don't even set the field yourself and use object holders

Tool is just another property, add it like you did hardness.

This is not good code, but this isn't the source of your problem. Never covert things to strings in order to compare them, it makes your code incredibly stringly typed and impossible to refactor.

That is not a JSON exposed option. It is a method defined by the IBakedModel interface (note: that is different than IModel). Probably. But can't say, because you haven't really explained what you want to do (so far, this is an XY Problem).

There is no newer function. What you're looking at is Mojang-deprecation, which they aren't using properly, but all they mean for it to mean is "do not call this" (because you should call it on BlockState instead) and you can certainly override it.

Ok, great, but you're not doing it correctly. You aren't performing the increase based on whether or not it was an ore block (of any variety) that was broken. You're doing it all the time as long as there's a smelting result. And you're corrupting the furnace recipes at the same time. Try mining regular stone, see what happens.

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...