WORLDEDIT-2775 - Reported by Chekkaa

If use-inventory is enabled and the player is subject to it, then normally they are given the destroyed blocks if they run something like //set 0. However, if they do an operation that would cause them to break more blocks than they can hold in their inventory, the player only receives as many blocks as they can carry, and the rest are "destroyed".

Normally, this is not a huge problem, but if the player then does an /undo, only the blocks that they have in their inventory at that moment are used for the operation, causing the restoration to be incomplete. To give an extreme example, if the player does a //set 0 on a region full of stone while their inventory is full of dirt, they will not get any stone. If they then do //undo, the command will complete, but nothing will be restored, because the player did not have any stone to restore with. As you can see, this undermines the entire functionality of //undo.

I propose that these "destroyed" blocks that can't fit into the player's inventory (the stone) be recorded (as a sort of "block credit") along with the data used to perform an undo. This will allow for undo operations to complete even when the user's inventory could not hold of all the blocks given by the original command. Of course, if the player throws away any given items before running the undo, it will still not complete fully, as only the "destroyed" blocks will be restored. However, a full undo would still be attainable by reacquiring the items given from the original //set 0 command through some other means. In this situation, it would be helpful to tell the player what blocks they lacked after doing an incomplete //undo (like the other operations do when use-inventory is enabled), so that they can acquire them, //redo, and finally do a proper, full //undo.

Alternatively, the blocks that were actually given to the player when running the //set 0 command could be stored, and every block that is not one of those would be restored as though it were one of the "destroyed" blocks. This would likely be more space-efficient, as the maximum amount of blocks to be stored would be equal to the maximum amount of items that can be held in a player's inventory, rather than the number of blocks that can be changed in a single WorldEdit operation (which is usually much larger).

Comment by CHCMATT

I am also having this issue, and when //undo is done, it seems to provide some kind of inventory issue (as pictured below). It makes some sort of 0'd out items which, when clicked on, they disappear.