V0idWa1k3r

What is you problem exactly? Just store the delay value somewhere, decrement it each tick/time period and as it reaches 0 set the mob as not sheared(presumably by calling setSheared(false)). You don't even need a DataManager for that as the client does not need to know about the delay(unless you want it to for some rendering or something, then you need another DataParameter). Kinda how sheep does it at EntitySheep::eatGrassBonus.

Please elaborate on what you are trying to achieve.

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 made a similar system at some point. While I was not using capabilities the logic should still be the same. Basically every time I need to check the rot I would check if the "birth time" is at 0, and if it is - set it to the current time and wait for the next check. It is farely unlikely that the player would obtain a food item with a birth tme of 0, but you could use -1 as a default value and then you can be sure that the item was spawned in rather than obtained in some other way. If your idea is that the capability can be attached to any item, not just some specific ones you could perform a player inventory iteration once in a while to check for this exact case. If you do it infrequently it will pretty much not matter performance-wise.

if (!player.getHeldItemMainhand().isEmpty() && player.getHeldItemMainhand().getItem() == Items.FLINT_AND_STEEL) Something like that.

Could you please show your code? Drawing anything after the buttons are drawn should draw that "anything" above the buttons as their z level is at 0 by default. Most likely you are doing something incorrectly as drawing something after the buttons are drawn works fine for me. As a workaround you should be able to draw that "rectangle overlay" with a higher Z value. If you are using BufferBuilder directly you specify z yourself in pos element. If you are letting the Gui class draw stuff for you there is a zLevel field that controls it. Or you canjust use GlStateManager::translate too. Just don't forget to reset the z level back after you are done drawing your overlay.

Do not use numeric IDs. They can and will change. Items class exists for a reason. Comparason by reference like this will always fail since fs is a newly created object. You need to compare the content. Use ItemStack::getItem to compare Items and ItemStack::getMetadata to compare metadata.

Remove the !world.isRemote check.

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

Item::getItemFromBlock as the name implies gets you an Item from a Block. Unless ModItems.JadeDragonScales is a Block(and if it is why is it located in the ModItems class?) you are not doing things correctly. Just pass your ModItems.JadeDragonScales to the ItemStack constructor directly, it will figure everything out for you.

Please show your updated code(the part where you initialize your blocks, the part where you initialize your items and the part where you call both initializers). Additionally show your new log, just in case.

Do you need a custom class here or not is a question only you can answer. These changes do not have anything to do with your class. Do you need it for any custom behaviour or will ItemSeeds suffice is up to you.

Just initialize your blocks before your items. You know how to move a line or two of code higher, right? Ideally you would switch to forge's registry events.

And this happens because your items are created before your blocks. Thus the dpetal item recieves null as it's soil block because at the time of it's initialization the ModBlocks.darklilac is null.

While I do not see what is null there your registerBlock method is not doing what it is supposed to do. Currently it registeres all your blocks and an ItemBlock for the block you've passed. As you are calling it 4 times all your blocks get registered 4 times which is not what you want at all. As for the null itself I would guess that you are calling the register method before the init method/not calling init method at all/calling registerBlock from one of the constructors of your blocks which causes the issue due to your method not doing what it is supposed to.

Your new error actually has nothing to do with the item, look at the stacktrace: at init.ModBlocks.registerBlock(ModBlocks.java:49) at init.ModBlocks.register(ModBlocks.java:37) Something you are registering in your ModBlocks class is null. We can't tell what since you've never posted your ModBlocks class.

Looks correct to me unless I am missing something. Please show your updated code and the error log. If you want the dpetal item to be an instance of ItemSeeds why have you created a ItemDpetal class in the first place?

What do you want the dpetal item to be? If it is supposed to be a ItemDpetal then you would set the value of dpetal to an instance of ItemDpetal. If it is supposed to be ItemSeeds you would need to set it's registry name explicidly with Item::setRegistryName

dpetal = new ItemSeeds(ModBlocks.darklilac, Blocks.FARMLAND); You never set the registry name for the dpetal(at least not in the code you've posted), and the ItemSeeds class does not do that for you. Your ItemDpeal class does but you do not use it. Side note: do not use ItemModelMesher, it is outdated and buggy. Use ModelLoader.

You do not need to write the itemstack into NBT. You need to write TE's data into NBT and set that NBT to itemstack's tag with a BlockEntityTag key. Currently you are creating a new NBT, writing the ItemStack in there, writing your TE data in there and discarding the NBT. The ItemStack has no NBT associated with it as a result. Use ItemStack::setTagInfo to write an NBT into your ItemStack's compound.

You are referencing a client-only class in your common code, hence the crash. The previous solution works because you are using a proxy.

1180 != 1178. That's one of the reasons to use descriptive class names.

You are still using DrawBlockHighlightEvent. You need a different event.