Draco18s

Read the deprecation message.

That depends on the hardware its running on.

To explain, we can't support old versions forever as doing so requires people who know the version and as new versions come out, people not using the old version forget how to work with it.

You can see how I handled it in 1.14: https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/hardlib/api/internal/ModItemGroup.java https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/industry/ExpandedIndustry.java#L59 (IItemProvider is approximately equal to a Supplier<ItemStack>, pretty sure the latter replaced the former, but the end result is pretty much the same)

You're seriously asking if using it is going to break something. No. That's why that method is there.

So then it isn't from the player is it? So why would you tell the code that it was?

I wonder if there might be a method in the CropsBlock definition that might help with this...

Is the message coming from the player? Or is it to the player? If you really can't figure it out:

You mean a red underline? Yes, it would, but just because it turns red doesn't tell us what your IDE is saying is wrong. All that is is "there is an error here." What error?

Sorry it wasn't diesieben07, it was ChampionAsh5357. This, you do this:

Your message is coming from your mod, from no where, you don't need a website to find a player's UUID, you either get the UUID from an entity itself or don't need a real UUID at all, in which case you need a dummy UUID, which diesieben07 already told you how to get.

Yes, method signatures have changed. Because Mojang changed them. Or they got a new MCP name because the old one was inaccurate or didn't meet naming practices. UUID, a universally unique identifier. Every player (every entity) has one. Chat messages typically originate from somewhere and that's what the UUID is for: to tell the client who sent the message. If you don't have a sender (hint, you--the developer--don't) then you need to use a dummy ID.

Entities are registered by registry name, so you can use that name to get the EntityType from the registries, and use that to create a new entity.

Its not.

Congrats! You know what function is the problem. Now debug that function.

Or use .shrink(1), if the stack can be stacked, or .tryToDamage(1,player) if it has durability. Depending on use-case.

Chat supports hyperlinks, so they've probably hooked into that.

This is not possible.

Increases the amount of hunger restored of what item?

This sure sounds like a good place to start debugging.

You can't, vanilla cauldrons only know about water.

Gosh, if only Vanilla had some differentiation in how much hunger vanilla food restored you could go look at those food stats...

Uh, Item#onItemUseFinish? The Food property is part of the Item class, all Item class methods accept an ItemStack parameter, and a LivingEntity paramter.

I'm not sure either, use the debugger. Here's a hint: you need to do one thing at a time and wait for the entity to complete that thing before you have it do something else.

Yes.