The Recipe table is keyed by your LIST of ItemID ints,
and thats just not going to fly in 172.
I have been making adjustments as needed with the rest of your codes,
but is it reasonable to make a hash keyed to that LIST as upto 7 ITEMSTACKS rather than ints?
I'm going to try an 'overloaded' variant of your Recipe methods
that just shove the array of itemstacks as a LIST<ITEMSTACK> to key off of.
If I do it right with the addInscribing() calls, passing a ItemStack[] list
maybe the lookup will be as simple as using the container passed array directly
The reason I did not use ItemStack is it was not hashable; you may run into the same problems using a List of ItemStacks where using "list.contains(stuff)" does not return properly.
As for IDs not flying in 1.7.2, they fly perfectly well. Item.getItemByID(ID) and Item.getIdFromItem(Item), or something like that since I don't have my development environment open at the moment.
The reason I did not use ItemStack is it was not hashable; you may run into the same problems using a List of ItemStacks where using "list.contains(stuff)" does not return properly.
As for IDs not flying in 1.7.2, they fly perfectly well. Item.getItemByID(ID) and Item.getIdFromItem(Item), or something like that since I don't have my development environment open at the moment.
I ran into this problem just now. I was attempting to add ItemStack(s) into a HashMap, only because I wanted to handle the amount of items that are put inside my "2-3 input furnace". For example; (1 apple, 8 gold = 1 gold apple), but in your tutorial that is not implemented.
Also, you should think about those people who don't always want to use an Item, perhaps they want to use Blocks. I suppose a simple solution would be to check the Object that is being passed to see if it's an Item or a Block, but using ItemStack would be a preferred solution.
Edit #1: I've just found the post you created awhile back regarding the same problem that I've encountered. After reading a few posts and suggestions, I came across a post that suggests using Mutable objects are not the best idea to use as a Key in a Hashmap. Mutable objects are susceptible to having their data changed, where as Immutable objects can't be changed later on down the road.
The bottom line is that it is better to use immutable objects as keys.
Edit #2: I found a solution to the problem, Instead of using an ArrayList, I created a custom class to handle recipes using ItemStack(s). Note; as mentioned above, ItemStack is not hashable, so I had to use the itemid(s). I've included a link to the working example that I've created. Also, a message to those of you who didn't know, it's fairly easy to override the hashcode and equals methods by clicking (Source -> Generate hashcode() and equals()) using eclipse.
I ran into this problem just now. I was attempting to add ItemStack(s) into a HashMap, only because I wanted to handle the amount of items that are put inside my "2-3 input furnace". For example; (1 apple, 8 gold = 1 gold apple), but in your tutorial that is not implemented.
Also, you should think about those people who don't always want to use an Item, perhaps they want to use Blocks. I suppose a simple solution would be to check the Object that is being passed to see if it's an Item or a Block, but using ItemStack would be a preferred solution.
Edit #1: I've just found the post you created awhile back regarding the same problem that I've encountered. After reading a few posts and suggestions, I came across a post that suggests using Mutable objects are not the best idea to use as a Key in a Hashmap. Mutable objects are susceptible to having their data changed, where as Immutable objects can't be changed later on down the road.
The bottom line is that it is better to use immutable objects as keys.
Edit #2: I found a solution to the problem, Instead of using an ArrayList, I created a custom class to handle recipes using ItemStack(s). Note; as mentioned above, ItemStack is not hashable, so I had to use the itemid(s). I've included a link to the working example that I've created. Also, a message to those of you who didn't know, it's fairly easy to override the hashcode and equals methods by clicking (Source -> Generate hashcode() and equals()) using eclipse.
Hashcode is not infallible, especially for complex objects, but yes, you can certainly do that. The ArrayList method works perfectly well, however, and can handle blocks just as well as items. Never heard of Item.itemsList[blockID] ? How do you think ItemStacks with Blocks are created in the first place? That's why all the Item IDs were offset by 256, and I'm pretty sure Forge does a lot of work behind the scenes to squeeze in those extra 4000 or so blocks. In 1.7.2, you can use "Item.getItemFromBlock(Block)" for the same effect, coupled with the same methods I mentioned above as well as the Block versions of those same methods.
So anyway, glad you're thinking about this stuff and found a solution that works for you, but there was nothing inherently wrong in the first place
I have not had time to check out 1.7.2 but I appreciate the information.
I wouldn't go as far as saying there is something wrong with the tutorial, because there isn't. It's just missing a step that I felt a few people might be curious about. Unless I am blind, I don't see a valid option to handle the amount of items in the recipe. As I stated above, I was trying to create a recipe, for example (1 apple, 8 gold, result). Using the class I created, I have control over the amount of items in my input slot(s) now. Simply by typing "new DualInputRecipe(new ItemStack(Item.redApple, 1), new ItemStack(Item.ingotGold, 8))". You don't offer that option since you're just creating an arraylist of itemid(s).
I have not had time to check out 1.7.2 but I appreciate the information.
I wouldn't go as far as saying there is something wrong with the tutorial, because there isn't. It's just missing a step that I felt a few people might be curious about. Unless I am blind, I don't see a valid option to handle the amount of items in the recipe. As I stated above, I was trying to create a recipe, for example (1 apple, 8 gold, result). Using the class I created, I have control over the amount of items in my input slot(s) now. Simply by typing (new ItemStack(Item.redApple, 1), new ItemStack(Item.ingotGold, 8), MyResultingItemStack). You don't offer that option since you're just creating an arraylist of itemid(s).
The point of the tutorial was simply creating multiple inputs and outputs; as you can see, you were easily able to adapt it to your needs, as would anyone with moderate knowledge of Java. My recipes were focused on items with metadata that only ever had a single item in the stack, much like vanilla smelting recipes that only take a single item at a time, and you are incorrect about the array list - it has item ids and metadata and could just as easily have the number of items required if I had needed that.
Regarding hashcodes, here's a little reading about the subject that may help inform you of some pitfalls to using ItemStacks as keys in your HashMap. Probably not a big deal, but it's good to at least be aware of the possibility.
I am merely providing another option that I discovered on my own and introduced a possible solution for those who are looking for one.
Also, I understand there are pitfalls, but I'm not using my class on a large scale, so it will be fine to use. There is always some sort of way to do something better when it comes to programming, most of it is preference and can be argued until the end of time.
I am merely providing another option that I discovered on my own and introduced a possible solution for those who are looking for one.
Also, I understand there are pitfalls, but I'm not using my class on a large scale, so it will be fine to use. There is always some sort of way to do something better when it comes to programming, most of it is preference and can be argued until the end of time.
That's fine, but in your earlier post you implied that the solution from the tutorial wouldn't work:
Also, you should think about those people who don't always want to use an Item, perhaps they want to use Blocks. I suppose a simple solution would be to check the Object that is being passed to see if it's an Item or a Block, but using ItemStack would be a preferred solution.
That's blatantly false, as I explained earlier about Blocks and Items.
Using hashed ItemStacks is probably just as good (or rather, bad) of a solution as the ArrayList - both will probably fail under certain circumstances. ArrayList is mutable, as you pointed out, which is not good, but since no one should ever have access to the ArrayList itself, that negates that part of the problem; even so, a list of integers will just have the hashcode calculated for that list, just as you are calculating a hashcode for ItemStacks (which are also mutable, btw), so given enough furnace recipes, I would imagine that either case will result in some duplicate hashcodes.
Now whether the ArrayList<Integer> or the hashed ItemStack will fail first is anybody's guess, but do note that ItemStack's can have NBT data, and your hashcode needs to be implemented in a way such that any two objects that are equal MUST have the same hashcode, so that's a lot trickier to write. My reasoning for using an ArrayList of integers was simple: that's how it's done in vanilla Minecraft. An extra integer per entry would be no problem to add, giving you your stack size, without having to write a difficult hashcode algorithm. If you can do it, go for it, but I don't think it's an appropriate solution for the majority of cases.
Hey good job on the tutorial, how compatible is it with 1.7.2
If you mean the concepts explained in the tutorial, then perfectly compatible; if you mean copying the code directly, then it's as compatible as any other 1.6.4 code
The main thing you'll need is a way to get IDs for and from Block and Item, which I've explained earlier:
As for IDs not flying in 1.7.2, they fly perfectly well. Item.getItemByID(ID) and Item.getIdFromItem(Item), or something like that since I don't have my development environment open at the moment.
There are similar static methods in the Block class.
@Override
public void readFromNBT(NBTTagCompound tagCompound)
{
super.readFromNBT(tagCompound);
NBTTagList nbttaglist = tagCompound.getTagList("Items");
this.coffeeMakerInventory = new ItemStack[this.getSizeInventory()];
for (int i = 0; i < nbttaglist.tagCount(); ++i)
{
NBTTagCompound nbttagcompound1 = (NBTTagCompound)nbttaglist.tagAt(i);
int b0 = nbttagcompound1.getInteger("Slot");
in other news
I'm having a puzzler in my modified ChargedRune handling:
My mod Applejack is harnessing the awesome powers of apples, so rather than scribing paper to scrolls I changed your tutorial code to take an apple as a Blank, output whatever the recipe says, and I use just recipe Inputs 0-1 to 'power' it as Charged items. Great, all my recipes start with a 'charged' power item(coal so far), only container items show up in the Discharge, so Bobs-your-uncle.
However
I am having trouble putting Charcoal in the list of Charged/power items.
public static int getInscriberChargeTime(ItemStack stack) {
if ( stack == null) return 0;
int met = stack.getItemDamage();
aj.ajOut("+++BimBug+++ getChargeTime for "+ stack.getDisplayName()+", subtype "+met);
if ( stack.getItem()== Items.coal){
if ( met == 1) return RUNE_CHARGE_TIME / 2;
return RUNE_CHARGE_TIME;
}
return 0;
}
I throw a Coal+xyz recipe in, the target shows in the recipe slot, machine powers,
and my ajout() console print says it got coal in the getInsciberChargeTime().
But when I throw Charcoal in, THAT Charcoal+ijk recipe shows in the recipe slot, but no power
and no console line saying it even considered looking at the charcoal in getInscriberChargeTime()
for testing, I have a coal recipe give iron ingots and the charcoal recipe give gold ingots ... just to check functionality for now, real recipes later. When I load the charcoal recipe the correct gold result shows in the recipe slot, but machine wont even TRY to power.
What am I missing in the logic of powering up the machine with Charged items? I thought everything I put in isSource() --> getInscriberChargeTime() will count as a charged item
as for using Items.coal to find Charcoal too,
that is the method I used in the recipe
(btw, I use nIS() as an overloaded frontend for new ItemStack() for shorter lines of code )
this.addInscribing( nIS( Items.coal,5,1) , 0.5F, Arrays.asList(
iid( Items.coal),
iid( Items.redstone),
iid( Items.iron_ingot) ) );
this.addInscribing( nIS( Items.gold_ingot,5,0) , 0.5F, Arrays.asList(
iid( Items.coal), 1,
iid( Items.redstone),
iid( Items.iron_ingot) ) );
[code]
Yes, I reversed the order of the arg pass to have a cleaner layout when doing a bunch of recipes.
And to do the lookup-
[code]
public ItemStack getInscribingResult(ItemStack[] stacks){
// count the recipe length so we can make the appropriate sized array
int recipeLength = 0 ;
int metaLength = 0 ;
int pointer = 0 ;
for (int i = 0; i < stacks.length && stacks[i] != null
&& i < GCApplicator.RUNE_SLOTS; ++i){
++recipeLength;
if ( stacks[i].getItemDamage() != 0 ) ++metaLength;
}
// make the array and fill it with the integer values from the passed in ItemStacks
Integer[] idIndex = new Integer[recipeLength + metaLength]; // add room for metas
for (int i = 0; i < recipeLength; ++i) { // runs thru passed stack[]
//i is for stack[], pointer is for list key array
idIndex[pointer] = (Integer) Item.getIdFromItem( stacks[i].getItem() );
++pointer;
int met = stacks[i].getItemDamage(); // will add meta if it exist
if (met != 0){
idIndex[pointer] = (Integer) met;
++pointer;
}
}
// And use it as the key to get the correct result from the HashMap:
return (ItemStack) metaInscribingList.get( Arrays.asList( idIndex ) );
}
so using the Items.Coal.getID and meta 1 does work for charcoal in the recipes,
but I cant see where your tutorial is refusing to even look it up in isSource() or getInscriberChardTime()
so using the Items.Coal.getID and meta 1 does work for charcoal in the recipes,
but I cant see where your tutorial is refusing to even look it up in isSource() or getInscriberChardTime()
isSource is only used in the Container for convenience of merging stacks into the appropriate slots during shift-click.
getInscriberChargeTime relies on canInscribe(), so if you don't allow for metadata (i.e. charcoal) in your canInscribe implementation, then your charging time will never get set.
getInscriberChargeTime relies on canInscribe(), so if you don't allow for metadata (i.e. charcoal) in your canInscribe implementation, then your charging time will never get set.
aha!
Further reading into the algorithm in canInscribe() explained what I was doing wrong.
I was so focused on the input Charcoal and the Recipe display...
I failed to notice the Output held iron from previous run... cant start a gold run if the output is holding iron
Your code works good,
I was failing to work your code good .
At least when the user (me) stops using it wrong, my changes of your tut for do work.
ty for pointing me at the canInscribe() traffic cop
Hey mate thanks for you help with the nbt errors I had
After fiddling around and looking to the vanilla furnace tile entity for advice with updating the class to 1.7.2 and to suit my needs for a machine rather than to be an inscriber I have managed to make the entire class error free except one
Hey mate thanks for you help with the nbt errors I had
After fiddling around and looking to the vanilla furnace tile entity for advice with updating the class to 1.7.2 and to suit my needs for a machine rather than to be an inscriber I have managed to make the entire class error free except one
The method updateMachineBlockState(boolean, World, int, int, int) is undefined for the type Block
Remove the @Override above the method - it's not an inherited method, it's a funky hackish workaround that Furnaces use to change the block in the world without spilling all of the inventory; since my Inscriber block also needed to change states, I implemented basically a copy of that method, and you probably will want that, too.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe reason I did not use ItemStack is it was not hashable; you may run into the same problems using a List of ItemStacks where using "list.contains(stuff)" does not return properly.
As for IDs not flying in 1.7.2, they fly perfectly well. Item.getItemByID(ID) and Item.getIdFromItem(Item), or something like that since I don't have my development environment open at the moment.
I ran into this problem just now. I was attempting to add ItemStack(s) into a HashMap, only because I wanted to handle the amount of items that are put inside my "2-3 input furnace". For example; (1 apple, 8 gold = 1 gold apple), but in your tutorial that is not implemented.
Also, you should think about those people who don't always want to use an Item, perhaps they want to use Blocks. I suppose a simple solution would be to check the Object that is being passed to see if it's an Item or a Block, but using ItemStack would be a preferred solution.
Edit #1: I've just found the post you created awhile back regarding the same problem that I've encountered. After reading a few posts and suggestions, I came across a post that suggests using Mutable objects are not the best idea to use as a Key in a Hashmap. Mutable objects are susceptible to having their data changed, where as Immutable objects can't be changed later on down the road.
The bottom line is that it is better to use immutable objects as keys.
Edit #2: I found a solution to the problem, Instead of using an ArrayList, I created a custom class to handle recipes using ItemStack(s). Note; as mentioned above, ItemStack is not hashable, so I had to use the itemid(s). I've included a link to the working example that I've created. Also, a message to those of you who didn't know, it's fairly easy to override the hashcode and equals methods by clicking (Source -> Generate hashcode() and equals()) using eclipse.
http://pastebin.com/SuF5LDLu
ooooo, thats a handy tip I'm gonna file away for other projects
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumHashcode is not infallible, especially for complex objects, but yes, you can certainly do that. The ArrayList method works perfectly well, however, and can handle blocks just as well as items. Never heard of Item.itemsList[blockID] ? How do you think ItemStacks with Blocks are created in the first place? That's why all the Item IDs were offset by 256, and I'm pretty sure Forge does a lot of work behind the scenes to squeeze in those extra 4000 or so blocks. In 1.7.2, you can use "Item.getItemFromBlock(Block)" for the same effect, coupled with the same methods I mentioned above as well as the Block versions of those same methods.
So anyway, glad you're thinking about this stuff and found a solution that works for you, but there was nothing inherently wrong in the first place
I wouldn't go as far as saying there is something wrong with the tutorial, because there isn't. It's just missing a step that I felt a few people might be curious about. Unless I am blind, I don't see a valid option to handle the amount of items in the recipe. As I stated above, I was trying to create a recipe, for example (1 apple, 8 gold, result). Using the class I created, I have control over the amount of items in my input slot(s) now. Simply by typing "new DualInputRecipe(new ItemStack(Item.redApple, 1), new ItemStack(Item.ingotGold, 8))". You don't offer that option since you're just creating an arraylist of itemid(s).
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThe point of the tutorial was simply creating multiple inputs and outputs; as you can see, you were easily able to adapt it to your needs, as would anyone with moderate knowledge of Java. My recipes were focused on items with metadata that only ever had a single item in the stack, much like vanilla smelting recipes that only take a single item at a time, and you are incorrect about the array list - it has item ids and metadata and could just as easily have the number of items required if I had needed that.
Regarding hashcodes, here's a little reading about the subject that may help inform you of some pitfalls to using ItemStacks as keys in your HashMap. Probably not a big deal, but it's good to at least be aware of the possibility.
Also, I understand there are pitfalls, but I'm not using my class on a large scale, so it will be fine to use. There is always some sort of way to do something better when it comes to programming, most of it is preference and can be argued until the end of time.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat's fine, but in your earlier post you implied that the solution from the tutorial wouldn't work:
That's blatantly false, as I explained earlier about Blocks and Items.
Using hashed ItemStacks is probably just as good (or rather, bad) of a solution as the ArrayList - both will probably fail under certain circumstances. ArrayList is mutable, as you pointed out, which is not good, but since no one should ever have access to the ArrayList itself, that negates that part of the problem; even so, a list of integers will just have the hashcode calculated for that list, just as you are calculating a hashcode for ItemStacks (which are also mutable, btw), so given enough furnace recipes, I would imagine that either case will result in some duplicate hashcodes.
Now whether the ArrayList<Integer> or the hashed ItemStack will fail first is anybody's guess, but do note that ItemStack's can have NBT data, and your hashcode needs to be implemented in a way such that any two objects that are equal MUST have the same hashcode, so that's a lot trickier to write. My reasoning for using an ArrayList of integers was simple: that's how it's done in vanilla Minecraft. An extra integer per entry would be no problem to add, giving you your stack size, without having to write a difficult hashcode algorithm. If you can do it, go for it, but I don't think it's an appropriate solution for the majority of cases.
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumIf you mean the concepts explained in the tutorial, then perfectly compatible; if you mean copying the code directly, then it's as compatible as any other 1.6.4 code
The main thing you'll need is a way to get IDs for and from Block and Item, which I've explained earlier:
There are similar static methods in the Block class.
Any item.id refrence that I've seen in 1.6.4 tutorials is now just items.item
I'm definitely having a fair crack at implementing this tutorial into 1.7.2 but am having a bit of trouble around the nbt tags section :/
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumYou would need the Item or Block ID in order to implement the recipes; IDs are still used in the code, albeit much less frequently.
NBT is mostly the same as it was in 1.6.4; what are you having trouble with specifically?
public void readFromNBT(NBTTagCompound tagCompound)
{
super.readFromNBT(tagCompound);
NBTTagList nbttaglist = tagCompound.getTagList("Items");
this.coffeeMakerInventory = new ItemStack[this.getSizeInventory()];
for (int i = 0; i < nbttaglist.tagCount(); ++i)
{
NBTTagCompound nbttagcompound1 = (NBTTagCompound)nbttaglist.tagAt(i);
int b0 = nbttagcompound1.getInteger("Slot");
if (b0 >= 0 && b0 < this.coffeeMakerInventory.length)
{
this.coffeeMakerInventory[b0] = ItemStack.loadItemStackFromNBT(nbttagcompound1);
}
error one The method getTagList(String, int) in the type NBTTagCompound is not applicable for the arguments (String)
error two The method tagAt(int) is undefined for the type NBTTagList what's the int meant to be
-
View User Profile
-
View Posts
-
Send Message
Curse Premium1. NBTTagList taglist = compound.getTagList("stringKey", Constants.NBT.TAG_COMPOUND);
2. NBTTagCompound compound = taglist.getCompoundTagAt(i);
Looking for the constants I came across this way to get the int for type compound tag
public void readFromNBT(NBTTagCompound tagCompound) {
super.readFromNBT(tagCompound);
NBTTagList nbttaglist = tagCompound.getTagList("Items", tagCompound.getId());
in other news
I'm having a puzzler in my modified ChargedRune handling:
My mod Applejack is harnessing the awesome powers of apples, so rather than scribing paper to scrolls I changed your tutorial code to take an apple as a Blank, output whatever the recipe says, and I use just recipe Inputs 0-1 to 'power' it as Charged items. Great, all my recipes start with a 'charged' power item(coal so far), only container items show up in the Discharge, so Bobs-your-uncle.
However
I am having trouble putting Charcoal in the list of Charged/power items.
public static int getInscriberChargeTime(ItemStack stack) { if ( stack == null) return 0; int met = stack.getItemDamage(); aj.ajOut("+++BimBug+++ getChargeTime for "+ stack.getDisplayName()+", subtype "+met); if ( stack.getItem()== Items.coal){ if ( met == 1) return RUNE_CHARGE_TIME / 2; return RUNE_CHARGE_TIME; } return 0; }I throw a Coal+xyz recipe in, the target shows in the recipe slot, machine powers,
and my ajout() console print says it got coal in the getInsciberChargeTime().
But when I throw Charcoal in, THAT Charcoal+ijk recipe shows in the recipe slot, but no power
and no console line saying it even considered looking at the charcoal in getInscriberChargeTime()
for testing, I have a coal recipe give iron ingots and the charcoal recipe give gold ingots ... just to check functionality for now, real recipes later. When I load the charcoal recipe the correct gold result shows in the recipe slot, but machine wont even TRY to power.
What am I missing in the logic of powering up the machine with Charged items?
I thought everything I put in isSource() --> getInscriberChargeTime() will count as a charged item
as for using Items.coal to find Charcoal too,
that is the method I used in the recipe
(btw, I use nIS() as an overloaded frontend for new ItemStack() for shorter lines of code )
this.addInscribing( nIS( Items.coal,5,1) , 0.5F, Arrays.asList( iid( Items.coal), iid( Items.redstone), iid( Items.iron_ingot) ) ); this.addInscribing( nIS( Items.gold_ingot,5,0) , 0.5F, Arrays.asList( iid( Items.coal), 1, iid( Items.redstone), iid( Items.iron_ingot) ) ); [code] Yes, I reversed the order of the arg pass to have a cleaner layout when doing a bunch of recipes. And to do the lookup- [code] public ItemStack getInscribingResult(ItemStack[] stacks){ // count the recipe length so we can make the appropriate sized array int recipeLength = 0 ; int metaLength = 0 ; int pointer = 0 ; for (int i = 0; i < stacks.length && stacks[i] != null && i < GCApplicator.RUNE_SLOTS; ++i){ ++recipeLength; if ( stacks[i].getItemDamage() != 0 ) ++metaLength; } // make the array and fill it with the integer values from the passed in ItemStacks Integer[] idIndex = new Integer[recipeLength + metaLength]; // add room for metas for (int i = 0; i < recipeLength; ++i) { // runs thru passed stack[] //i is for stack[], pointer is for list key array idIndex[pointer] = (Integer) Item.getIdFromItem( stacks[i].getItem() ); ++pointer; int met = stacks[i].getItemDamage(); // will add meta if it exist if (met != 0){ idIndex[pointer] = (Integer) met; ++pointer; } } // And use it as the key to get the correct result from the HashMap: return (ItemStack) metaInscribingList.get( Arrays.asList( idIndex ) ); }so using the Items.Coal.getID and meta 1 does work for charcoal in the recipes,
but I cant see where your tutorial is refusing to even look it up in isSource() or getInscriberChardTime()
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumThat works, too, and I've used it as well, but I prefer to use the Constants class.
isSource is only used in the Container for convenience of merging stacks into the appropriate slots during shift-click.
getInscriberChargeTime relies on canInscribe(), so if you don't allow for metadata (i.e. charcoal) in your canInscribe implementation, then your charging time will never get set.
aha!
Further reading into the algorithm in canInscribe() explained what I was doing wrong.
I was so focused on the input Charcoal and the Recipe display...
I failed to notice the Output held iron from previous run... cant start a gold run if the output is holding iron
Your code works good,
I was failing to work your code good
At least when the user (me) stops using it wrong, my changes of your tut for do work.
ty for pointing me at the canInscribe() traffic cop
After fiddling around and looking to the vanilla furnace tile entity for advice with updating the class to 1.7.2 and to suit my needs for a machine rather than to be an inscriber I have managed to make the entire class error free except one
Any help would be appreciated
{
flag1 = true;
BlockArcaneInscriber.updateInscriberBlockState(this.currentInscribeTime > 0, this.worldObj, this.xCoord, this.yCoord, this.zCoord);
}
The error is on "updateInscriberBlockState"
The method updateMachineBlockState(boolean, World, int, int, int) is undefined for the type Block
-
View User Profile
-
View Posts
-
Send Message
Curse PremiumRemove the @Override above the method - it's not an inherited method, it's a funky hackish workaround that Furnaces use to change the block in the world without spilling all of the inventory; since my Inscriber block also needed to change states, I implemented basically a copy of that method, and you probably will want that, too.