Page 1 of 1

odd behaviouir of crusher recipe selection

Posted: Sun Nov 17, 2024 8:03 pm
by Rauschkind
so, i have a crusher that gets its recipe by combinators.
no combinator is signaling "metallic asteroid cruishing".
yet, i see the crusher selecting this recipe frequently, it seems to default to this recipe when it has no recipe for a tick before selecting "no recipe" (as it should).
this is very annoying because it then will stick to the recipe untill it has depleted its storage.

i simply cant make sense of it. any advise how to make this machine behavie was greatly appriciated.

Re: odd behaviouir of crusher recipe selection

Posted: Sun Nov 17, 2024 8:24 pm
by jdrexler75
Show your setup.

The crusher will select metallic crushing if you have "set recipe" enabled and it receives a metallic chunk signal. It doesn't need the specific recipe signal. This makes it easier to use deciders operating on metallic chunks (or the other resources) to set the recipe without needing a recipe translation.

That also means you can't both have "read contents" and "set recipe" at the same time, because its contents will send the signal for the recipe.

(This is a problem with all machines, not just the crusher, and I wish we could separate both functions to separate wires somehow.)

Re: odd behaviouir of crusher recipe selection

Posted: Sun Nov 17, 2024 8:24 pm
by LCStark
It's difficult to say anything about it without seeing your setup. I've never had this weird behaviour occur on crushers. Most probable answer would be that you've got a signal contamination somewhere.

Re: odd behaviouir of crusher recipe selection

Posted: Sun Nov 17, 2024 8:27 pm
by Rauschkind
jdrexler75 wrote: Sun Nov 17, 2024 8:24 pm

The crusher will select metallic crushing if you have "set recipe" enabled and it receives a metallic chunk signal.
really. of course it gets a metallic chunk singal. i use that signal to control other stuff.
i want to control my crusher. i want to use the reciepe signal to control the reicpe.

this just seems so dumb. why??

Re: odd behaviouir of crusher recipe selection

Posted: Sun Nov 17, 2024 8:47 pm
by Rauschkind
LCStark wrote: Sun Nov 17, 2024 8:24 pm It's difficult to say anything about it without seeing your setup. I've never had this weird behaviour occur on crushers. Most probable answer would be that you've got a signal contamination somewhere.
i did not post a screenshot because its would show 16 deciders + 1 constant combinator, and i felt making sense of it was to much to ask from random strangers on the internet XD

Re: odd behaviouir of crusher recipe selection

Posted: Sun Nov 17, 2024 11:28 pm
by jdrexler75
Rauschkind wrote: Sun Nov 17, 2024 8:27 pm this just seems so dumb. why??
I explained why in my post. It's extremely useful for simple setups with deciders. Most machines are like this. I would've been upset if it hadn't worked this way! But you can make a suggestion thread about making this configurable if you like.

Or do it like this, using this design I can set the crusher recipe to ice/carbon/iron ore depending on which inventory is low, with ice having higher priority over carbon over iron ore, with just one constant box and one decider to handle all recipes. (Didn't get to asteroid reprocessing yet, that will probably go in a different crusher.)
Screenshot_20241118_005442e.png
Screenshot_20241118_005442e.png (289.41 KiB) Viewed 580 times


Just connect the constant box to the green input, and the inventory to red (in my case the hub but a belt system will also work).

It works the following:
  • If the "each" signal is the ice signal (i.e. matches the green ice input), and ice is low, make more ice
  • If the "each" signal is carbon, and ice is OK but carbon is low, make carbon
  • If the "each" signal is iron ore, and both ice and carbon are OK but iron ore is low, make iron ore
If I had to translate the "each" signal to its corresponding recipe, that would be extremely irritating!

Re: odd behaviouir of crusher recipe selection

Posted: Mon Nov 18, 2024 6:04 am
by Rauschkind
jdrexler75 wrote: Sun Nov 17, 2024 11:28 pm xplained why in my post. It's extremely useful for simple setups with deciders
yeah. and it extremly can break a setup where this is not the intended function and it cant not be controlled.
at least put in a checkbox if ingredients should set the recipe.

Re: odd behaviouir of crusher recipe selection

Posted: Thu Nov 28, 2024 8:58 am
by Boske
I came here from google because i tried setting the crusher recipe while also reading the contents.
This does not work as I would expect with the current behavior

I want to set the reprocessing recipe based on how many asteroid chunks are available for each type but this was flickering because the "available" amount went down when the chunks were picked up from the belt and put into the crusher.
So I tried reading the crushers contents and add it to the belt contents, but this ended up setting the recipe for regular crushing once no reprocessing recipes was set anymore.

I don't think it makes sense to set the recipe from a signal for the regular chunks.
For other items, it is set by the endproduct and the chunks are not the endproduct.
Perhaps it could make sense to set it from eg iron ore for regular metallic crushing and copper ore for advanced metallic crushing but i think i would prefer setting the recipe explicitly for crushers.

Re: odd behaviouir of crusher recipe selection

Posted: Thu Nov 28, 2024 4:51 pm
by jdrexler75
Boske wrote: Thu Nov 28, 2024 8:58 am I want to set the reprocessing recipe based on how many asteroid chunks are available for each type but this was flickering because the "available" amount went down when the chunks were picked up from the belt and put into the crusher.
The flickering is inevitable at some point. For me it was sufficient to read the inserter putting chunks in the crusher, because then when the signal "stops", it takes a cycle for the decider to update and so the crusher is already working when the signal changes, and finishes what it started.

If you could read the contents, it will work the same but maybe it'll be a little less surprising "why" it works.
I don't think it makes sense to set the recipe from a signal for the regular chunks.
For other items, it is set by the endproduct and the chunks are not the endproduct.
Perhaps it could make sense to set it from eg iron ore for regular metallic crushing and copper ore for advanced metallic crushing but i think i would prefer setting the recipe explicitly for crushers.
Well at the very least from the tooltip it's the general and intended approach, and it's easy enough to work with when you know how. Though perhaps they should make "read contents" and "set recipe" mutually exclusive like for other entities such as chests with "set requests", to make this less surprising.
Screenshot_20241128_173449c.png
Screenshot_20241128_173449c.png (30.41 KiB) Viewed 297 times

Re: odd behaviouir of crusher recipe selection

Posted: Sat Nov 30, 2024 6:46 pm
by Ext3h
Just use a constant combinator to output an -1k offset for all the input and output materials that could occur as ingredients / products of a recipe.

Now you can safely read the contents AND set the recipe via a dedicated recipe signal. (Or just force +1001 for the material if there isn't a dedicated recipe signal.)

Machines won't set their recipe from negative signals, but you can still carry your own information in there.