hey

as I mentioned in #62 there is a behavior I didn't expect. I guess it could be a bug in some way.

I'll use the mod Reliquary as an example. It does add multiple belts, so called mob charms that do affect the corresponding mobs behavior around the player. There's a charm per vanilla mob and an additional charm that can store multiple mob charms because otherwise you can't wear more than one belt in your bauble-slots.
Every charm uses charm fragments (creeper charm needs creeper charm fragments, skeleton charm needs skeleton charm fragments and so on) with the additional charm being an exception: it needs any charm fragments completely independent from what charm those fragments actually are for.
After I added every recipe the calculator wants me to use wither skeleton charm fragments for the additional belt because their recipe was the last charm fragment-recipe I saved. But since those fragments require wither skeleton skulls I would prefer almost every other fragment...
Another example are the potions. I added recipes for 1 awkward potion, 3 and 2 (in that order), so whatever I want to brew it just uses the recipe for 2 potions - the one saved last.

For the potions the solution is simple: use the one that's closest to the set output. If I want to craft 5 Awkward Potions the ingredients are 5 water bottles and 2 Nether Warts - the recipe for 3 plus the recipe for 2 potions.
For the Charms it get's way more complex. Maybe for such oredict-entries in recipes you could add an additional request to ask the user to choose an item as soon as there are multiple matching recipes available.
maybe you could add an availability-counter in some way, effectively letting the player define a ranking which item is prefered but that coule become rather complex and annoying to keep up to date.
And maybe you can think of another even better solution that's easier to implement - I don't know how simple or complex the code currently is or would become by these ideas...

For the potion recipes I've already explained it in #62. For oredict-related recipes, it should already have full support for oredict labels in recent versions. Which version are you current playing?

3.2.2 (should be the newest curseforge-version for MC 1.12.2)

The problem isn't the oredict support, that part works. the problem is that it solves the oredict-label with the newest fitting recipe which is a problem because there are much cheaper options stored in orlder recipes. For "skeleton charm fragment" for example I need skeleton skulls and regular bones but because I saved the "wither skeleton charm fragment" later it prefers to show wither skeleton skulls and wither bones as ingredients for that oredict-label.
Of course I could just delete an older charm fragment-recipe and re-add it to have a cheaper version chosen automatically. But in the long run I'd have to check all stored recipes for such conflicts whenever I add a recipe that contains oredict labels.

This might be a personal problem because I played a few days and made some progress before even installing your calculator instead of using the calculator from the beginning and adding only what I needed at that time. On the other hand there might be reasons to prefer an older recipe. For example: I'm on a longer exploration and don't have my sawmill with me but plenty of trees around me. Why would I care that I could get 6 planks from the sawmill while I want to know how many trees to chop for a boat?

Ok, it makes sense to me. For the charm issue, a very straight-forward solution is to manually edit the recipe to use certain type of fragment that you want. The system picks oredict label for you, but you still have full control of how the recipes is.

Another solution is more complex but systematic. The calculation engine picks recipe first following the alphabetic order of group names, then follow the time order. So you can create one group with a high priority name like "!Prioritized", then temporarily move recipes that you want to that group, so they will always be used first if possible.

I don't think letting the user to pick recipe manually when there are multiple-match recipes is a realistic solution. When there are many cascading recipes with multiple matches, choosing recipes manually could be very annoying. So I think it's better to stick to passive ordering solutions. The current system already defines an explicit order of recipes. Recipes in the same group now follows the order of addition, but it can be any order in low level implementation. If you want, I can add some interactions to let the user sort recipes in the same group, providing full control of ordering. But for now using the two methods described previously seem good enough to me.

One big issue now is I'm getting many complaints about confusing buttons. So I need to be careful when adding more features. Let me know how do you think.

The information about group names might be the solution in this case. So it checks the whole group before checking the next in alphabetical order? In that case my solution would be to split the group in "common-reliquary", containing overworld drops, and "rare-reliquary", containing nether drops, because c has a higher "priority" than r.
That's an information worth to be mentioned somewhere...

It should solve your problem if you think it's acceptable. This order should be mentioned in the document, but since it's quite advanced feature, it might not be easy to find. To be honest, the document is a little too long, but I'm trying to make it short.

I'm closing this issue since there seems nothing else I can do to help.