Thanks, that looks much better.

The paragraph feels like some combination of overly vague and outdated/wrong. At least the context makes it clear what "restrictive dependencies" are supposed to be: The official documentation calls them "incompatibilities"; "conflicts" is another common name.

Why use any dynamic elements at all? Wouldn't some static explanation, hidden behind the blue (i) thingy, be sufficient? "When targeting a belt, if the inserters configured stack size is larger than the belts stack size, the inserters stack size is rounded down to whole belt stacks."

What are these "restrictive dependencies" supposed to be?
Something you declare in info.json? Non-optional dependencies could be considered a form of restriction, but why create a specific term for that?
Or something related to prototypes, entities, etc.? The modding API has a few hits each for ...

How would a platform specify that it wants to receive "trash," and how would it specify that it only wants a certain amount of "trash"? Would this be accessible to the circuit network?

It wouldn't. Requests should be specified by the already existing mechanics, which includes the circuit network ...

My 2 cents: If there are items in the trash slots, they need to go away ASAP. But I don't see anything wrong with using them to fulfill requests, before dumping any remainder into the big storage chest called planet.

For configuring a hub to act like e.g. a buffer chest, introducing a drop-down ...

Doesn't the spidertron cycle through its ammo slots while shooting? Having mixed ammo types sounds like you're setting yourself up for an rather unwelcome surprise, especially with atomic bombs in the mix.

According to 123899, in particular this post, this seems to be intentional.

The train is considered at the stop until it leaves the rail block

or stops at another train stop, but passing a waypoint isn't stopping.
You can either
- put the stations far enough apart that the train has left the "Drop" station's block by the time the breaking point reaches the "Depart ...

In the info pane, select "space age mod" (directly below the image), and the bulk inserter will show up as expected.

Because at some point you're done loading up and want to deliver those items.
"Any request not satisfied" doesn't help you with that.


It's the negation of "All requests satisfied"; you might need negations sometimes to transform your wait conditions into disjunctive normal form (which is the ...

- the naming of the condition is terrible if it the behavior is intentional

Clarifying that "All requests satisfied" and "Any request not satisfied" are about importing items from the current location would certainly help.


- there are no dedicated conditions for checking unsatisfied planet ...

Looks like it tied to an order in which game engine computes circuit network values.


The key part is hidden in there: The game works in "updates" or '"ticks" during which everything gets updated once. For circuits this means all combinators update simultaneously and other combinators will only ...

Yes, any random result where the number of possible outcomes is a power of 2 with even odds works best.
Technically, any random result helps, but then you'll have to deal with partial bits, and, in case of uneven odds, getting different amount of information depending on the result.

No, this would reduce the whole belt to effectively have only one circuit connection point (since they'd all be implicitly connected).
Having multiple connections is occasionally useful, e.g. using hold(all) for controlling the contents of a sushi belt while using hold(single) to configure filters ...

The issue with your suggestion is that you're applying the same multiplier to all qualities, possibly excluding normal. That means their relative value to each other remains constant. Yes, the absolute value for legendary increases faster, but one legendary will still have the same science output of ...

How do I pass the priority order through to a selector combinator, but only of the items that are low?

Split it into smaller tasks you can manage individually.
First, figure out which items are low, which you've already solved.
Second, filter the list of priorities with the output from step one ...

Roboboy wrote: Fri Jul 03, 2026 9:20 pm this could be avoided if the input and the output signal could be controlled

I can see you're playing on version 2.1, which added color selection for circuit in- and output wires. You should take a closer look at your assemblers circuit control settings or read FFF 443.

It is also possible to use 'Set requests' at the same time as 'Read contents'

Yay?

…, due to a little bit of magic self-subtraction of the circuit network signals.

Oh. Did the attempt to add a wire selection for most/all circuit control options not work out, or are you hiding that for a later FFF?

However, the asteroid processing recipe duplicates itself, so sometimes during normal production, no item count decreases either.

You could arrange for an inserter that prioritizes removing the output asteroids. As long as the inserter either removes an asteroid or becomes/stays idle before the ...