Jump to content


  • Posts

  • Joined

  • Last visited


  • Gender
  • URL
  • Location
    Dresden, Germany
  • Personal Text
    A mysterious figure emerges from the sand...

yooksi's Achievements

Creeper Killer

Creeper Killer (4/8)



  1. I was manage to accomplish what I wanted with a custom item model class, thanks to your example on GitHub. Marking this thread solved.
  2. Thanks for the reply, I will take a look at your example in a moment. I have a feeling though that you're talking about blocks, while I am thinking about items. I know that blocks can have translucent textures, but can items have them too?
  3. The easiest solution would be to stop using NBT to store metadata, and use the local metadata value in Item for that, like it was meant to be used.
  4. Is there a way to render a texture layer transparent, even though the texture itself is not transparent? This would really help me in reducing the amount of model files that share almost exactly the same properties. Every time I create a new item variation that has an extra layer, I have to create a new model file for it, and since it's a bow, this means it has to come with three more pulling models as well.
  5. Did you set item max damage to 0, and are you changing item damage at any point in your code?
  6. From what he has shown us I would say no. @XFactHD In order to get your subtypes to work and call getSubItems you have to call setHasSubtypes(true) from inside your ItemBlockRFCapacitor ItemBlock class constructor.
  7. After taking a look at ShapedOreRecipe and RecipeFirework , I realized that setting up this class manually is going to be a pain in the ass, and for some reason I don't feel comfortable extending ShapedOreRecipe out of pure convenience in the moment. If it gets changed and becomes incompatible with my recipes, I will have to rewrite them. Makes more sense to set it up manually, right? EDIT: I figured out that ShapedOreRecipe is actually a Forge implemented class, and in order to have a custom recipe class I need to register it and all that. Think I will stick with the native Forge class for now.
  8. I am guessing that I have to declare my recipe as an IRecipe and then make it override IRecipe#getCraftingResult , correct? If so, I don't know how to do this, any examples?
  9. Spot on, that's exactly what I am doing. When should create a new NBTTagCompound for the item to make this work?
  10. Ah, you are right. Now that I checked it again getColorFromItemstack does get properly called even when the item is in the crafting output grid. I must have been setting my debug breakpoints in wrong places, because I could have sworn it was never called. However, my next problem is that because I store the colour values (or to be more precise dyeColor metadata values) in item NBT, I am unable to retrieve them when crafting because the item did not have a chance to initialize it's NBTTagCompound. I do the initialization when the ItemCraftedEvent is fired. I would like to do the initialization in getSubItems but unfortunately that is not called until after the item has been crafted (pulled out of the crafting output slot). Any idea on how I should handle this?
  11. I want the ItemStack that is the result of the crafting (displayed in the crafting output slot) to be coloured, much the same way as it would be after it leaves the crafting output slot - via the use of IItemColor#getColorFromItemstack . The mentioned method works for all cases except when the item is residing in the crafting output slot, then a default texture is used (from metadata). So let's say I've got a test item that has a model file and a custom texture all set up. I register a ColorHandler for it, and return Color.RED from getColorFromItemstack . The item is properly colored red in my inventory and in the creative tabs. Everything works fine until I decide to craft that item, in which case the item is displayed un-colored (using the default texture, without custom color applied to it) in the crafting output slot. When removed, the item is rendered normally again. In order to fix this I would need to abandon the subtype system of handling this item and split it up into separate items (one for each color), each with it's own model and texture file. My question is, is there a way of forcing the item in the crafting output slot to be rendered with a color applied to it (just like we do with getColorFromItemstack ) WITHOUT resorting to dedicating separate item classes, model and texture files? Hope I made more sense this time =)
  12. After a lot of experimenting I've learned the basics of setting up item subtypes and making them display in different colours via ColorHandlers. This however does not work for items that are displayed in the crafting output field when crafting (they are displayed with their default non-coloured textures). The only way I know how to fix this is to make an item model and texture file for every colour I want (not to mention registering separate classes). This will bring a lot of redundant files, is there a way around this?
  13. Makes sense, but if it's going to go away in the future, isn't it better to avoid using it before your code gets so dependent on it that it requires a complete rewrite to make it compliant to the new changes?
  14. Thank you, I definitely didn't know that we can register our event handler classes with a simple annotation. Basically I should use @Mod.EventBusSubscriber for all my event handlers, as they all contain only static methods and fields.
  15. I've seen people register them in all three initialization phases, but which way is the correct one? I myself register it in the pos-Init phase and I've never had a problem with it. That raises the second question: is it really important when we do it?
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.