Jump to content

yooksi

Members
  • Posts

    112
  • Joined

  • Last visited

Everything posted by yooksi

  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?
  16. It's called by other methods beside Item#onUpdate . I still believe we should have a method that edits the item of an ItemStack, all this effort seems like hacking to me. We also have to allocate new objects all the time when all we want to do is replace the Item and leave other ItemStack properties the same.
  17. You're right, that's a better idea, I was overthinking it. I don't know this in every situation, the itemSlot method argument will sometimes be passed as -1.
  18. Can we see the updated whole class? The main EntityItem class. Handle spawning after block break. Handling spawning after a toss event. Let me know if you need me to provide more information.
  19. I don't know what CombinedInvWrapper and RangedWrapper are, can you give me a simpler explanation? I am not a really experienced modder. CombinedInvWrapper combines multiple IItemHandler inventories into one. RangedWrapper exposes a range of slots from an IItemHandler inventory. Aha, so for example, it merges all player inventories into one?
  20. This is how my method code looks after I've tried to work around ItemStack#setItem: NewItemTorch.java. Notice that I am forced to call ItemStack#areItemStacksEqual quite often, and from what I've seen in the code belonging to the methods called, this might get really expensive after continued use. Especially since I have to scan the whole player inventory, and if the player is carrying a lot of items... you see my point. I am very sensitive about code optimization and even though I try not to fall into the pit of premature optimization, I'm still often worried about my code performance. Do you think I am overreacting in this case?
  21. I don't know what CombinedInvWrapper and RangedWrapper are, can you give me a simpler explanation? I am not a really experienced modder.
  22. The difficulty is that Item#onUpdate will be called for items in any of the player's three inventory sections (main, armour and off hand), so you need to check which section it's in before trying to interact with that section. You can do this by checking if the ItemStack in the provided slot of the inventory section is the same as the provided ItemStack . I do this here. This doesn't handle the item being in the player's off hand. I see you use IItemHandler to interact with player inventory. What are the advantages of manipulating the inventory that way over using PlayerInventory?
  23. Are there any advantages of using the old method over the new one?
  24. Bumpy ol' bump! Can anyone help me with this issue?
×
×
  • Create New...

Important Information

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