fix: hotbar tools, shulker boxes and drops by blocksimus · Pull Request #353 · lambda-client/lambda

blocksimus · 2026-10-22T01:33:49Z

Description

A few things I ran into after the rewrite... feel free to pick them apart.

Hotbar swapping behavior - hotbar gave up the smallest stack first so tools were getting moved out. The default sort by count meant any sort added after it only broke ties. Not as happy with the code here, so if you have any better thoughts...

A shulker box in the hotbar never opened (it tried to move it from the hotbar to the hotbar), nothing could be taken out of an open one so builds kept placing and breaking it, and a box couldn't go back while an identical one was in the hotbar. Opening uses a withContents filter now instead of sortedByBestContentMatch, because acquireStack grabs any matching box already in the hotbar, so a same-looking box with different contents would get opened instead.

Collecting drops only set Baritone's goal when the drop moved, so if another task stopped Baritone on the way it just sat there. Now it sets it again after Baritone's been idle for a second.

Selections kept their default sort by count when mutated, so any sort added after it only broke ties. A full hotbar then gave up its smallest stack first, which was usually a lone sword or tool.

A box already in the hotbar never opened, nothing could be taken out of an open box so builds kept placing and breaking it, and a box couldn't go back while an identical one was in the hotbar.

Collecting drops only set Baritone's goal when the drop moved, so if another task stopped Baritone on the way it just waited forever. Now it sets it again after Baritone has been idle for a second.

beanbag44 · 2026-10-22T09:49:58Z

 						.asSequence()
 						.filter { it.stack.item == shulkerItem && it.stack.name.string == itemName }
 						.firstNotNullOfOrNull { it.slot }
+					if (pickedUp != null && containedIn.slots.any { it.identity() == pickedUp }) return@thenOrNull null


hm, maybe we could adjust the container transfer task to allow swapping within the same container, just checking that the slots arent the same? I dont see how that could break any functionality. Then to avoid a needless transfer we could check to see if the original slot the shulker came from is empty and the shulker is already in the correct container before doing the transfer.

I shortcut this by not bothering if it was just going back into your inventory/hotbar (not external), unless you think it's important to try get it back where it was previously?

If possible at least. If the slot isnt empty anymore then dont bother, but i think for the sake of inventory cleanliness its best to try

Done, the only skip is the box already being back in its container with its own slot filled.

blocksimus · 2026-10-22T11:47:15Z

Thanks for the review! I'll try get another iteration done soon.

Picks boxes by slot, hands back the placed box instead of keeping it on the container, and only puts boxes back into chests.

The Pre stage swapped a kept slot back before it was asked again, so a swap pause never ran out.

blocksimus · 2026-10-23T05:12:04Z

 	private fun SafeContext.checkResetSwap() {
 		activeRequest?.let { active ->
 			if (active.keepTicks <= 0) {
+				if (active.keepTicks == 0 && active.activeRequestAge > 0 && tickStage != requestStage) return


Fixes an issue I hit with my Nuker's Server Swap at 2. The slot got swapped back at Pre (now in the default mask) before the break asked again, so Nuker stalled.

Ah i wondered if changing the default would cause issues. Wouldnt we only need the tickStage != requestStage check though? keepTicks is checked to be <= 0 just before, and the active.activeRequestAge > 0 would never prevent the return for keepTicks 0 requests as they start and end on the same event

Yea, the activeRequestAge > 0 was unnecessary. I think == 0 is still helpful... if a request becomes overdue, it can swap back at any stage, not just its own.

beanbag44

Lemme know if this is too much, i can always help out; i think the pr's have maintainer write perms enabled by default

beanbag44 · 2026-10-23T11:06:17Z

 			}.then { pos ->
 				openContainer(pos).onSuccess {
-					success(OpenedShulkerBoxContext(pos))
+					val placed = PlacedShulkerBoxContainer(pos, Block.getBlockFromItem(shulkerItem), null, stacks)


hm containers should only really be created in ContainerHandler and ContainerSerializer. Seeing as openContainer accesses the placed shulker, you can probably receive it from ContainerHandler.accessedPlacedContainer. Or actually its likely best just to change the return type of openContainer to T : PlacedContainer with the class taking a type parameter

See what you think...

beanbag44 · 2026-10-23T11:28:30Z

 	private fun SafeContext.checkResetSwap() {
 		activeRequest?.let { active ->
 			if (active.keepTicks <= 0) {
+				if (active.keepTicks == 0 && active.activeRequestAge > 0 && tickStage != requestStage) return


Ah i wondered if changing the default would cause issues. Wouldnt we only need the tickStage != requestStage check though? keepTicks is checked to be <= 0 just before, and the active.activeRequestAge > 0 would never prevent the return for keepTicks 0 requests as they start and end on the same event

beanbag44 · 2026-10-23T12:28:09Z

            .toStructure(TargetState.Stack(slot.stack))
            .toBlueprint()
            .build(finishOnDone = true, collectDrops = false)
+            .onPreTick { slot in HotbarContainer.slots && !this.hotbarRequest(slot.index).submit().done }


hm something about this feels off lol but i think the whole TargetState style system needs improving, so that can wait for a later date

Yes, it does, and I was getting into a mess working through some edge cases... have a look at the change in InteractSim instead.

blocksimus · 2026-10-24T04:13:25Z

Lemme know if this is too much, i can always help out; i think the pr's have maintainer write perms enabled by default

No stress, it's been a good exercise in getting to know the codebase, although feel free to make changes as you'd like.

A closed box goes back into its own slot when it's free, or stays where it was picked up if it can't go back.

blocksimus · 2026-10-24T05:16:22Z

 		}

-		listen<InventoryEvent.FullUpdate> { onContainerUpdate() }
+		listen<InventoryEvent.FullUpdate>(priority = { Int.MAX_VALUE }) { onContainerUpdate() }


I had to set a higher priority so ContainerHandler indexes the opened container before OpenContainerTask reads it.

blocksimus added 3 commits October 22, 2026 12:11

fix: keep tools in the hotbar when making room

af61151

Selections kept their default sort by count when mutated, so any sort added after it only broke ties. A full hotbar then gave up its smallest stack first, which was usually a lone sword or tool.

fix: open, empty and put back shulker boxes

b63840e

A box already in the hotbar never opened, nothing could be taken out of an open box so builds kept placing and breaking it, and a box couldn't go back while an identical one was in the hotbar.

fix: walk to drops again after Baritone stops

7daa215

Collecting drops only set Baritone's goal when the drop moved, so if another task stopped Baritone on the way it just waited forever. Now it sets it again after Baritone has been idle for a second.

github-project-automation Bot added this to Kanban Oct 22, 2026

github-project-automation Bot moved this to Backlog in Kanban Oct 22, 2026

beanbag44 self-requested a review October 22, 2026 09:56

beanbag44 requested changes Oct 22, 2026

View reviewed changes

blocksimus added 4 commits October 23, 2026 14:11

fix: open and place the right shulker box

f6547bb

Picks boxes by slot, hands back the placed box instead of keeping it on the container, and only puts boxes back into chests.

fix: keep a hotbar slot until its stage comes back

1dac2e4

The Pre stage swapped a kept slot back before it was asked again, so a swap pause never ran out.

style: put task chain steps on closing braces

b3b9dee

fix: pick the right shulker box to open

a57615f

blocksimus force-pushed the stack-fixes branch from 35cca8c to a57615f Compare October 23, 2026 04:21

blocksimus commented Oct 23, 2026

View reviewed changes

blocksimus requested a review from beanbag44 October 23, 2026 09:03

beanbag44 requested changes Oct 23, 2026

View reviewed changes

blocksimus requested a review from beanbag44 October 24, 2026 04:13

blocksimus added 2 commits October 24, 2026 16:08

fix: put shulker boxes back by slot identity

311d6a7

A closed box goes back into its own slot when it's free, or stays where it was picked up if it can't go back.

refactor: derive slot identity from container index

d5103f7

blocksimus force-pushed the stack-fixes branch from 09dfdea to d5103f7 Compare October 24, 2026 05:09

blocksimus commented Oct 24, 2026

View reviewed changes

Conversation

blocksimus commented Oct 22, 2026

Description

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

blocksimus commented Oct 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

beanbag44 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

blocksimus commented Oct 24, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants