There is also a slot for your cursor. When your inventory is open you can click on an item to put it in your cursor slot and it will allow you to pick up an additional item.
If you do the same, but add all weight-1 items before adding all weight-4 items, you'll still get a solution using the same (optimal) number of bundles, but you may use more capacity in the final bundle than needed -- e.g., if you have 61 sticks and 1 pearl, and add them in that order, the first bundle wastes 3 slots and the second uses 4 slots (vs. no wasted space in the first bundle and just 1 slot used in the second if adding in the reverse order).
OTOH, if you mix adding items of different weights (while staying with the approach of only ever adding to the current bundle if there's room, and if not, moving to a fresh bundle) then you can arrive at a suboptimal number of bundles. E.g., adding 61 sticks, 1 pearl and 3 dirt in that order will require 3 bundles instead of the optimal 2.
Games often lead to interesting computational problems. Another example - I was designing a solver for Flow [0] which made me think about graph problems and applications in e.g. circuit board wire routing. Intuitively it's easy, but translating that into logic is more challenging.
Turns out you can save a lot of time and effort by just cutting infeasible solutions out one by one, and resuming the solver, as opposed to writing some tricky constraints.
Another POV is, is any game made better by having serious constraint satisfaction problems hiding inside of it?
Before I get flamed for the question, another way of stating the question is, would Minecraft be made better if it didn’t limit the inventory size, or if the inventory limits were so simple as to not require any kind of constraint satisfaction, whether traditional (ie reading a wiki what to do) or programmatic?
[0] https://store.steampowered.com/app/1970580/Backpack_Hero/
Might optimise to run Minecraft servers on a WAN.
LAN should specify whether item selection is hostable.
