Non players (aka auto crafters) do not use the charge on the tome of Alkahestry, leading to infinite duping as long as the intial crafting cost is met.

This issue has the same cause as #112. Unfortunately it is something that needs to be fixed on RFTools side and it is tracked there as well McJtyMods/RFTools#583.

it used to be crafting event, but I have changed that to a more standard way (in my opinion) that every recipe has. There is a method in every recipe that defines which items are supposed to be remaining after an item is crafted. This method is properly called in vanilla at the time player crafts an item, but is not called in RFTools and I guess in other crafters then.

The issue why I can't fix it on my side is that the only method that RFTools calls on my side is missing the context of the recipe. I basically get the information in that method that tome with a given charge is just being used in crafting, but there is no context of whether it is being charged with redstone or discharged crafting new stuff.

The only solutions I can think of on my side are:

• make the charging/discharging recipes dependent on enabled state of tome - e.g. if it's enabled you will only be able to charge it with redstone in crafting table, otherwise you are only able to craft new items with it. This may be the solution, but I still don't like that the player when they are using it themselves need to switch between states.
• disable the charging recipe altogether and only way to charge the tome would be to have it enabled on player and let it draining redstone/glowstone from inventory.

Now that I have written this down I may actually go with the second point as a short term solution and see if auto crafters actually start supporting what I believe they should support by default.

And just because I was curious I tried searching for the getRemainingItems method to see if perhaps someone is against using it and actually found pretty knowledgeable forge people recommending its use in some special cases.

So other mods will have an issue with auto crafters not supporting the method.

Out of a very quick search it looks like Chisels and Bits will have an issue with that, but hard to tell if that is an issue without actually trying it in game.

C&B bits bags do not have the issues with autocrafters, if you try to craft designs from a bag. So maybe talk to Algo and see if he had a solution to the issue you haven't thought of?

Alternatively charge is just 1 universal property right? why not make charge tool damage on the book instead?

Charge actually is the damage and now that I have thought of this more I realized that solutions above wouldn't work as I need the additional context of what items are being crafted to know how much charge/damage to use. I can take a look at C&B, but I don't see how it would get this context either as there's no other place where this is passed at the time of crafting.

well he's not core modding so he must of thought of something? I'm not sure. I would ask him for you but he literally jsut went to bed at the time of this comment :/

no worries, I will look at his code. I have it cloned anyway because of code examples and a bit of integration I wanted to do with void tear.

Seems odd to expect all autocrafters to handle this special circumstance. Xeno tells me its a crafting event, but its obviously not one thats expected by almost anyone considering this is /all/ auto crafters

So Algo does the same thing that I do. Only for two of the recipes, but it's the same thing - manipulate items in getRemainingItems. He does it for copying negative design to a blank negative and for applying mirror design to positive/negative. If you do these crafts in hand it works correctly, but if you do these in RFTools auto crafter you lose the original negative/mirror design.
It's caused by the same issue, just in this case it's more "subtle" as it doesn't cause dupe bug but rather causes player to lose stuff that they shouldn't lose.

I have one other thought on this and that is basically having the recipes work only for crafting inventories that are whitelisted. That way I can whitelist crafting in hand and then whatever autocrafter will actually properly call getRemainingItems. That is what I am going to try next and if that works will release a new version soon that will only allow crafting with tome in hand (or in vanilla crafting table).

gosh I'm dumb p3pp3rf1y for some reason when I checked the C&B recipes in a table I thought the destruction of the design and bag was normal (even though I know its not) so sorry!

Anyhoo, Mezz is investigating both Algos and yours with his worktable to see if he can find a solution. He figures something changed in 1.9 that flew under everyones radar.

So you were right its everyone elses problem xD <3

Looks like everyone ignored getRemainingItems during the update. It was part of the 1.7.10 -> 1.8 change for me so it was overlooked among 1000s of more obvious errors. I'll work on fixing up the Forestry Worktable.

Btw in the version I released yesterday I have a check for SlotCrafting in all Tome recipes which to my knowledge is only used in manual crafting so the recipes don't work in auto crafters as of that release. I will be adding the whitelist for crafting containers mentioned above but if you need to test this now just use previous version of Reliquary that doesn't have the check.

This has been fixed in the Forestry 5.1.10 Worktable. It does not use SlotCrafting though.

So it turned out that I am absolute derp and didn't realize that when I am referencing deobf field names in reflection that won't work in obfuscated/live environment. So I basically disabled all tome recipes with that last change even when crafted manually. Also I have figured out that I have no easy way to check for who is using the recipe (would likely require special code for every crafter) so I am not going with the whitelist idea either.

Anyway mezz has fixed the worktable and McJty did the same with crafter so I have removed the check on my side and the recipes can now be used anywhere again hopefully not producing another dupe bug in some other block anytime soon.