That method needs a tag compound passed to it. So you need to make a tag compound called chicken, and also make sure the data inside the compound is correct. Looking at epoxide's code, it looks like he has a tag key called "brainType" which you would have to put in the string value of "chicken".
Anyways, you need to instantiate a tag compound to pass into the setTagCompound() method.
That method needs a tag compound passed to it. So you need to make a tag compound called chicken, and also make sure the data inside the compound is correct. Looking at epoxide's code, it looks like he has a tag key called "brainType" which you would have to put in the string value of "chicken".
Anyways, you need to instantiate a tag compound to pass into the setTagCompound() method.
In other words the point is that you need to make a compound that stores value according to a key. The key in this case is "brainType" and the value you want is "chicken". Then you set that tag on your item.
In other words the point is that you need to make a compound that stores value according to a key. The key in this case is "brainType" and the value you want is "chicken". Then you set that tag on your item.
for some reason now, using your exact code but changing the names from temptations to temptationssal and chicken to salmon (including the item stack) the first recipe listed in the code is the only recipe for all those items.
Our answers in this thread are just to give you the general ideas, the rest you have to figure out with regular coding knowledge. The main point is that an item stack can have NBT data that can be stored and retrieved. After that you need to get understanding on how NBT works. Epoxide's code just gives you an idea of how you can use the NBT data once you have it set -- changing names, appearence, subtypes, etc.
I would just take these ideas and do your own coding than trying to work with the Epoxide code directly. Just create item stacks, create NBTs, and add those NBTs to the item stacks. They try to read them back and do something with them. That's it! But the point is you need to really get confidence with NBTs.
Our answers in this thread are just to give you the general ideas, the rest you have to figure out with regular coding knowledge. The main point is that an item stack can have NBT data that can be stored and retrieved. After that you need to get understanding on how NBT works. Epoxide's code just gives you an idea of how you can use the NBT data once you have it set -- changing names, appearence, subtypes, etc.
I would just take these ideas and do your own coding than trying to work with the Epoxide code directly. Just create item stacks, create NBTs, and add those NBTs to the item stacks. They try to read them back and do something with them. That's it! But the point is you need to really get confidence with NBTs.
As I mentioned above, using your code and Epoxide's code, It added a recipe but it was the same recipe for all of the nbt items.
Oh, sorry, it works! It was a bug with NEI. Thanks for all the help. Very much appreciated. Would anyone like my cat food mod in their minecraft? cat food with potion effects and cheap meat with lots of hunger bars?
Oh, I don't think the NBT data would be checked by the recipe. The recipes look at the metadata not this extended NBT stuff. I think you'd need to use regular metadata to interact directly with the vanilla recipes. To process the NBT data I think you'd want to handle the crafting event and check the NBT data in addition and modify the recipe output.
Remind us again why metadata didn't work in the first place? This NBT stuff is cool if you want to add stuff that can't fit in the 4-bits of metadata, but there is a lot of vanilla code that only looks at the metadata so the NBT stuff is really for your own mod's code to process.
Oh, I don't think the NBT data would be checked by the recipe. The recipes look at the metadata not this extended NBT stuff. I think you'd need to use regular metadata to interact directly with the vanilla recipes. To process the NBT data I think you'd want to handle the crafting event and check the NBT data in addition and modify the recipe output.
Remind us again why metadata didn't work in the first place? This NBT stuff is cool if you want to add stuff that can't fit in the 4-bits of metadata, but there is a lot of vanilla code that only looks at the metadata so the NBT stuff is really for your own mod's code to process.
metadata didnt work as you can re eat the food 10 times and it adds metadata each time you eat it. Thanks for the help.
Oh, sorry, it works! It was a bug with NEI. Thanks for all the help. Very much appreciated. Would anyone like my cat food mod in their minecraft? cat food with potion effects and cheap meat with lots of hunger bars?
Thanks a lot guys.^_^
Sure give me a link i'll take a look at it, got a modpack up that likes different mods (side note: make sure it doesn't crash us)
Items can have a lot more metadata than Blocks. An ItemStack's damage value (aka metadata) is stored as a short, so you can store numbers up to Short.MAX_VALUE (32767).
You could store the food type and eaten count in the one value using bitwise operations to pack/unpack them (much like log blocks store the type and the orientation in their metadata).
Rollback Post to RevisionRollBack
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.
Items can have a lot more metadata than Blocks. An ItemStack's damage value (aka metadata) is stored as a short, so you can store numbers up to Short.MAX_VALUE (32767).
You could certainly pack a lot of info into a short. I guess an interesting question is what happens if you extend the use of metadata on a vanilla item. I would hope that they are clean in their code in terms of masking before comparing, in which case you'd be safe to extend it as much as you wanted. Right? Like dyes already use values 0 to 15 but could I set the 5th bit as a flag to denote something for my mod?
You could certainly pack a lot of info into a short. I guess an interesting question is what happens if you extend the use of metadata on a vanilla item. I would hope that they are clean in their code in terms of masking before comparing, in which case you'd be safe to extend it as much as you wanted. Right? Like dyes already use values 0 to 15 but could I set the 5th bit as a flag to denote something for my mod?
I think most Vanilla items that use the damage value for sub-items (e.g. dyes) clamp the value to the expected range before they try to do anything with it (e.g. determine icon or unlocalised name). They treat the damage value like a single number rather than a bitfield, so any values higher than the expected maximum would simply be clamped to the maximum rather than masked with the maximum using & (bitwise AND).
ItemBlock doesn't check if the damage value is in the range 0-15 before placing the block, but it's masked with 15 in NibbleArray anyway.
Rollback Post to RevisionRollBack
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.
I think most Vanilla items that use the damage value for sub-items (e.g. dyes) clamp the value to the expected range before they try to do anything with it (e.g. determine icon or unlocalised name). They treat the damage value like a single number rather than a bitfield, so any values higher than the expected maximum would simply be clamped to the maximum rather than masked with the maximum using & (bitwise AND).
ItemBlock doesn't check if the damage value is in the range 0-15 before placing the block, but it's masked with 15 in NibbleArray anyway.
Yeah, the problem is you have to trust that it is coded that way everywhere -- for example slot comparisons for isEqual(), packets, etc. I have the suspicion that if you set the metadata of a dye with 15 metadata to 31 metadata (i.e. to set a flag on bit 5 for some purpose) that it would mess some stuff up somewhere. Some vanilla code would properly see it as also a 15, but others would not consider it the same. Maybe it's all good though.
That method needs a tag compound passed to it. So you need to make a tag compound called chicken, and also make sure the data inside the compound is correct. Looking at epoxide's code, it looks like he has a tag key called "brainType" which you would have to put in the string value of "chicken".
Anyways, you need to instantiate a tag compound to pass into the setTagCompound() method.
like this?
temptations.setTagCompound(brainType.chicken);
No, something like:
NBTTagCompound chicken = new NBTTagCompound();
chicken.setString("brainType", "chicken");
temptations.setTagCompound(chicken);
In other words the point is that you need to make a compound that stores value according to a key. The key in this case is "brainType" and the value you want is "chicken". Then you set that tag on your item.
for some reason now, using your exact code but changing the names from temptations to temptationssal and chicken to salmon (including the item stack) the first recipe listed in the code is the only recipe for all those items.
Our answers in this thread are just to give you the general ideas, the rest you have to figure out with regular coding knowledge. The main point is that an item stack can have NBT data that can be stored and retrieved. After that you need to get understanding on how NBT works. Epoxide's code just gives you an idea of how you can use the NBT data once you have it set -- changing names, appearence, subtypes, etc.
I would just take these ideas and do your own coding than trying to work with the Epoxide code directly. Just create item stacks, create NBTs, and add those NBTs to the item stacks. They try to read them back and do something with them. That's it! But the point is you need to really get confidence with NBTs.
As I mentioned above, using your code and Epoxide's code, It added a recipe but it was the same recipe for all of the nbt items.
Just skimming over this all you should need to do in the recipe is:
ItemStack yourItemStack = new ItemStack(yourItem);
yourItemStack.setTagCompound(new NBTTagCompound());
yourItemStack.getTagCompound().setString("brainType", "chicken");
GameRegistry.addRecipe(yourItemStack, //recipe);
ItemStack yourOtherItemStack = new ItemStack(yourItem);
yourOtherItemStack.setTagCompound(new NBTTagCompound());
yourOtherItemStack.getTagCompound().setString("brainType", "nextBrainType");
GameRegistry.addRecipe(yourOtherItemStack, //recipe);
Give that a try
for some reason it still uses the first recipe for all the items
Did you make a different recipe? if not post your add recipe code
Oh, sorry, it works! It was a bug with NEI. Thanks for all the help. Very much appreciated. Would anyone like my cat food mod in their minecraft? cat food with potion effects and cheap meat with lots of hunger bars?
Thanks a lot guys.^_^
Oh, I don't think the NBT data would be checked by the recipe. The recipes look at the metadata not this extended NBT stuff. I think you'd need to use regular metadata to interact directly with the vanilla recipes. To process the NBT data I think you'd want to handle the crafting event and check the NBT data in addition and modify the recipe output.
Remind us again why metadata didn't work in the first place? This NBT stuff is cool if you want to add stuff that can't fit in the 4-bits of metadata, but there is a lot of vanilla code that only looks at the metadata so the NBT stuff is really for your own mod's code to process.
metadata didnt work as you can re eat the food 10 times and it adds metadata each time you eat it. Thanks for the help.
Sure give me a link i'll take a look at it, got a modpack up that likes different mods (side note: make sure it doesn't crash us)
Items can have a lot more metadata than Blocks. An ItemStack's damage value (aka metadata) is stored as a short, so you can store numbers up to Short.MAX_VALUE (32767).
You could store the food type and eaten count in the one value using bitwise operations to pack/unpack them (much like log blocks store the type and the orientation in their metadata).
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.
You could certainly pack a lot of info into a short. I guess an interesting question is what happens if you extend the use of metadata on a vanilla item. I would hope that they are clean in their code in terms of masking before comparing, in which case you'd be safe to extend it as much as you wanted. Right? Like dyes already use values 0 to 15 but could I set the 5th bit as a flag to denote something for my mod?
I think most Vanilla items that use the damage value for sub-items (e.g. dyes) clamp the value to the expected range before they try to do anything with it (e.g. determine icon or unlocalised name). They treat the damage value like a single number rather than a bitfield, so any values higher than the expected maximum would simply be clamped to the maximum rather than masked with the maximum using & (bitwise AND).
ItemBlock doesn't check if the damage value is in the range 0-15 before placing the block, but it's masked with 15 in NibbleArray anyway.
Chisel Facades: For all your decorative pipe-hiding needs.
Please don't PM me to ask for help or to join your mod development team. Asking your question in a public thread preserves it for people who are having the same problem in the future. I'm not interested in developing mods with people.
Yeah, the problem is you have to trust that it is coded that way everywhere -- for example slot comparisons for isEqual(), packets, etc. I have the suspicion that if you set the metadata of a dye with 15 metadata to 31 metadata (i.e. to set a flag on bit 5 for some purpose) that it would mess some stuff up somewhere. Some vanilla code would properly see it as also a 15, but others would not consider it the same. Maybe it's all good though.