[1.9.4] Dupe bug with reliquary
Tsukiumy opened this issue ยท 14 comments
rftools-1.9.4-4.64
Reliquary-1.9.4-1.3.2.390
if needed i can get a list of all the mods that are present
i was in my creative world testing some things that i want to buld on my survival world, and when i tried to use the crafter to charge the tome of alkahestry using blocks of redstone, it started to duplicate the book, leaving the original and the result in the grid, allowing the user to convert the exceding one to be used to create more redstone, and with that create more books, in a loop, just as a note that the alkahestry is OP AF, as it can be used to multiply some itens, like ender pearls, ghast tears and nether stars
http://i.imgur.com/c8TZFNQ.png
what info u need :3 , btw, added a pic to show more or less
P3pp3rF1y/Reliquary#112
just in case its on her side of the bug
The way I am handling the charging seems pretty standard to me - in getCraftingResult update the tome's meta to new value and in getRemainingItems I make sure that the original tome isn't one of the remaining items.
See:https://github.com/P3pp3rF1y/Reliquary/blob/1.9/src/main/java/xreliquary/items/alkahestry/AlkahestryChargingRecipe.java
If I am doing something wrong there I am happy to fix it but I don't see anything obvious.
Hmm... In RFTools I have similar items that give an additional result but I solved that by having the 'container' item implement Item.getContainerItem(). My crafter supports that just fine.
I will investigate more about getRemainingItems() though. Have not come accross that before and I would like to find some other cases where this is being used in vanilla first so that I can test with how vanilla handles this
And I took a look at it and unless I am missing something there's no way I can just use getContainerItem for this here. I checked your storage tablet which uses it but you only have 2 states - full/empty so you can decide whether you return null or actual item in recipes. But in my case Alkahestry Tome with exact same meta can be used in both charging recipe - in which case it shouldn't be among the remaining - and in crafting recipes - in which case it needs to stay among the remaining items and should get its charge decreased.
So yeah, it looks like to avoid this bug you would need to call getRemainingItems.
Actually I took a look at vanilla's RecipeRepairItem/RecipesBanners/RecipesArmorDyes and none of them seem to use getRemainingItems in the way I do and yet they are very close in behavior to what I need to do here. So I will take a look at this on my side and likely change it to the way they treat their items.
The latest version of reliquary has a check for SlotCrafting so the recipes dont work in your crafter. When you need to test you will need to grab previous one.
I am typing this on phone so I probably wasn't clear. What I meant was I will be happy to see rftools support getRemainingItems but given the SlotCrafting check in the latest version tome crafting recipes won't work in your crafter so you will need previous one to test those.
Also one more thing I noticed is that you seem to check for exact damage but this will change as tome is charged or used to craft items. Not sure there's easy solution for that though - maybe check if it's damageable and in that case allow any meta?
Well RFTools does not even use SlotCrafting. At all. So why wouldn't it work? I also tested, it does work actually. But yes, I am having that other issue which is what I'm working on right now
I guess Forgecraft wasn't using the latest version then because it is working fine for me.
SlotCrafting actually takes care of calling getRemainingItems in all manual crafting cases. So I added a check for it in the recipes in the latest reliquary version. That's why with latest version you won't see any tome recipes in crafter but you will in crafting table. Will need to add some kind of whitelist for auto crafters in reliquary later on.