Logistics Pipes

Logistics Pipes

13M Downloads

Crafting with Catalysts (still) sucks

Timeslice42 opened this issue ยท 4 comments

commented

LP: 0.10.4.5

This has been an issue for at least five years now, mainly (but not exclusively) with Gregtech. The last time around the discussion ended up getting us the Crafting Cleanup module, which sort of helps, but still doesn't address the problem correctly (although #1637 exacerbates this problem greatly).

Basically, any recipe which requires ingredients which are not consumed in the crafting are not handled intelligently by the LP system. An example of this would be the majority of the default recipes in LP for pipes and modules, which need the Programmable mcguffin (aka the catalyst) to craft them. There is, however a viable workaround for this example: you just "lie" to the crafting pipe/module by removing the catalyst from the list of ingredients, and just leave one in the crafting table.

This works sufficiently for regular items, but fails for any catalyst which is damaged and eventually destroyed by the crafting OR if the recipe/catalyst needs to go into a machine. In this case the user has to baby-sit all of their affected recipes to make sure they stay stocked with the catalyst, as LP doesn't have any way to ensure that there is exactly one instance of each catalyst needed in the crafting table.

The current workaround is to put the oredict and/or ignoreNBT/ignoreDamage fuzzy flag on the catalyst (depending on context), and then put a crafting cleanup upgrade module on the crafting pipe/module. This works to an extent, but if you need to craft 50 widgets at once, it'll try and send 50 spanners into the crafting table (along with the other ingredients) when it likely only needs one for the whole batch. Not only is this a waste of the resources needed to make a spanner, but they likely won't even fit into the crafting table, causing all sorts of issues.

This issue needs more discussion, but the simplest solution I can think of is to allow fuzzy options (either via upgrade module or the built-in interface) on supplier pipes/modules. This way I can slap a supplier pipe on the fuzzy crafting table, tell it to keep 1 catalyst (marked oredict and/or ignoreNBT/ignoreDamage) stocked, and it will put whatever it can find or craft in there that fits the bill.

commented

The downside to a fuzzy supplier is that (I assume) it could get expensive figuring out if the network has the necessary item available. The alternative would be to have some way to mark an ingredient as a catalyst, but then the crafting pipe/module would have to buffer/queue/de-batch multiple recipe requests, ensuring that exactly one instance of each catalyst is in the crafting table at the beginning of each craft.

commented

LP: 0.10.4.5
This has been an issue for at least five years now, mainly (but not exclusively) with Gregtech. The last time around the discussion ended up getting us the Crafting Cleanup module, which sort of helps, but still doesn't address the problem correctly (although #1637 exacerbates this problem greatly).
Basically, any recipe which requires ingredients which are not consumed in the crafting are not handled intelligently by the LP system. An example of this would be the majority of the default recipes in LP for pipes and modules, which need the Programmable mcguffin (aka the catalyst) to craft them. There is, however a viable workaround for this example: you just "lie" to the crafting pipe/module by removing the catalyst from the list of ingredients, and just leave one in the crafting table.
This works sufficiently for regular items, but fails for any catalyst which is damaged and eventually destroyed by the crafting OR if the recipe/catalyst needs to go into a machine. In this case the user has to baby-sit all of their affected recipes to make sure they stay stocked with the catalyst, as LP doesn't have any way to ensure that there is exactly one instance of each catalyst needed in the crafting table.
The current workaround is to put the oredict and/or ignoreNBT/ignoreDamage fuzzy flag on the catalyst (depending on context), and then put a crafting cleanup upgrade module on the crafting pipe/module. This works to an extent, but if you need to craft 50 widgets at once, it'll try and send 50 spanners into the crafting table (along with the other ingredients) when it likely only needs one for the whole batch. Not only is this a waste of the resources needed to make a spanner, but they likely won't even fit into the crafting table, causing all sorts of issues.
This issue needs more discussion, but the simplest solution I can think of is to allow fuzzy options (either via upgrade module or the built-in interface) on supplier pipes/modules. This way I can slap a supplier pipe on the fuzzy crafting table, tell it to keep 1 catalyst (marked oredict and/or ignoreNBT/ignoreDamage) stocked, and it will put whatever it can find or craft in there that fits the bill.

Have you check how AE2 handle non-consume item?

I'm not using AE2 for crafting, nor could I at the time this ticket was written.

commented

LP: 0.10.4.5

This has been an issue for at least five years now, mainly (but not exclusively) with Gregtech. The last time around the discussion ended up getting us the Crafting Cleanup module, which sort of helps, but still doesn't address the problem correctly (although #1637 exacerbates this problem greatly).

Basically, any recipe which requires ingredients which are not consumed in the crafting are not handled intelligently by the LP system. An example of this would be the majority of the default recipes in LP for pipes and modules, which need the Programmable mcguffin (aka the catalyst) to craft them. There is, however a viable workaround for this example: you just "lie" to the crafting pipe/module by removing the catalyst from the list of ingredients, and just leave one in the crafting table.

This works sufficiently for regular items, but fails for any catalyst which is damaged and eventually destroyed by the crafting OR if the recipe/catalyst needs to go into a machine. In this case the user has to baby-sit all of their affected recipes to make sure they stay stocked with the catalyst, as LP doesn't have any way to ensure that there is exactly one instance of each catalyst needed in the crafting table.

The current workaround is to put the oredict and/or ignoreNBT/ignoreDamage fuzzy flag on the catalyst (depending on context), and then put a crafting cleanup upgrade module on the crafting pipe/module. This works to an extent, but if you need to craft 50 widgets at once, it'll try and send 50 spanners into the crafting table (along with the other ingredients) when it likely only needs one for the whole batch. Not only is this a waste of the resources needed to make a spanner, but they likely won't even fit into the crafting table, causing all sorts of issues.

This issue needs more discussion, but the simplest solution I can think of is to allow fuzzy options (either via upgrade module or the built-in interface) on supplier pipes/modules. This way I can slap a supplier pipe on the fuzzy crafting table, tell it to keep 1 catalyst (marked oredict and/or ignoreNBT/ignoreDamage) stocked, and it will put whatever it can find or craft in there that fits the bill.

Have you check how AE2 handle non-consume item?

commented

hi, the supplier pipe ignores damage by default and can be used with damageable items that do not switch NBTs. Otherwise the setup is equivalent (and intended so!) to the programmer: setup crafting table with recipe, add crafting pipe, import recipe, remove persistent item from crafting pipe. I will add "Fuzzy Upgrade for supplier pipe/module" onto the list of feature requests: https://github.com/RS485/LogisticsPipes/wiki/Feature-Requests