Currently Problamtic Setup
When making an asteriod crusher recycling design, I came to this weird problem that instead of setting the recipe to reprocessing, it sets the recipe to crushing.- 2025-05-16_16-07-52.png (2.89 MiB) Viewed 691 times
It happens randomly, more tiled machines are stuck faster, however I didn't observe it happen when I only use top row of machines (It might just because of luck).
Analyse
First I'll explain what these circuits does:1. Constant combinator are coded recipes (see here for a introduction of recipe selector.)
2. Decider combinator near constant combinator is recipe selector that selects an recipe when machine and inserter is empty (condition 1 in "AND" group, condition 2 is recipe code, condition 3 is found ingredient).
3. The other decider combinator is a register that locks recipe when machine or inserter is not empty.
I've noticed a place where things could go wrong:
When the crusher has no more ingredients, and output inserters are taking out outputs, at that tick register decider combinator loses any "stock" input signal, at the same time input inserter picked up a new ingredient. The next tick recipe selector decider combinator has no output because the inserter has item in it, the register decider loses recipe signal and the machine is set recipe by inserter item.
This setup don't always have a recipe selected from decider combinator, giving a chance for inserter 1 tick pick chance to set a crushing recipe. The setup in original post always have a recipe signal, so it won't accept any item signal as recipe.
Here is a tick by tick video I accidentally captured (after going tick by tick for 14 hours? accident?) I roughly think that add a constant recipe signal (with lowest priority) can brute force solve this problem, but I don't like this. Any ideas?
(Tried to brute force add a constant recipe signal, it's not easy and are beyond my size limit of this design)
Further Improvements
I have some other problem wants to get improvement.1. Check if there is any other problem that may break this design?
2. A more graceful way to handle that 1tick window instead of constant recipe signal?
3. In this design, the recipe code constant are hooked to a combinator that I can't find a way to just use one wire, but two wires. So I have to seperate each recipe code constant for each tiled machine. Can I optimize the wiring to let them use the same combinator to share the constant without interference? (I think adding a diode is not worth it. It's bigger and consume power.)
Edit: I actually solved this specfic quirk and even saved one more wire color, I'll explain what happend when I have time to.
Edit 2: Finally I made this working version which satisfies my requirements. It still has a lot room for improvement, but it's working well now.
I "abused" recipe selector decider combinator to save one wire color on crusher, and added a blocking signal with the extra wire color. Thankfully all crusher can share this constant signal.
I intuitively feels that I can even let recipe selector decider combinator share recipe code constant signal using a similiar method, but I will leave it for now. (Sketch idea: use register decider combinator to double as a encoder to encode items from conveyer to other differentiable signals than working items(items inside machine & inserter), so that recipe selector decider combinator can use one wire color to take conveyer item and working item. Then I can use another color to share recipe code.)
Original Post
The below blueprint has a mistake, and the analyse based on this blueprint is not the real reason. However this behavior do exist randomly, I'm doing more investage.Blueprints first:
Working:
Not Working:
When making an asteriod crusher recycling design, I came to this weird problem that instead of setting the recipe to reprocessing, it sets the recipe to crushing. The idea that came to me first is the execution order of circuitry, so I flipped wire color and it worked.
As long as the behaviour stays consistent with specific wire, I'm fine with it. I understand this kind of execution order effect is reasonable about programming, but I think it's worth pointing this out.
Below are some explanation and analyse:
- 2025-05-16_11-08-20.png (996.87 KiB) Viewed 777 times
- 2025-05-16_11-08-36.png (956.08 KiB) Viewed 777 times
2. If there is nothing inside machine and inserter, change recipe, otherwise, use a register to lock recipe.
3. When the ingredient of that recipe is in front of the inserter, these happens:
Tick 1 - selector combinator changed to this recipe
Tick 2 - decider combinator A changed it's output to this recipe
Tick 3 - machine sets this recipe
Tick 4~k - the inserter grabs the item(takes different time due to coveyer-inserter interaction, assume ends at tick 7)
Tick 7 - decider combinator B now have to inputs: the recipe and the ingredient
Tick 8 - This is where discrepancy happens: in the not working version decider A disabled its output because its requirement are not met, and decider B loses recipe input, machine is set to make ingredient(crushing recipe); in the working version decider B's requirement are satisfied so it stores the recipe signal, the decider A also loses its output, but the recipe is locked.
Another note about this design: machine set recipe prefers recipe signal, so if both an item and a recipe signal exists, they always pick recipe signal's reciple.
Side note: I actually found this problem when improving this design, the better designs still need some polishing(most of the time was spent on this problem).
