Animefan8888

I meant to convey confusion with that. I apologize that it came off as annoyance or me loosing my patience. Though I do loose my patience on here with some people and do get annoyed by some as well. I can't say I've ever had that experience with you. But back to your problem what was it you were trying to learn from that section of code? If you are still trying to accomplish rendering a moveable image. Then you bind the texture to OpenGL with TextureManager#bindTexture and then if you are in a Gui/Screen use blit. Specify the values it asks for like you would render your background of the gui. So the parameters for this blit method is where on the screen x,y then where in the image x,y then the width and height to render it to the screen. There are more versions of blit which allow you to customize various things. One limitation of the above method is that it only works with 256x256 images. Another one is you can't scale up or down the size of the image.

I wasn't intending to be negative. I was wondering what information you were trying to gleam from that method. What about it did you want to know? I wanted to know what you didn't understand.

What version are you using and how much code do you have?

We don't teach Java here. If you don't know what implement means search it on google. If you don't know what a field is look that up on google. Otherwise you'll need to be more clear on what you are having a problem with.

What are you looking through those methods for? TextureManager#bindTexture binds the texture you want to OpenGL then Gui/Screen#blit takes the bound texture and renders it to the screen by giving OpenGL vertices. This is exactly what you want. Now to make it move change the relX and relY variables every tick and use partialTicks to interpolate it.

They have to implement IProxy yes, Then you change the @SidedProxy field in your Main class to IProxy.

Does not equal com.mintry.ruinsoftime.proxy.ClientProxy Change your string to the latter. And you'll also want to change your CommonProxy one. On that note you should change your proxy system a bit. Get rid of CommonProxy and repalce it with ServerProxy and make both of your proxies extend from an interface you will create typically called IProxy. The reason for this is a CommonProxy is your "Main" class(@Mod class).

Post it here.

Does this class of yours exist at that position?

Even soft dependencies must be there at compile time. However it sounds like you are having problems with IntelliJ not working like you are supposed to have you looked around on other forums that are a out IntelliJ?

Where do you call updatePoweredState?

PacketBuffer#readCompoundTag

In an ideal world, everyone would use Capabilities and not mess with the ItemStacks NBTTagCompound at all. So basically always use Capabilities. If we are talking computer performance, I think NBTTagCompound just boils down to a HashMap and a Capability is also stored in a HashMap. Capability are easier to read and NBT is sloppy. If we are talking the amount of time to write the code, it comes down to how much information, for small amounts NBT is faster to implement but larger amounts it's typically faster to create a Capability. In RAM NBT is a HashMap<String, INBT> where INBT is a single NBT attribute a Compound/HashMap, List/ArrayList, NBTInt/int, etc. Where as in a Capability you define your own object that is attached to a Object(Entity, ItemStack, World, etc) and you store it there in whatever manner you want(not NBT). On disk everything is converted to NBT and written in Minecraft's custom file format.

The same way you did it before.

Double click it/run it.

Yes why not take a look at SwordItem to see how it's damage is applied? If you knew Java you would know how ridiculous this question sounded. What do you mean "do I need to make a new package"?

No, you'll have to edit the model code yourself.

Then you get to be the person to tell them they are doing it wrong. It's passed in as a parameter and should be used as such. The only use case for them to use that method is in Item#onItemRightClick, but once again this doesn't matter. Imagine changing the ItemStack in that slot before before calling their items method. Yes you can totally do that. Just remember to change it back after you call it. onItemRightClick(world, player, hand) { originalStack = player.getHeldItem(hand); stackWithModuleItem = new ItemStack(getActiveModuleItem(), 1); player.setHeldItem(hand, stackWithModuleItem); stackWithModuleItem.getItem().onItemRightClick(world, player, hand); player.setHeldItem(originalStack); }

Well you have to register all of these Module Items anyways. Don't conditionally register them. ItemUseContext has an ItemStack inside it. And ItemUseContext is what is passed to Item#onItemUse.

Take a look at setRotateAngles does and make it do that to your horns too. Otherwise yes you would have to merge them.

None of this ever references your OreGenConfig class or potentially an instance of it so I don't know how you expect it to be loaded.

Your config is not setup properly then. Post all the code relating to your config file.

I don't think you understood what I said. I never said anything about registering Items. Plus what is init that's an old term used pre 1.13. FMLPreInitializationEvent, FMLInitializationEvent, and FMLPostInitializationEvent are gone. Yes you can...all an ItemStack is is an Item with entry specific values like a count and Capabilities.

What about? Use the debugger or println statements.

Where do you call this method? And where do you setup your config file? Is it being loaded properly?