Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Ban-pick: weighted tuple pool policy per gamemode (Botlatro generation parity)

Open
#13 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
lua
Domain
api

Research direction

Start by locating the ban-pick engine's BP.start entry point, its current default pool, and the build_pool/decorate_tile integration. Use src/utils/TupleBans.ts as the behavioral reference for weighted tuple generation and constraints. Done means consumer policies work per mod and gamemode, with server-deliverable configuration and client defaults as described.

Written by the indexing model from the issue text.

Description

The ban-pick engine's default pool is a uniform random sample of every installed deck Back — including modded decks — with no exclusions, no weights, and no stake dimension. Botlatro (the Discord matchmaking bot) already runs real pool policy for its tuple-ban queues; this issue is about giving consumer mods the same power in-game, per mod and per gamemode.

Reference: what Botlatro's generation enforces (src/utils/TupleBans.ts)

  • Allowed stakes: a fixed subset (White/Green/Black/Purple/Gold — 5 of 8).
  • Allowed decks: decks table minus per-queue banned_decks minus match-step bans.
  • Weighted roulette-wheel selection via per-queue deck_mults / stake_mults.
  • Occurrence caps in the generated list (9 tuples): max 4 of any stake (< (tupleCount-1)/2), max 3 of any deck (< (tupleCount-3)/2), no duplicate (deck, stake) pairs.
  • White-stake guarantee: if the final slot is reached with zero whites, it is forced white — every list contains at least one.
  • All of it is data-driven (DB tables) so moderators tune weights/bans live, without a deploy.

Proposal

  1. A reusable weighted-tuple pool helper in the API (opt-in, e.g. MPAPI.BanPick.build_weighted_pool(policy)), implementing the constraints above and returning { key, stake } items. The engine already supports everything downstream of it: pool items may be { key, stake, ... } tables, and config.decorate_tile(card, item) renders stake stickers — no engine changes needed.
  2. Policy comes from the consumer, per gamemode — each mod passes its own policy into BP.start via build_pool, exactly like schedule/decorate_tile today. PvP and Speedrun configure independently.
  3. Policy data should be server-deliverable (gamemode config in the match/lobby payload, keyed by modId + gameMode) so allowed lists/weights can be tuned like the bot's DB-backed mults — without shipping mod updates. Client-side defaults as fallback.

Notes

  • Sampling differs today: the in-game default samples decks without replacement (each deck once); tuple pools intentionally allow one deck at multiple stakes. Both remain valid choices per gamemode — the helper covers the tuple case, the current default stays for plain drafts.
  • Related: the low-rated-player pool veto (see linked issue) depends on this — its mercy rule ("force white stakes into the reroll") only has meaning against a weighted tuple pool.
Dominant language
Lua
Stars
7
Forks
3
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Balatro-Multiplayer/BalatroMultiplayerAPI

All issues in Balatro-Multiplayer/BalatroMultiplayerAPI

Similar issues

More Lua issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.