Issue description:

With Refined Storage's feature consolidation in 1.6, I would like to request some more tools for the player to be able to build complex systems upon.

The current redstone controls for crafters are fairly limited. A relatively small set of enhancements could provide a rich foundation for the player to build upon for processing patterns.

What happens:

Redstone control on the Crafter causes the crafter to remove its patterns from the network. An attempt by a player to regulate crafting via redstone control is somewhat disruptive to in-flight crafting jobs. It doesn't seem usable for that purpose.

What you expected to happen:

I would like more choices than Require redstone/Require no-redstone/Ignore redstone:

1. Redstone signal enables crafting
2. Redstone signal disables crafting
3. Wait for Redstone pulse after each craft

This would enable the player to design their own replacement for blocking patterns based entirely on the contraption they are interacting with. These redstone modes would not remove the pattern from the autocrafting system, but would rather delay scheduling of new processing jobs, just as though the machine the crafter was pushing to was busy or its inputs were full.

The first two are easy to explain and document, but the third is the one I'd find most useful. In that mode I'd be looking for a one-shot mode with an edge triggered reset. eg: for a contraption makes a redstone pulse at the end of it's craft (think Botania Altar), which would unblock the crafter after each craft.

This would provide a foundation for more interesting game-play options for the player, ranging from signal blocks with filters and inventory sensors through interacting with machines that give a redstone status. Or as simple as a comparator on a chest as a simplistic blocking mode implementation.

This would give the player a lot of options without a heavy impact on the autocrafting code. As far as autocrafting was concerned, it could just be another 'machine is busy' state.

What I'm worried about is that "redstone signal enables/disables crafting" sounds very confusing.

Players will enable it and think that an autocrafting task will be scheduled even though it just "enables" the patterns.

(Will especially cause confusion since 1.10.2 had an option "schedule task on redstone signal")

I struggled with the wording. I agree that it is very important that the description is clear and unambiguous. People will find a way to misinterpret it somehow.

I wanted to suggest wording more like "Redstone signal blocks crafting", "Redstone signal unblocks crafting", and "Block after each craft until redstone signal", but I was afraid to use the word "Block".

Rather than enable/disable or block, you could use pause & resume? They're pretty unambiguous for what it is doing.

Unsure what wording you would use for the 'Pulsed' crafting.
Maybe you have one option for 'Toggle pause/resume on redstone pulse', and a second option for 'Toggle pause/resume after each craft'.
Those 2 combined would result in what @DarkHelmet433 wanted, while giving flexibility.

It just might be a bit overwhelming having 3 options for all of this!

The problem I'm trying to solve with pulse mode is to handle propagation delays and timing with redstone. It's why ExtraUtils has pulse mode in various machines.

For example, suppose you're trying to implement AE2 style inventory-blocking with a comparator on a chest. A simple pause/resume is vulnerable to RS being too fast for the redstone feedback to work and guarantee that just one craft happens with the quirks of redstone. You need some sort of edge triggering or pulse mode for that to work.

Another example, suppose you're trying to automate a Botania Altar where you are literally using a block to drop items into the world. The altar gives you a redstone signal for its states - idle, crafting, complete. In AE2 systems I've seen some amazingly complicated and fragile systems with signal blocks and where timing is critical because inventory blocking is the only tool they have available. Hence trying to find a workable idea to the player directly control the sequencing of processing crafting.

Perhaps the complexity belongs in an Advanced Crafter in the addons mod? Then leaving the base RS with the essentials and move things like inventory-push-blocking, pull crafters, advanced redstone control, etc out of harm's way.

Speaking of which, pull crafters (for want of a better name) might be a more elegant way of approaching this - make them appear like an Interface. A processing pattern pushes to the internal 9 inventory slots. It's up to you to pipe them out and distribute them. When you've emptied the slots, the next craft can happen. Processing patterns have 9 slots and an internal Interface-like 9 slot inventory solves having to poll an external inventory for being empty. Cancelling the craft from the crafting monitor can retrieve the items from the output buffer. Again, this is something that could fit better in the Addons mod.

I think these different modes make sense and would be helpful, although I’ll say these could all be collapsed down into the “redstone signal enables crafting” mode.

A signal inverter (typically just a torch and repeater) can handle your second mode and a t-flip-flop (I think) can handle the third.

The key though is the autocrafter not inserting items into an inventory until it receives the signal.

Really though, if you think about it, the redstone signal is detecting the completion of a craft, right? When a craft completes, RS already knows about it (via an item coming into the network), otherwise it wouldn’t be able to continue the crafting chain.

I think a more elegant solution would be a “speed downgrade”; where an autocrafter wouldn’t insert items into an inventory while that same autocrafter is waiting for a craft to complete. This could be an option in the UI, an actual item you put in an upgrade slot or an “advanced crafter” in RS addons as you suggested.

This avoids some of the complexity of the old blocking mode (which was pattern based).

The new dev build on Jenkins (for 1.6.6) adds this feature! Please try it out.