Skip to content

feat(seller): restock sold out items in batches instead of one stack per cycle - #33

Merged
icemansparks merged 1 commit into
merkerhoodfrom
feat/restock-batching
Aug 24, 2026
Merged

feat(seller): restock sold out items in batches instead of one stack per cycle#33
icemansparks merged 1 commit into
merkerhoodfrom
feat/restock-batching

Conversation

@icemansparks

Copy link
Copy Markdown
Collaborator

Problem

When an item sells out (Thick Leather was the reported case) it takes a long time to come back, and then only one stack at a time.

GetItemsToSell() builds its priority block by walking itemPriceOverrides and pushing each item that is not currently in the auction house once. With ~11.5k price override rows, a specific missing item has to win a shuffle against every other missing item to land inside that cycle's ItemsPerCycle (200) budget — hence the wait. And because itemsInAH is snapshotted at cycle start and the item appears once, it can only ever be relisted as a single stack per cycle.

Change

The priority block now queues an item as many times as it is short of its target count:

  • target = mod_auctionhousebot_countOverride.targetCount, else the global AuctionHouseBot.DuplicatesCount, else 1 — the same precedence the per-listing cap in Sell() already applies, so the batch can never overshoot (botItemCounts is incremented per listing).
  • sold out items first, then items still partially stocked (top-up), each group shuffled independently.
  • copies are expanded after the shuffle so they stay adjacent — an item that gets picked gets its whole batch, rather than the batch being split across cycles.

New setting AuctionHouseBot.RestockBatchSize (default 5) bounds how many stacks of one item a single cycle may queue, so one item with a target of 50 cannot eat the whole ItemsPerCycle budget. Set it to 1 for the previous one-stack-per-cycle behaviour.

TraceSeller now logs how many items were sold out vs understocked per cycle.

Behaviour notes

  • With ~10.6k countOverride rows loaded, the priority block is now larger and blocks 2–4 (random duplicates / non-override bins) are reached even less often than before. That is intended: restocking is now targeted instead of random.
  • Existing setups with no countOverride rows and DuplicatesCount = 0 see no change (target falls back to 1 stack).
  • Cost is unchanged in order of magnitude — blocks 3 and 4 already pushed the full item bins each cycle.

Verification

  • Restock math checked against a standalone harness mirroring missingStacks() (sold out / partial / at target / no override / batch size 1 / batch size 0) — all assertions pass.
  • Full module compile: the core-build workflow on this PR.
  • Not yet built or run on testcore (LXC 113).

Files

  • src/AuctionHouseBot.cpp — batching logic in GetItemsToSell(), botItemCounts passed in
  • src/AuctionHouseBot.h — signature
  • src/AuctionHouseBotConfig.{h,cpp}RestockBatchSize
  • conf/mod_ahbot.conf.dist — setting + docs

…per cycle

GetItemsToSell() put every price override item that was absent from the
auction house into the priority block exactly once, so a sold out item came
back at one stack per cycle at best, and only if it won the shuffle against
every other missing item within that cycle's ItemsPerCycle budget.

The priority block now queues an item as many times as it is short of its
target count - the per-item mod_auctionhousebot_countOverride value, else the
global DuplicatesCount, else one stack, matching the cap Sell() already
enforces per listing. Items still partially stocked are topped up too, after
the sold out ones. AuctionHouseBot.RestockBatchSize (default 5) bounds how
many stacks of a single item one cycle may queue; 1 keeps the old behaviour.
@icemansparks
icemansparks merged commit 02f0d36 into merkerhood Aug 24, 2026
1 check passed
@icemansparks
icemansparks deleted the feat/restock-batching branch August 24, 2026 10:21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant