[MC-6165] Comparators cannot determine if a container is empty

What I expected to happen was:
As comparators can now be used to guage the contents of containers, I expected a single item to be adequate to output a signal, allowing us to determine when a container has become empty

What actually happened was:
The container must be over 6.666...% full before any output is created. For chests, this means 116 items must be inside before a signal is produced. For hoppers, this means 22 items must be inside.

This essentially makes it impossible to check for emptiness, restricting us to a fullness test. The fix would be simple enough: output floor( (contents/capacity) * 14) + ceil((contents/capacity)), instead of floor( (contents/capacity) * 15). This would still allow checking if a container is at its capacity, while also allowing you to check if it's completely empty.

Steps to reproduce:
1. Place a comparator, with a container as its input, and a 15-long wire of redstone dust as its output.
2. Insert an item into the container. If it does not exceed 6.666...% of the container's capacity, there will be no output.
3. Bring the container to above 6.666...% of its capacity. Observe an output of 1.
4. Bring the container to near full capacity. Observe that its output is 14.
5. Bring the container to full capacity. Observe that its output is 15.

I don't see this as a feature request, but rather a bug in the newly added system (remember, the snapshot came out just today). It seems unreasonable (and likely accidental) to have no way of determining a container is completely empty, when you can determine the container is completely full. Both of these features are far more useful than determining a container's percent content in increments of 6.666...% instead of 7.142857...%.

In fact, this change would have an added benefit (unintentional by my equation, but still): an output of 8 would indicate a container is precisely at 50% or higher. In the current system, 7 indicates you're 3.333% higher or lower than 50%, which is again a failure to provide a useful threshold for calculations.

Finally, an example usage case of why you would want to determine a container is empty: you could have an automated storage minecart unloading station, using a hopper to unload the carts. When the hopper contains zero items, you know the cart is empty, and you can send it on its way.

Comments 15

WolfieMario 2013-01-05T03:03:02Z

You know, I have a feeling a mod here will be tempted to close this as "Invalid". I've seen this happen many times. At the very least, if you're going to close this, have the courtesy to acknowledge that it's a bug report, not a feature request. Thus, if you feel this behavior is intended, mark it "Works as Intended", not "Invalid". It would also be nice to see evidence it's intended (Hi Dinnerbone! 😃), not the opinions of somebody who does not actually work at Mojang.

The heart of the report is "comparators don't give an output if their input container has at least one item". There is no way to interpret that as a 'feature request'; it is a factual statement, which is either intentional or unintentional. If you must close this, close it based on the issue I am reporting, not based on the fact that I suggested a fix.

Of course, if you don't think this is intentional, then there's no need to close it. I'm not asking for it to be closed; I'm just saying that if you are closing it, don't cop-out and say it was never a bug report to begin with.

Howzieky 2013-01-05T05:57:29Z

PLEASE FIX THIS DINNERBONE! Everybody else, VOTE THIS UP SO HE CAN SEE

Tanisha Angelia 2013-01-05T11:33:15Z

I found this behavior to be undesirable as well.

Personally for me it would be more useful to have a system that showed how many slots where free, ignoring stack values completely, but I'm aware that those wanting more detail wouldn't be happy about that - but throwing it out here in case there's a chance for having both type of checks.

kuemmi 2013-01-06T02:31:04Z

It's also not consistent with the behaviour of the newly added pressure plates, that give off a signal with one item.

Anon Ymus 2013-01-06T03:49:13Z

As annoying as it is, it would make some redstone signal strengths encompass a wider range of items, making this feature less precise. Also, it would break the functionality in http://www.youtube.com/watch?v=a92_VBLTjAQ because hoppers filled with five diamonds would output a signal.

5 more comments

Tanisha Angelia 2013-01-06T06:36:36Z

@Anon I see the problem, it would been easily resolved if we had a power source with a power output that could be modified, then you could added those as a one signal B input to those comparators and it wouldn't been an issue anymore. Any current solution would make it rather hard if not impossible to get a compact design. :/

But I'm more in favor of filter hoppers and filter pipes to begin with which would allow for even more sophisticated sorting devices as you could side step the technical issues in favor of contraption feature complexity and elegance.

WolfieMario 2013-01-06T17:13:35Z

@Anon The current setup is already not all that precise - you can't even tell if you're under or above 50%, one of which the revised version would allow. As I said, is 6.666...% all that different from 7.142857...%? Sure, one's less pretty (I should note that both are still rational numbers; the latter is 100/14, or 50/7), but generally you'd do rounding anyhow. And you can just round that one down to 7% without much inaccuracy. You'd get the benefit of being able to tell a container is completely empty, 50% or less empty, and completely full. Right now you can just tell that it's completely full.

And this was just the second snapshot of 1.5; with that logic we couldn't change the behavior of any item now, because it would break builds. I think the idea is to get redstone working right before releasing 1.5; the breaking of builds which are running in testing versions should be entirely inconsequential to the improvement of redstone.

Also, that device will likely be outmoded if/when Dinnerbone adds filters (he has stated that he has acknowledged Sethbling and Docm's works do not remove the need for a filter, as neither work on non-stackable items. In fact, neither present anything that new to the game; stack-based sorting has been possible as early as eight months ago). Even if filters are not added, the worst that will happen is the device loses compactness. All you need to do is set the comparator to only output a signal if the strength is at least two ticks of strength, and add one item to each detection hopper.

Thus, fixing this would make things possible, without making anything else impossible.

Dan Porter 2013-01-07T15:29:01Z

I'm also strongly requesting this feature, however I may rephrase it.

Comparators operate as you would expect, giving a redstone signal equivalent to how full they are out of 15 (3/15ths full, 3 strong redstone signal)

Our feature request (if I follow everyone and myself right) is the ability to check IfEmpty on any container item, wether using a comparator or not. Personally, I'd prefer it rolled into comparators by changing the scale to be 1 power if items present +1 for each 1/14th full.

WolfieMario 2013-01-07T15:48:50Z

Well, at its core, this is a bug report - namely, that comparators don't let us check whether a container is empty or has one item. If we said this is a feature request, I'm afraid a mod would have to come and close it 😛

I hope the mods don't mind us proposing ideas to fix this bug, and remember that feature requests to fix bugs don't make the bug itself a feature request? 😛
I mean, I can move my suggestion in the report itself down to the comments, if that's needed.

Anyhow, yes, your proposed formula evaluates the same as mine - it's just easier to read. I don't think the exact formula matters (Mojang might opt for something more on the order of "(contents / capacity * 14) + (contents > 0 ? 1 : 0)", as that's both valid Java, and not hilariously inefficient like my more mathematically-clear version); all that's important is that the problem is solved - namely, that we be able to determine if a container is exactly empty or exactly full.

Nathan Adams 2013-01-09T23:32:30Z

The algorithm was changed to "average fullness of all slots" from "average fullness of the whole container" very quickly after 13w01b's release. It will also ceil instead of floor. 0.0001% fullness will give 1 output.

WolfieMario 2013-01-09T23:49:29Z

Thanks Dinnerbone! The only problem I see is, does it let us check if a chest is 100% full, to prevent overflow? If I'm calculating this correctly, the average fullness of slots for a chest missing a single item is 0.999421296...%, and a chest with 26 of 27 slots consumed is 0.962%. Where does that ceiling occur? Would those situations output 15, or will 15 be reserved for a completely full container? 😛

Also, I could be doing my math wrong, as I landed on the exact same numbers for "average fullness of the whole container" as I did "average fullness of all slots". Not surprising, what with all the numerators and denominators cancelling, making the equations literally the same. But I don't quite understand what difference the two situations imply.

Anyways, thanks again!

Nathan Adams 2013-01-09T23:55:40Z

Current ("fullness of the whole container") algorithm is pretty much:

Guess at how much the max capacity of the container is by assuming empty slots' max == average max of nonempty slots
Total the count of all the items that we have
Pct == total / guessedMax
Round down, convert to redstone

New algorithm is:

For each slot, figure out its fullness (count/total, empty slots = 0/64 == 0)
Pct == total/numSlots
Round up, convert to redstone

There isn't a way to know exactly 100% full, and not "nearly full". Do you have a suggestion for that?

Anon Ymus 2013-01-10T00:01:28Z

Perhaps reserve signal strength 0 for empty, 15 for full and scale the others by multiplying by 14/15 before ceil-ing? I think people are most concerned with whether their container is full or empty, as useful as a percentage is. I think making it slightly harder to find the exact percentage is worth having a full signal. (I mean, the whole point of redstone signals is that they are blocky and by no means exact.) Again, thanks very much.

WolfieMario 2013-01-10T00:13:50Z

Agreed, I think the redstone conversion is where the issue happens. One of my suggestions above, restated here (as the above was actually flawed, go figure) as "(int)(percent * 14) + (total > 0 ? 1 : 0)", would seem to accomplish it.

If percent is 0 (as total is 0 if all slots are empty), the ternary will return 0, as will percent*14, totalling 0.
The floor done by (int) makes the first term still zero out if it's under 1/14, while the ternary always evaluates to 1 if there is at least one item.
After percent is 1/14, we get an output of 2.
For a percent of 99.99999%, we still get 13+1 = 14.
Only 100% will pass 14 out of the floor and allow an output of 15.

WolfieMario 2013-01-17T17:30:25Z

To anybody still wondering, as of snapshot 12w03a (possibly earlier), Dinnerbone has apparently implemented things in exactly the way we suggested above (one item is enough for 1 tick of signal, and a container must be completely full for an output of 15. You get an output of 8 once it is exactly 50% or more full).

Many thanks again, Dinnerbone! 😃