class ItemStackHandler
{
    @Override
    public void setStackInSlot(int slot, ItemStack stack)
    {
        validateSlotIndex(slot);
        if (ItemStack.areItemStacksEqual(this.stacks[slot], stack))//this, wasn't this function supposed to have it's return negated?
            return;
        this.stacks[slot] = stack;
        onContentsChanged(slot);
    }
}

if(stacks are the same): return

else: put stack in slot

 

 

Soo...no.

if(stacks are the same): return

else: put stack in slot

 

 

Soo...no.

 

so I have 3 blocks of stone in inventory slot 1, I want to put 3 other blocks of stone in inventory slot 1. I can't? I don't even think this method should be used at all. it compares stack sizes, which makes no sense in the context.

While I agree - "set" (setStackInSlot) means that you are setting instance and should be literally "inv[slot] = stack", you can't argue with the logic behind it - If stacks are already equal = do nothing, else = set it to one you want.

 

Still, this is not bug, rather design choice.

 

Also - there most certainly won't be negation like you proposed.

 

P.S: You can always override

While I agree - "set" (setStackInSlot) means that you are setting instance and should be literally "inv[slot] = stack", you can't argue with the logic behind it - If stacks are already equal = do nothing, else = set it to one you want.

 

Still, this is not bug, rather design choice.

 

Also - there most certainly won't be negation like you proposed.

 

P.S: You can always override

 

You are right, I guess. I don't know the call hierarchy of this method so whoever are its caller must know what they're doing.

Anyone can call that method at anytime, and it does exactly what it says it does: it sets the slot contents to the stack provided. If you have 3 stone and want to add 3, you create a stack of 6 stone and use that as the argument to this method. That's how this method has always worked.

 

As for the stack comparison and return, I would guess that is to avoid needlessly calling #onContentsChanged, a presumably potentially expensive operation - probably ends up forcing a write to disk down the line somewhere.