Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Ban-pick: one-time pool veto for low-rated players (port of Botlatro's tuple veto)

Aperta
#14 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
lua
Ambito
api, game-dev

Direzione di ricerca

Inizia dalla gamemode/queue config, da matchmaking_ratings.rating e dal match/draft payload. Traccia il flusso di build_pool dell'API engine, lo host state e la configurazione del pulsante Confirm/Random, poi esamina decorate_tile nella mod Speedrun. Il lavoro è completato quando can_veto è calcolato dal server, il consumo una tantum e il broadcast avvengono lato server, il pulsante UI è correttamente condizionato e la generazione del pool tiene conto di mercy.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

What

Port Botlatro-Multiplayer's match veto into the in-game ban-pick draft: a
one-time-per-match button letting a low-rated player reroll the candidate pool,
with a difficulty-mercy bias.

Reference semantics (Botlatro-Multiplayer, verified in source)
  • Tuple-ban queues generate 9 weighted (deck, stake) tuples; teams ban from the list.
  • Veto (veto-tuples- handler): only match participants with
    elo <= queues.veto_mmr_threshold (fallback 200) may press it. Effect: full
    tuple-list regeneration with a mercy rule -- TupleBans.veto() forces white-stake
    generation when the list holds fewer than 4 white-stake options
    (vetoWhiteAmount = 4). One veto per match, shared (tupleVetoUsed keyed by
    match id): if both players are eligible, first press consumes it. No vote --
    unilateral, by design (it is a low-rated-player protection).
  • Contrast: Reroll Options is the consensual sibling -- any participant may
    trigger it but it runs a vote of all match players, also once per match.
  • Rank names (STONE etc.) are Discord roles (queue_roles.mmr_threshold) and are
    display-only; the veto gate is an independent raw threshold. The bot does not
    tie veto to rank either -- the numbers are just aligned by convention.
Two bot bugs the port should NOT copy
  1. Button visibility checks the WHOLE QUEUE, not the match:
    SELECT elo FROM queue_users WHERE queue_id = $1 + .some(...)
    (matchHelpers.ts) -- the VETO button renders whenever anyone in the queue is
    under threshold, and the real gate only happens at press time.
  2. Open TODO: the veto button disappears permanently after a reroll.
Design: server-computed eligibility (client never knows the rule)

The server computes can_veto per player per match and includes it in the
match/draft payload. The client renders the button only when true; the host/server
still validates the veto action itself (client-side gating alone is spoofable).

This keeps the eligibility RULE server-side and swappable: start with bot parity
(rating <= threshold in gamemode/queue config, using matchmaking_ratings.rating),
and later move to named tiers if/when the server grows a tier concept -- today the
schema has only integer ratings and leaderboard positions, no named ranks -- all
without touching the mod or API.

Depends on

#13 (weighted tuple pool policy) -- the mercy rule only has meaning against a weighted tuple pool. Eligibility and pool policy are both per modId + gameMode, so PvP and Speedrun configure independently.

Work items
  1. Server: veto threshold in gamemode/queue config; compute per-player
    can_veto into the match payload; validate + consume the veto action
    (once per match) server-side.
  2. API engine: veto action -- host regenerates the pool (consumer
    build_pool re-run with a mercy flag), resets the ban schedule, broadcasts;
    once-per-draft guard mirrored in host state.
  3. API UI: Veto button in the ban-pick button row (definition-time button
    config + per-frame check, same pattern as Confirm/Random); rendered only when
    the payload says can_veto; removed once consumed.
  4. Speedrun mod: pool builder honours the mercy rule (the white-stake-bias
    equivalent for its pools; engine already supports {key, stake} tuple items +
    decorate_tile).
Open questions
  • Threshold value per gamemode (bot default is 200; new-server ratings default 600
    -- numbers need re-basing).
  • Veto on plain deck drafts too, or only tuple (deck+stake) pools?
  • Repool semantics: bot restarts the tuple ban list -- mirror that (full draft
    restart) or preserve prior bans?
Lingua principale
Lua
Stelle
7
Fork
3
Metriche di merge delle PR
Nessuna PR unita negli ultimi 30g

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Balatro-Multiplayer/BalatroMultiplayerAPI

Tutte le issue di Balatro-Multiplayer/BalatroMultiplayerAPI

Issue simili

Altre issue su Lua

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.