Pattern cycle issues
Blueflamefirez opened this issue · 20 comments
Describe the bug
Hello,
i'm playing on ATM10, however this issue is not specific to that modpack.
A pattern cycle occurs when creating a pattern for iron dust -> iron ingot in a smelter,
and a pattern for iron ingot -> iron dust in a mekanism crusher.
I believe since RS handles processing patterns as the same (categorically) it sees the two patterns as the same in terms of processing, hence the cycle. However, in reality, the processing happens in two different machines, one smelts and one crushes. Thus logically, a pattern cycle should not occur.
A more complex example of this would be in AE2 certus crystals -> charged crystals and charged crystals -> certus crystals.
I recommend finding a way to differentiate between machine output types, such as smelters, crushers, etc. Since JEI is able to pick up on this in the crafting recipe view, i presume the metadata is there? I might be completely wrong.
I would love for a fix for this as it would make autocrafting much more straightforward!
Thank you.
How can we reproduce this bug or crash?
- Mekanism/ (or any processing mod) as a base mod
- create a pattern for dust -> ingot and ingot -> dust
What Minecraft version is this happening on?
Minecraft 1.21.1
What NeoForge or Fabric version is this happening on?
21.1.194
What Refined Storage version is this happening on?
2.0.0-beta 3
Relevant log output
So how will that prevent the autocrafting algorithm from trying to make one from the other until the end of time?
I'm sorry, i didn't understand what you mean. Why would that be a problem? You select what you want to autocraft from the crafting grid, so why would it continue to autocraft to the end of time? And if you're talking about the autocrafting upgrade, wouldn't a regulator or interface be enough?
Okay, you're being close minded now and to be honest just incompetent
I'm not a dev lol i'm just some guy who thinks you're wrong and has nothing better to do than tell you
it's clearly easy to see that somehow, these false cylic patterns must not exist.
They are not "false" cycles. As I keep trying to explain, they are cycles. Even if RS did care about the machine for some reason, they would still be cycles. Can you explain, in detail, exactly how "dust requires crushing iron which requires smelting dust" is different from "dust requires iron which requires dust", in a way that will stop it from looping?
Ah okay that explains things, well if you're not a developer than i don't understand how you can state that i'm wrong? Is it because you feel like you're right or is there some underlying technical knowledge that you have that you're not sharing?
Anyway, let me break it down logically to you so you can understand. This is how i think and suggest the developers design RS in the future.
From a mathematical perspective, we're dealing with two distinct processing domains or spaces, let's call them Space A and Space B. These domains are defined by the type of processing involved:
Space A corresponds to smelting. Any recipe that involves smelting like turning iron dust into iron ingots belongs exclusively to this space.
Space B corresponds to crushing. Recipes like converting iron ingots back into iron dust fall into this separate space.
Even though the transformations between these two materials are reversible and appear equivalent in terms of resource exchange, they occur in fundamentally disjointed contexts. Each space operates independently, governed by its own machine and processing logic.
Therefore, from a systems perspective, these should not be considered part of a cyclic dependency. A true cycle would require the operations to exist within the same logical space, but here, they are isolated by their processing type. Treating them as a loop is a misclassification it's not a literal loop, it's two separate reversible processes that happen in different domains.
This is a simplified version without any mathematical notations, feel free to ask any questions.
So how will that prevent the autocrafting algorithm from trying to make one from the other until the end of time?
The crafting algorithm is what determines how everything can be made, using what, how much of that you have, and how much you need, and what you are missing, before telling you in the crafting preview window. How do you imagine it works?
As a suggestion; maybe add a linking device to link autocrafters with the corrosponding machine, thus an autocraft for a smelter would recognize that any patterns in there are for smelting, and the crusher autocrafter would understand that any patterns linked to that are for crushing
Pattern cycle comes from RS trying to make iron ingots from dust, which it can make from ingots which comes from dust and so on. Thus the cycle. There isn't really a good way to solve this, the best way is to stock one of the things always,and make the other as needed: if you have iron farm which makes dust, convert it to ingots for storage and make into dust as needed.
Refined Storage doesn't associate patterns with machines by design.
I understand the design principle, but then this should be an enhancement addition. It doesn't make sense from a player standpoint that these two patterns are incompatible even though from a code perspective it does, i suggest looking into a way to make this incompatibility work
I don't entirely understand what problem you are having, and if I understand correctly, which is you want to be able to craft dust from iron as well as iron from dust on demand, how does linking machines to patterns going to solve that?
Autocrafting fails when these two patterns are together in the autocrafting system, even though they operate in different machines:
Pattern 1: Smelting dust → ingot (e.g., using a furnace)
Pattern 2: Crushing ingot → dust (e.g., using a crusher)
Despite these being distinct processes handled by different machines, RS treats both as generic "processing patterns" without recognizing the machine specific context. As a result, it falsely detects a cyclic dependency, and assuming you're trying to convert dust to ingots and back again in a loop when in reality you're just enabling two separate conversions.
This issue also affects other recipes:
Certus Quartz Crystal ↔ Charged Certus Quartz Crystal, attempting to automate both directions leads to another false cycle, even though the charged version requires Certus Dust to revert to the normal certus crystal.
Why i suggested linking autocrafters directly to specific machines is because it would allow each autocrafter to understand the type of processing it’s associated with; smelting, crushing, enriching, etc. and treat patterns accordingly. This approach would allow RS to differentiate between processing types, mitigating false cycle detection. It also allows us to avoid the need to define separate processing categories during pattern creation to keep the player experience streamlined
Of course, this is just one idea, there may be better architectural solutions, and I leave that up to you guys to explore what fits best with RS’s design philosophy. But from a player’s standpoint, enabling machine-aware pattern handling would be a huge quality-of-life improvement.
As an example, here is an image of a setup i have:
As you can see, each autocrafter corrosponds with one machine as it streamlines the processing process. If i could link each one of those crafters to it's corrosponding machine then there would be no false cyclic patterns.
That is a cycle though
a->b->a is a cycle, regardless of what type of pattern you use. Even a recipe like "craft blocks into ingots and ingots into blocks" doesn't work. The machines do not matter. If rs knew they were different machines, it would not matter. What matters is that you have one pattern to turn dust into ingots, and another to turn ingots into dust, and you can't have both of those, you have to pick one.
That is a cycle though
a->b->a is a cycle, regardless of what type of pattern you use. Even a recipe like "craft blocks into ingots and ingots into blocks" doesn't work. The machines do not matter. If rs knew they were different machines, it would not matter. What matters is that you have one pattern to turn dust into ingots, and another to turn ingots into dust, and you can't have both of those, you have to pick one.
What you described is indeed a true cyclic pattern, and RS is correct to flag it as such. Your example of blocks ↔ ingots is a classic crafting loop, and since both conversions happen within the same crafting context (i.e, the crafting table/ pattern), it makes sense that RS identifies it as a cycle.
However, the case I presented is fundamentally different. It involves two distinct machines performing two distinct types of processing: a smelter for turning dust into ingots, and a crusher for turning ingots back into dust. These are not interchangeable crafting operations, they're separate processes with different contexts.
The issue arises because RS treats all processing patterns as equivalent, regardless of the machine involved. From a player’s perspective, this can be misleading, since it doesn't make sense that two different types of processes create a cycle. You're not using the same machine to go back and forth; you're using a smelter for one direction and a crusher for the other. That distinction should matter.
No, it should not. How does RS make ingots? With dust. How does it make dust? With ingots. The machine does not matter. If RS tries to calculate an autocrafting recipe where it needs to make ingots, the first thing it checks will be dust, then to make that dust it will check ingots, then to make those ingots will check dust, etc, creating a loop, which then breaks it. The fact that they use different machines is irrelevant to whether it's a loop. It doesn't matter if the dust goes into a furnace or if it goes into a cannon that kills iron golems. It doesn't matter if you think of it as a loop. It is a loop and so RS cannot support it.
Okay, you're being close minded now and to be honest just incompetent, doesn't matter if it does or doesn't support this currently. What matters is that this is an obvious improvement to make as it a shortcoming of the autocrafting system, clear as day, no buts or ifs.
If RS tries to calculate an autocrafting recipe where it needs to make ingots, the first thing it checks will be dust, then to make that dust it will check ingots, then to make those ingots will check dust, etc, creating a loop,
Yes exactly the issue, it should check for processing type so it's not all generic processing patterns, why it doesn't do this now is beyond me and is why i'm bringing it up, it's clearly easy to see that somehow, these false cylic patterns must not exist.
No, it should not. How does RS make ingots? With dust. How does it make dust? With ingots. The machine does not matter. If RS tries to calculate an autocrafting recipe where it needs to make ingots, the first thing it checks will be dust, then to make that dust it will check ingots, then to make those ingots will check dust, etc, creating a loop, which then breaks it. The fact that they use different machines is irrelevant to whether it's a loop. It doesn't matter if the dust goes into a furnace or if it goes into a cannon that kills iron golems. It doesn't matter if you think of it as a loop. It is a loop and so RS cannot support it.
This might be a shot in the dark, and please do correct me if i'm wrong as i'm quite interested, but i believe the algorithm uses recursion with a timeout, which would make sense because for more complex recipes, it timesout if takes longer than (5 sec?) to calculate all that you need. Btw, i think that timeout should be increased, since recipes from mods like extra disks which require all previous tiers often times than not timeout before calculating everything. Anyways, that was a tangent.
Let's assume we have a recipe that needs iron ingots, well first the algorithm should calculate how many iron ingots you have, followed by how many more iron ingots you need. Now let's assume you have pattern for iron dust -> iron ingots, well now it should calculate how many of that dust you need to smelt to get ingots.
Now the risk here, and i think that's what you're hinting at, is that there is a possibility that we don't have enough iron dust to smelt for iron ingets, so naturally, as things are right now, it would go to the next pattern which is to crush iron ingots -> iron dust, thus creating a cycle.
However, this can be circumvented by "locking" the amount of iron ingots available.
- let's assume you have 10 iron ingots and you need 20 iron ingots in total.
- You have 5 iron dust ready to smelt, this in total leaves you with a theoretical 15 iron ingots.
- Now assuming you locked the amount of "readily available" resources, that's to say the 10 iron ingots and 5 dust
- The algorithm would throw out an error saying not enough resources instead of a cycle error, since the items are locked and not available for use for any processing/ crafting.
Of course this is probably not the best/ nor an optimal solution since i have no idea what the underlying code looks like. I'd love to discuss this further as i'm actually interested in how the algorithm works.
One other possible way is to set priority per pattern for the same item, so let's say i have 3 patterns for processing iron ingots.
- Dust -> ingot
- Block -> ingot
- Ore -> ingot
i could set a priority for each one of those and it would start with the highest priority all the way to the lowest.
Anyhow, i'd love to hear your thoughts.
What happens if you have a recipe like 1 ingot into 2 dust, 1 dust into 1 ingot? Then there's no "amount available"
This is what might happen if you have a recipe like 1 seed into 3 wheat, 1 wheat into 1 seed
I'm not getting entirely what you mean, but that would open up a whole lot of other issues unrelated to RS, for example, infinite resource generation