Belt/pipe input limiter (v0.7.5c) set to "below 0" blocks items passing through

I suppose this is an oversight and should instead be "below or equal" setting rather than strict "below".

Examples for comparison:

1. Input limiter set to closest non-zero value (20 for tier I storage). Storage is connected to both input and output belts and works as a buffer.
   Expected behavior - storage pulls items from input belt if its current content is less than 20. As soon as the storage has any items it immediately outputs it to output belt - items are passing through.
   Actual behavior - same as expected, works as intended.

2. Input limiter set to zero value. Storage is connected to both input and output belts and works as a buffer.
   Expected behavior - storage pulls single item from input belt and immediately outputs it to output belt, maintaining zero content at all times. If storage can't push items to output then it's not pulling any items from input belt, also maintaining zero content.
   Actual behavior - storage not pulling any items regardless of output capability. This is equivalent to just pausing the input belt.

Also same issue with output limiter. There was a report about a month ago where Cpt Marek explained that this is intended behavior. I still don't get why it works in such way.

This is intended behaviour, which is symmetrical
to this & likely will not change: Belt/pipe output limiter fully right cannot work if output when full is intended

Here's a dev's statement on the mentioned symmetrical issue:
Belt/pipe output limiter fully right cannot work if output when full is intended

rollerkostr [discord] wrote:

I suppose this is an oversight and should instead be "below or equal" setting rather than strict "below".

I'll just copy & mirror what I said on that post: Belt/pipe output limiter fully right cannot work if output when full is intended

I'm pretty sure that this is intended, as this is
a "input if below" & not "input if below or equal to" setting.

And by "input" it means any incoming resources by transports (belts/pipes),
so including ones that would just pass through the storage structure.

That's one nice use case - with limiter you can completely disable storage output when it's connected directly to other storage (so no transports to pause) without pausing the storage itself.
What can I do if I want to keep the storage empty while still maintaining flow through it?

Do you trully need to keep it completely empty?
What's the actual usecase for this?

That's not a lot of capacity that you're wasting
(only 10% of a given storage structure).

I mean it would/could be a nice to have,
but I preffer to have the ability to pause their I/O
and have more performance (as this would
require a substacialy more complexity to implement,
than it already is (even full, unrestricted storages
work like this, there is no "bypass the main buffer"
route for resources, they always go through it)).

Agree with you on the nice to have side, it's not really so crucial for gameplay (for me at least). I just supposed It's an oversight and rather simple to implement or fix to allow all sorts of use cases.

Ok, how about this, would it be better if we got more granural controll
of the fill/empty percentages of storage structures?

Currently it's restricted to 10% precision, but would
it be better for it to be for example 5% instead
(Note: this doesn't have to be the same for all/any
simmilar sliders in the game, like fertility target in farms)?

Also nice to have feature. But why limit yourself with some predefined precision when it can be fully customizable - any user-defined percentage or even exact quantity?

The reason why that's restricted is probably because these sliders were meant to set truck import/export limits,
which need to be coarse in order to make this more-or-less "idiot proof" (so the trucks don't carry partial loads on the regural),
but I think that having more granurality would definetelly help this issue quite a bit.

Interesting! Yes it is by design that we don't allow immediate flow through storages, otherwise storages could be use instead of belts, and teleport items through a bunch of them stacked in a row! They are storages after all, they are meant to store items.

eryk500 [discord] wrote:

Ok, how about this, would it be better if we got more granural controll

There's no reason for it to ever be a % anything, just type in the number.

This is the main reason for it being the way it is: Belt/pipe input limiter (v0.7.5c) set to "below 0" blocks items passing through
And due to ther nature of the reason, this will likely stay as is, unless the devs
figure something out that would fix this & wouldn't be unintuitive or not easly glancable;
it could be as simple as having different slider implementations for trucks & belts,
but it could look strange as to why the truck sliders behave differently than the belt ones.