Draco18s

Yes. I love working within the Forge framework and have adopted several of its patterns in my own projects (eg. event systems and registry objects, though my registry system is often little more than a dictionary<string,SomeType> that doesn't deal with a lot of the validation Forge does, but I'm also not an idiot trying to register things at the wrong time, or with duplicate names).

And not all things that plant crops are items that are BlockItems.

You do know that this is client-side-only right? https://github.com/kregerl/Potion-Cakes/blob/1.15.2/src/main/java/com/loucaskreger/potioncakes/EventSubscriber.java#L10

I don't know where you heard this, but it is objectively wrong.

1.7 isn't supported any more, thus against forum policy. Those threads are locked in order to prevent people from helping give support to an unsupported version. There's a green banner at the top of every page about it.

This is a forum, not Stack Overflow. There's no need to lock threads unless they violate actual rules.

Do people not know how to use search? https://forums.minecraftforge.net/search/?q=x-ray block&type=forums_topic&updated_after=any&sortby=relevancy&search_and_or=and 2nd, 5th, 6th, 10th, 11th, 12th, 13th, 14th, 16th, and 18th results are all this problem.

private void Hat() { //what does it do? } glad to help

Cool. What's the plugin do? This is the Forge forums, most of us (probably all of us) have never used Bukkit.

You're overriding Block#hasTileEntity not IForgeBlock#hasTileEntity public boolean hasTileEntity(BlockState state)

You write a method (eg. a lambda) that satisfies the constraints of Supplier<T>. That is, it is a zero parameter function that returns an instance of <T> You already know what the <T> is, too, its right there:

In other words: Right-click -> Open Type Hierarchy

A "supplier" is just a function (such as a lambda) that takes no parameters and returns a value of a specified Type; it supplies a thing. A consumer is the opposite: it consumes a given Type as its only parameter and returns nothing.

When I say the same way I mean literally the same way you would a block or an item, just not a block, but a recipe serializer. YOU don't, that's what @ObjectHolder is for (not that you actually need a field for it anyway). That's for ITEMS, you want RECIPIE_SERIALIZERS.

The same way you register other IForgeRegistryEntry objects.

Post your code.

This is what tags are for. Mods that make tags visible have the onus on them to not make it overwhelming.

Modifying loot tables directly is not inter-mod compatible.

Using the available hooks Forge already provides. Namely events and registry substitutions, but also tags, and json data files (and their extensions).

TLDR Forge blockstates were removed because vanilla states are smarter now.

You have an inner class with the same name as the outer class.

1) ItemStacks are never null 2) This method is only ever called on a book that has been written to, which implies that it has NBT data already

Generally that's the correct way yes. Of course, you haven't shown your code.

This is just some random ItemStack you created that contains nothing (I am not even sure that's a valid constructor...) You need to actually get the itemstack in the player's hand, which you would have to do when you create your thrown entity (and appears you are already doing): He's not creating item entities, he's creating snowball like thrown entities.