Describe the Suggestion

It would be neat to see config options (server-side) that do the following (so people can choose which system they want to use):

1. Stop belts entirely when an item on it is being processed. This would break contraptions a fair bit, but would make more visual sense, and the stopping of connected shafts could be used to time things in assembly lines in interesting ways.

2. Not automatically stop items when getting processed on belts. This means that you would need to slow/stop belts when using things like presses or deployers so they don't "miss" the item, or so items don't pop off onto depots/basins if something is already in the depot getting processed.

Of course these would both default to off, leaving the current behaviour, since I understand why it is the way it is from both a development and gameplay perspective.

Screenshots and Videos

No response

Additional Context

Something that's always bothered me is that when items are on a belt and stop to get processed, the belts under them keep moving despite that not really making much sense. I was thinking about how it's also somewhat inconsistent, with many processors stopping items from progressing along belts, while fans specifically don't. I know this is for balance reasons as making fan-based systems that easy would negate the usefulness of furnaces entirely. But having these options could be neat for playthroughs where you need different mechanical considerations.

I get Suggestion 1 can already be done with detection systems but it's expensive to build such things into every belt if you want visual consistency and realism. Suggestion 2 is even more realistic, but also a lot harder on the player. But I think it would be an interesting sort of "hardcore engineering" mode, to make it so you need to take timing into account on all processing steps on a belt, or at least use detection systems to manually stop things. It would be a cool challenge. Hence why they would both be disabled by default.

I get it would be a lot of work for something most people wouldn't even use, but I figured I'd ask anyway!

1. makes no sense, as belts (as well as any other part of the factory) do not "stop" for anything. the only thing that happens is when a process is occurring the itemstack will wait for the animation to finish before spitting out the result, which continues along it's merry way as the rest of the stack stays behind to be processed. if there are items "in the queue" waiting behind on the belt, they wait their turn like any other interaction where there is traffic. at no point does a belt "stop". to do so would stop the entire factory like being overstressed. so too would the processor stop like the metal press or whatever else if they were on the same network.

2. sounds boring and uninteresting, why make it so every single interaction needs such micromanagement or filtered stops? fans are the way they are because it is a progress-bar-furnace-replacement which deliberately takes x time, affects multiple and variable blocks of space, and can be stacked to reduce that time; it wouldn't work to stop the itemstack nearly as sensibly... let alone the fact you are pushing air at the items so it makes no sense to freeze them in place

1. makes no sense, as belts (as well as any other part of the factory) do not "stop" for anything. the only thing that happens is when a process is occurring the itemstack will wait for the animation to finish before spitting out the result, which continues along it's merry way as the rest of the stack stays behind to be processed. if their are items "in the queue" waiting behind on the belt, they wait their turn like any other interaction where there is traffic. at no point does a belt "stop". to do so would stop the entire factory like being overstressed. so too would the processor stop like the metal press or whatever else if they were on the same network.

   2. sounds boring and uninteresting, why make it so every single interaction needs such micromanagement or filtered stops? fans are the way they are because it is a progress-bar-furnace-replacement which deliberately takes x time, affects multiple and variable blocks of space, and can be stacked to reduce that time; it wouldn't work to stop the itemstack nearly as sensibly... let alone the fact you are pushing air at the items so it makes no sense to freeze them in place

In hindsight, 1 is overcomplicated yes. (My intent wasn't overstressing components, but rather that the belt and anything on the "output" side would stop, while it would not stop the "input" side from moving) - Alternatively the belt, and items on it, could stop (for visual consistency with the queue) but keep transmitting shaft power regardless. This wouldn't break nearly as many things, even if it still doesn't make logical sense.

As for 2, the entire point is to be micromanagey for people who enjoy that part of the gameplay - making super intricate contraptions, problem-solving, etc. It's something quite a few hardcore modpacks would probably love to use. It also makes no sense to freeze things in place on a still-moving belt while it paitiently waits to be pressed or spouted or deployed to, but things do anyway. The whole point of this was to fix that inconsistency.

And again, I suggested they be a config options, so if you don't like it you can just... leave the configs as they are by default, and never have to worry about it. I'm not trying to break your contraptions or make you use filters and micromanage things, I'm asking for the option to do these things if I, or others, want to.