Leaderboard

I think using @ObjectHolder is the intended way of using registries, and seeing that every test mod using registries uses them @ObjectHolder, it would make sense to use it as well. Also, the docs say this is the recommended way.

Imports can be static. Also, let's not go out of our way to call out this guy on every mistake he makes. Whether he's new to java or not, we should not get abusive.

I assume that you can't use these methods as you do not have the DYE_COLOR data parameter as you manage your sheared items differently and don't exatcly store the wool color anywhere, correct? You do not need these methods then. Simply store your delay and it can be your isSheared indicator aswell - if it is at 0 the mob is not sheared and if it is anything else then the mob was sheared.

When the server-to-client packet is received by the client, you can access the current GUI from the Minecraft#currentScreen field. If it's an instance of your GUI class, you can update it with the data from the packet.

Just send another packet. The return value of IMessageHandler#onMessage is largely useless now that packets are handled on a network thread and all the logic needs to be run on the main thread.

CommandBase already implements ICommand, there's no need to implement on your class. I told you to implement IClientCommand. You need to override CommandBase#getRequiredPermissionLevel to return the permission level required to execute the command. 0 allows anyone to execute it, higher numbers restrict it more.

...override getHarvestLevel?

In your GUI only send the packet with most basic info that allows you to identify what the player is trying to do. On the server get all the values, perform the checks and send the response if needed. The approach is to do all logic on the server and simply notify the client when appropriate.

You need to send a custom packet to the server and let the server do everything you need to. You also should never trust a client in general so most of your checks and actions should be server-side.

I think you ment BlockPos, not BlockState. OP, how do you know that this does not work? Did you place a breakpoint after those 2 if statements and it is not being triggered? Because there are more thing that would stop your structure from spawning later down the line. Those 2 checks apart from creating a new BlockPos object every time(don't do that btw) look fine. As @Choonster said, do not use getBiomeForCoordsBody. Why are you comparing classes here? If your intention is making the structure only spawn in the plains biome you can either use BiomeDictionary or directly compare the biome to Biomes.PLAINS. This will be true if the block above the inital ground height is not air thus forbiding your structure from spawning. Tallgrass, for example... You do not need this. You can return from a loop directly when your air check fails. With your current code you are just wasting time in the loop if the structure won't generate. Never use IDs. They can and will change. Blocks class exists for a reason. getStateFromMeta should not be called. Use BlockStates. A state with meta 0 will most likely be the default state. This way of spawning structures is very confusing and painful to update/fix later. Use templates if they are available in whatever version you are modding for. Do not create a new Random object every time you need to do something. You have an instance of Random passed as an argument. nextInt returns a value from 0 to the number specified excluding this number. nextInt(15) will return a number from a range of [0-14]. => world.getHeight(i, k) random.nextInt(10) == 0 is much more understandable and does pretty much the same.

Look at the constructor of the ItemStack, the names of parameters are pretty descriptive. That 1 in particular is the amount of items in the stack