Fix: Dropping items outside of inventory menus

[Adem-Kurt]

Description

This PR fixes two separate bugs that prevented players from dropping items with clicking outside the inventory in menus.

Changes

Previous Behavior

• In the Creative inventory, right-clicking outside the menu bounds while holding a stack of items did not drop a single item. Instead, the right-click input was intercepted to clear the hotbar.
• In standard container menus (Survival Inventory, Chests, Furnaces, etc.), clicking outside the menu bounds with an item held did nothing. The item would remain attached to the cursor.

Root Cause

1. Creative Menu: In IUIScene_CreativeMenu.cpp, handleValidKeyPress had a check that captured any right-click (buttonNum == 1) and triggered the hotbar clearing function, terminating the input flow before the outside drop logic could process it.
2. Standard Menus: In AbstractContainerMenu.cpp, the clicked function had an early bounds check (if (slotIndex < 0 || slotIndex >= slots.size()) return nullptr;). Because clicking outside the UI sends a slot ID of SLOT_CLICKED_OUTSIDE (-999), this early check blocked the input, never allowing the drop code to execute.

New Behavior

• Players can now drag items outside the Creative inventory and right-click to drop exactly one item per click without unexpectedly clearing their hotbar.
• Players can now drag items outside standard containers (chests, crafting tables, standard inventory) and drop items (full stacks or single items) properly onto the ground.

Fix Implementation

• Commit 1: Added !m_bPointerOutsideMenu to the right-click interception logic in IUIScene_CreativeMenu.cpp so it only clears the hotbar if the pointer is actually inside the UI boundaries.
• Commit 2: Added an exception for SLOT_CLICKED_OUTSIDE in the initial boundary bounds check in AbstractContainerMenu::clicked so the -999 ID can properly reach the subsequent drag-and-drop code blocks.

AI Use Disclosure

I used AI as a search tool, find the code causing this bug.

Related Issues

• [Suggestion]drop whole stack #871

[Adem-Kurt]

2026-03-11.22-29-27.mp4

[jvnpr]

Tested your branch, looks like there's a problem in the creative menu where some items don't get dropped even when the count reduces, leading to some getting lost. Doesn't look to be an issue in the inventory.

adem-kurt-1159-pull.mp4

[Adem-Kurt]

Hi,

Thank you for testing the branch and providing the video. I found the root cause of the bug. It is related to the server's anti-spam protection mechanism for dropping items on creative mode.

The Issue:
In Minecraft.Client/PlayerConnection.cpp (around line ~1236), there is a spam prevention check when an item is dropped:

		else if (drop && validItem && validData)
		{
			if (dropSpamTickCount < SharedConstants::TICKS_PER_SECOND * 10)
			{
				dropSpamTickCount += SharedConstants::TICKS_PER_SECOND;
				// drop item
				shared_ptr<ItemEntity> dropped = player->drop(item);
				if (dropped != nullptr)
				{
					dropped->setShortLifeTime();
				}
			}
		}

Right now, the game limit is 200. When you drop 1 item, the game adds 20 to a counter. If you click fast the items disappear.

Possible Solutions:

1. Change the penalty: We can add a smaller number when you drop an item (for example, change 20 to 2).
2. Increase the limit: We can make the maximum limit bigger (like TICKS_PER_SECOND * 50).
3. Turn it off: We can disable this rule completely for local play or creative mode.
4. Give the item back: Instead of the item disappearing, we can give it back to the player. But this might not be the best solution because you need to click more.

I am not sure what the best solution is to fix this. Also, this change might be out of scope for this PR.

[jvnpr]

Given this issue only occurs in the creative menu and not the inventory, how is it currently implemented in the inventory? Does the check only happen within the creative menu?

[Adem-Kurt]

Yes, the check only happens within the creative menu!

In standard menus (like the survival inventory, chests, etc.), dropping items is handled via a standard \ContainerClickPacket. The server processes this in \PlayerConnection::handleContainerClick(), which evaluates the action via \AbstractContainerMenu::clicked(). If the click is outside the bounds (\SLOT_CLICKED_OUTSIDE), it simply calls \player->drop()\ directly (in \Minecraft.World/AbstractContainerMenu.cpp) without any spam limits.

However, the creative menu operates differently. When you drop an item from the creative inventory, the client sends a \SetCreativeModeSlotPacket\ with a negative slot ID to the server. This packet is handled by \PlayerConnection::handleSetCreativeModeSlot()\ (in \Minecraft.Client/PlayerConnection.cpp), which is exactly where this \dropSpamTickCount\ anti-spam logic lives.

Because regular containers use a completely different packet and logic path, they bypass this creative-specific spam filter entirely.

I think the best option is removing the spam check for creative menu.