V0idWa1k3r

No, you set it as %modid%:%path%. In your case it would be camfm:blocks/%name%. Also, if this is your folder structure then it is incorrect. The folder structure for resources is assets/modid/. Any other folders(including the textures one) must be located in a folder with a name of your modid. From there you can structure it as you want.

"0": "blocks/gunhilt", "1": "blocks/gunbarrel", "2": "blocks/merp", "3": "blocks/revolver" No they are not. You need to have a modid as a domain for your textures locations otherwise the game is going to look for them at assets/minecraft/textures/

BlockRedstoneDiode::calculateInputStrength is the method you are looking for, not it's update tick. You can adapt the code from that method to check all faces instead of just the input one.

Check how vanilla does it at BlockRedstoneDiode. I believe it has something to do with the fact that Block::canConnectRedstone is actually irrelevant when it comes to recieving weak power and is relevant when it comes to sending it.

Look at the methods in the class you are extending - Gui. The image dimenions are irrelevant as you specify everything yourself.

wr.pos(0, 0, 0).tex(90, 90).endVertex(); wr.pos(0, 256, 0).tex(90, 90).endVertex(); wr.pos(256, 0, 0).tex(90, 90).endVertex(); wr.pos(256, 256, 0).tex(90, 90).endVertex(); Vertices must be specified either CW or CCW, not in a "flipped N" order as you currently are doing(that's why your texture looks like a triangle). UVs range from 0 to 1, and different vertices should have different UVs. ResourceLocation textureLocation = new ResourceLocation("hackerdt", "assets/hackernotify.png"); assets/ gets resolved automatically, you do not need to specify it in your path. You must have your resources(textures/sounds/jsons/etc) in assets/modid/ folder. GlStateManager.pushMatrix(); GlStateManager.popMatrix(); ? RenderGameOverlayEvent has different ElementTypes you need to check, otherwise you will be drawing your image multiple times a frame for each thing the event fires for. A priority of an event is NORMAL by default, you do not need to explicitly specify it.

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.

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.