V0idWa1k3r

You must explicitly call GuiTextField::textboxKeyTyped to let your text fields handle the keyboard input. See how it is done in GuiCreateWorld for example.

Call this in your register method. If you are implementing an interface you must implement it's methods which are not default. In your case you must implement public Render<? super T> createRenderFor(RenderManager manager) Your IDE most likely will tell you that you need to do so anyway. This method must return a new instance of your Render class(new RenderNukePrimed(manager)) Blindly passing null into methods is probably a bad idea. Especially if you do not know what those methods do. Here is an example of how to register a renderer for your entity.

Your renderer must extend any subclass of Render<T> where T is a type of your entity class. Currently you are extending RenderTNTPrimed. That is a wrong method. Use the other method that takes IRenderingFactory as it's second parameter.

You must use RenderingRegistry::registerEntityRenderingHandler (the one overload that takes a class and a IRenderFactory). IRenderFactory is an interface that you can either implement directly or use lambdas. You must call RenderingRegistry::registerEntityRenderingHandler during pre-init from either your client proxy or another client-only class.

Please show where you are registering your entity renderer. Additionally make sure that your nuke block actually spawns your nuke entity when ignited.

Your positioning is still of. Think about it - the coordinates you are giving to the text field/button are it's top left corner. If you say "Your position is at width / 2 - 200, height / 2 - 200 and your size is 200, 20" then you are going to see the box at [width / 2 - 200 => width / 2; height / 2 - 200 => height / 2 - 180]. When you are creating a text field at width / 2 + 200 it will go from that to width / 2 + 400. The one text field you are seing is most likely your question field, everything else is way up there or down there with their current y coordinates and some are way too offset to the right. As your buttons take positions from your text fields the same is true for them.

MC works the same way, that is how rendering in 2d works. The thing is - you are drawing your buttons first. the super call in the drawScreen method is what draws the buttons. That happens because a GuiButton can only have a y size of 20 at most. I do not see where you are setting your button's size above 20 in your class though, have you changed that? By that I ment to compare your button positioning with vanilla's. You are positioning your buttons based on the positioning of your text fields, and those are not really positioned all that well... they are positioned exactly in the way they are drawn. Some are positioned against the right boundry of the screen answerB = new GuiTextField(9, this.fontRenderer, this.width - 50, 200, 200, 20); answerD = new GuiTextField(11, this.fontRenderer, this.width - 50, this.height / 2 + 100, 200, 20); Some are positioned agains left top corner of the screen answerA = new GuiTextField(8, this.fontRenderer, 200, 200, 200, 20); And this one is positioned agains the left x boundry and the middle of the screen answerC = new GuiTextField(10, this.fontRenderer, 200, this.height / 2 + 100, 200, 20); If you want the buttons to anchor to the middle of the screen position them agains it. The center is [width / 2, height / 2]. width and height here are scaled width and height of the screen.

See how vanilla does it at any of it's guis with buttons, like GuiIngameMenu. A couple of issues I can see: question.drawTextBox(); answerA.drawTextBox(); answerB.drawTextBox(); answerC.drawTextBox(); answerD.drawTextBox(); In initGui? Drawing must happen each frame, not once the GUI is open and never again. You are adding to your list but are never clearing it. Minecraft won't clear your lists for you, so every time the GUI is resized you will put "logical duplicates" into the list. this.drawDefaultBackground(); this.mc.getTextureManager().bindTexture(BACKGROUND_TEXTURE); You need to do something with the texture you are binding(hint: draw it). You can't just bind it and expect it to be drawn. In your current call ordering everything you draw will be drawn over your buttons. Your saveCard method shrinks the size of the item stack... on the client. You can't do that as the server still has different data. You need to use custom packets. After doing that it proceeds to create a new item, write a bunch of stuff into it's NBT and... discards it completely.

new ItemStack(block, amount, metadata)

OreDictionary::getOreIDs takes an ItemStack and returns all ore ids associated with that ItemStack. You can get a string ore name out of an integer ore id using OreDictionary::getOreName. Be aware that if the itemstack has no ore ids associated you will get an empty array of ids. And you also need to be aware that an item may have more than one ore name associated with it, hence the ore id being an array.

Obviously this is null. And interestingly enough you have posted every file you could but the most important one - your entity class. The client is not aware of the parameter change if you do it like this. If you want the client to be aware of some kind of data changes you need to use EntityDataManager and DataParameters. Kinda how boats do that with the BOAT_TYPE parameter. As a side note: ModelLoader is client-side only, you must call it from your proxy/client-only class or you will crash the server. Models must be registered in the appropriate ModelRegistryEvent. Unlocalized names have nothing to do with anything but displaying the name of the item, stop using them. Just use Item::getRegistryName().

Judjing by his crash report(especially the fact that there is optifine mentioned in there) I think he is not a modmaker and posted in the wrong subforum. @Gaming4me am I correct? If I am your solution lies in the fact that you've installed a wrong version of Waila. You need a normal, not dev version.

Clear the relevant lists in your initGui method. By default vanilla clears the button list on gui's resize. If you setup something else in that method you need to clear it beforehand too or you end up with stuff duplicating in your lists. To clarify: This is your culprit. The butonList is cleared before initGui is called, but your allyButtons and enemyButtons are not.

I am literally telling you how to make it so in this entire thread but you are doing something else and asking why is it not working. 1. Create a field/DataManager param that stores the amount of ticks left before the mob can be sheared. 2. Check if this value lequals 0 in your isShearable method 3. Set it to the desired cooldown in onSheared method 4. Decrement it each tick. And you are done.

This is not how you raytrace anything. Items already have a built-in raytrace method conviniently called Item::rayTrace.

What? GuiIngameMenu is a normal GuiScreen, you can just call Minecraft::displayGuiScreen with null as it's argument and call Minecraft::setIngameFocus to close it as most other GUIs. Kinda how it is already done in the very same GuiIngameMenu at GuiIngameMenu::actionPerformed when the button.id is 4.

As you press your button you would need to send a custom packet to the server that does all those operations you want it to do. As it is a container all ItemStacks changes made on the server should automatically be synced to the client watching the GUI.

You can check if the current screen (Minecraft.currentScreen) is an instance of GuiIngameMenu

registry names must be entirely lower case. GameRegistry.register is outdated. You should use registry events. ItemModelMesher is outdated and buggy, never use it. You should use ModelLoader in the approptiate ModelRegistryEvent instead. Or at least do it in pre-init and not init. Your BlockProfanePutrefaction still uses incorrect super call in the code you've attached. Your version is invalid. See this. BlockDirt specifies additional variants to your blockstate, but your json does not contain them. You will need to either override all methods that use them and noop them or choose a different class to extend, like Block. If you want a tool to be effective agains a certain block in that block's constructor you can use Block::setHarvestLevel. The first parameter is a tool class, for a shovel it is "shovel", the second parameter is the harvest level. You can leave it at 0. As it is the material by default that determines whether the block is harvestable by hand or not the GROUND material will still make your block harvestable by hand even if you call this method.

This is the correct way. Please show the code where you initialize your block and the edited block class's constructor.

You still need it regardless of your parent class. Otherwise a lot of things are not set, such as the default blockstate which indirectly controls the texture and the model, or the material which indirectly controls break speed with tools...

You are missing a super call at this constructor.

I literally mean to give them a purpose. Why do you have a method that does nothing? If you do not need them - drop them, you are returning false to begin with and that is a constant value. If you want them to do something - introduce the code to do so. That is irrelevant. The names of methods imply that they are getters and setters for whether your entity was sheared or not. If you do not need them - delete them, this is your own code. If they are supposed to be setters and getters for a value - introduce that value with a field or a DataParameter in the DataManager. This is a basic java concept. I'm not telling you to do that because of code cleanup or something like that. I'm telling you to do so because you are still using those methods as getters and setters which they are not in their current implementation and that can lead to potential issues.

If you want a custom keybind you can't use the default methods, you will need custom packets. The problem with shift-right clicking is that shift is the default keybind to stop riding an entity(or rather it is a sneak keybind and sneaking is what makes you dismount) and that is defined in EntityPlayer so you can't change that. ? If you are creating getters and setters make them have a purpose. Post the log then.

In what way? You can simply check if the player is holding shears or not. If they are - run the shearing code, if they are not - ride your entity.