Draco18s

I wonder if vanilla has any food items and whether or not that code might be a valuable asset to study.

https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/ores/entities/TileEntitySifter.java#L177-L199

https://mcforge.readthedocs.io/en/1.13.x/networking/simpleimpl/#getting-started

I already answered that: This is specific to contributing to Forge not making mods. And if you want to make a mod for yourself without using Forge, then you can get help elsewhere. We only help people who use Forge and you are not using Forge (instead you are explicitly going around Forge). Therefore I don't particularly care if I am rude (see my signature). All of that would be covered by entity tasks.

So you check to see if event.getEntity() is an instance of ServerPlayerEntity, but them fuck off with it and send a message to whatever PacketDistributor.PLAYER.with() returns. Why?

Pick a player object (an instance of ServerPlayerEntity). Send a message to that player. The networking is done for you. That's what the packet handler is for.

And you did everything wrong. Congradulations. The whole point of the "clean" project is that it's fucking clean. Exactly what vanilla shipped so that patch files can be generated correctly. You are not meant to touch the clean project in any way and Forge does not support or condone building it.

You'd be right. https://mcforge.readthedocs.io/en/1.13.x/networking/

Go look at the vanilla transparent blocks.

It means the method signature doesn't match any methods from the superclass. Or as I said earlier:

Use @Override Because you need this method, not the one you have (because it doesn't exist any more). https://github.com/Draco18s/ReasonableRealism/blob/1.14.4/src/main/java/com/draco18s/harderfarming/block/TannerBlock.java#L64-L67

Because we can't run it. If we can't run it we can't use a debugger. If we can't use a debugger all we can do is guess.

There's no reason to create a glass stack if you're just going to call getItem() on it. entity.getItem().getItem() == Items.GLASS

Which block? What command? Do you know how to write Java?

A-Za-z -> A-z Also, don't post pictures of code. Also, show examples of text that needs to be matched (both positives, false positives, and false negatives).

Rather than getting items from a tag, query if a given item has a given tag.

This AABB only contains the full 1x1x1 volume that your block occupies. If you want the space above it you need to offset the Y by more than 1 unit (and you can offset the bottom by +1 to avoid needlessly checking the volume your block fills).

Very much true. I have first hand experience on just how costly a try-catch block is. I had code at one point that had the possibility of generating an error (a Vexing type) and wrapped it in a try-catch--because that was the right things to do. And the code was called so often that it ground Minecraft to a halt. We're talking two minutes per tick levels of slow for what was a few tens of thousands of calls. Performing bounds-checks and null-checks on the other hand takes nano seconds, virtually zero time. I ended up just letting the exception be thrown and bypassing the compiler's check for exception handling, as it was an exception that could never occur unless something went very wrong indeed (better to let the game crash than catch the exception). Code correctly and don't catch boneheaded exceptions. Boneheaded exceptions are the result of bugs. Don't intentionally hide bugs in your code.

Show your code.

Oh? Huh, thought I'd saw that it changed. *shrug*

--ignore this--

For reference, that list came from here: https://blogs.msdn.microsoft.com/ericlippert/2008/09/10/vexing-exceptions/ Note that Vexing is for things like int.Parse(str) that throws an exception when str isn't a valid integer (so use int.TryToParse(str) instead), but Java doesn't have a non-exception throwing version, hence, vexing. Someone, somewhere, made a design decision to throw an exception and now you have to deal with it. Null check first, you bonehead. Check your types first, you bonehead. Check your bounds first, you bonehead.

There are four kinds of exceptions: Fatal. They aren't your fault and there's nothing you can do about it. Let the program crash. Vexing. They are the result of unfortunate design decisions. Avoid them if you can. If you can't, catch is vexing exceptions. Exogenous. They are the result of untidy external realities impinging upon your beautiful, crisp program logic. Try it and be prepared to handle the unfortunate realities. Boneheaded. These are your own damn fault. These are bugs. Never catch these. Fix your code so that it never triggers a boneheaded exception. A ClassCastException is #4

This is why it has been renamed to isClient in 1.13+.

I think your problem is that you've made the crop grow on the client side (and only the client side) while on the sever side of things, nothing's changed. Show your code.