no-shows should not show down hands

[ctm]

Currently mb2 treats players who never show up the same as players who have been playing, but time out. In both cases the player is marked as on vacation and at showdown, if the player is in a hand (usually due to blinds, although players can go on vacation in the middle of hands), the player has a chance of winning the pot.

This is not how it's done IRL (and, AFAIK, on other sites), in that if you never show up (or actually, if your butt isn't in a seat when the cards are dealt) your cards are mucked at the beginning of the hand.

mb2 should do something similar.

C. Meck wrote me a nice email about this. I'm a little too tired to process it, but I don't want this falling through the cracks. I'll circle around and get back to him sometime when I'm more alert.

[ctm]

C. Meck:

It's standard that absent players remain in tournaments until blinded off. I do remember freerolls where players who no-showed were taken off after a few levels. I've even played in a live tournament where a dead stack remained in play until blinded off because someone had paid for it, but never bothered to play. It's also standard that when the absent player is all-in, that their cards are folded and thus are automatically eliminated. In live play, this would happen when an empty seat is dealt the hand, then the dealer mucks when once the cards have been dealt.

IMO, I wouldn't remove absent players but I would have absent players automatically have their hand folded, so they would lose when all-in. The part about the other table having more dead chips to play for due to the sit-out to me is just one of those random things that sometimes works in your favor and sometimes doesn't.

OK. So, what I'll initially do is make it so that mb2 keeps track of whether a player has played at least one hand, and if not, I'll have that hand folded at the showdown. In a live game it's clear when a person is in a seat and when not, but online I can't tell if someone was in the seat by the time the cards are dealt.

If the above mod ("played at least one hand") is too lenient, I'll revisit this and consider a stricter rule.

[ctm]

I've made this high priority because we've had a lot of no shows lately and it's one of three things I hope to get done today.

[ctm]

I've demoted this to a nicety and taken away high priority. It's getting late enough in June that I really need to focus on the true Pre-requisites, the biggest being load testing #231.

This is still easy to do, so I'll probably do it sometime as filler when I have only a small amount of time to work.

[ctm]

JRX: deadhead, V players and Zombies should not win pots, they should be auto folded on 1st action - needs to be fixed before you can sell it

[ctm]

Back in June, when I removed the high priority tag, I wound up forgetting to do what I initially claimed I would do. However, that solution wouldn't have helped with Grizz yesterday. It would only help with no-shows which have indeed been an issue in the recurring evening and night games, but haven't been a problem at ARG, per-se.

It would be trivial to implement fold at first action for someone on vacation, but IMO, that would excessively penalize someone with a network glitch. However, it's not particularly hard to implement a round-trip check from the server to the client and back on first action and fold once the client has responded.

AFAIK, the only downside to what I've described in my previous paragraph is every once in a while it might look like someone is getting a break that others don't get. However, I don't think that's big enough to worry about, especially since there are a bunch of other things that I can (and will add), including better whose turn feedback (#232) that will only improve things.

So, I've both restored the high priority tag and also made this part of the EMBARGO milestone. I will try to get something done "soon", but probably won't deploy it before today's two EMBARGO tournaments, because a rushed deploy could make things much worse if there's a bug.

[ctm]

FWIW, I did some work on this earlier today. There's a little trickiness associated with the bring-in in stud. Logically, I know how to proceed, but due to the trickiness I'll do more testing than normal.

[ctm]

I've implemented the first step (i.e., the one I claimed I'd do back on June 16th), tested it and merged it to master. I'll deploy it sometime in the middle of the night or early tomorrow.

I'm closing this issue and opening a new one to implement the algorithm I described earlier today.

[ctm]

This code caused a panic:

thread '<unnamed>' panicked at 'n_source: 0, n_to_use: 4', lib/commands/src/evaluator.rs:17:9
stack backtrace:
  15:        0x108c8e2f4 - mb2_commands::evaluator::combinations::hceb435bf4d231034
                               at /Users/ctm/poker/rust/poker/lib/commands/src/evaluator.rs:17:9
  16:        0x108cb9307 - mb2_commands::game::best_hand_from::h106d07ac59ba0351
                               at /Users/ctm/poker/rust/poker/lib/commands/src/game.rs:72:32
  17:        0x108d19bd1 - mb2_commands::game::best_hand_and_hands_from::{{closure}}::h17c55331d2cae70f
                               at /Users/ctm/poker/rust/poker/lib/commands/src/game.rs:175:13
  27:        0x108cb9a19 - mb2_commands::game::best_hand_and_hands_from::h8f4437dc40a48432
                               at /Users/ctm/poker/rust/poker/lib/commands/src/game.rs:172:17
  28:        0x108d1a377 - mb2_commands::game::hands_won::h5c6faf5006d6944f
                               at /Users/ctm/poker/rust/poker/lib/commands/src/game.rs:239:9
  29:        0x108c88bca - <mb2_commands::game::badugi::Badugi as mb2_commands::game_group::GameGroup>::hand_winnings::h569e5992d91f6f20
                               at /Users/ctm/poker/rust/poker/lib/commands/src/game/badugi.rs:89:25
  30:        0x1087c90a0 - mb2::table::Table::showdown::h9eebf67e3f288d32
                               at /Users/ctm/poker/rust/poker/mb2/src/table.rs:1749:40
  31:        0x1087d4581 - <mb2::table::Table as mb2::table::NextActions>::award_uncontested::h9de98d409de4c830
                               at /Users/ctm/poker/rust/poker/mb2/src/table.rs:3581:9
  32:        0x1086a1312 - mb2::tournament::RunningEvent::act::h683bcbcd7fb31d41
                               at /Users/ctm/poker/rust/poker/mb2/src/tournament.rs:685:36
  33:        0x1086a01b7 - mb2::tournament::RunningEvent::run::h1e166fbbbde57512
                               at /Users/ctm/poker/rust/poker/mb2/src/tournament.rs:568:20

This was after a no-show was all-in:

demo989 blinds 15000
demo990 blinds 9200 and is all-in
1    V demo990 0  9200  [  ] [  ] [  ] [  ]
2 B   demo989  15800 15000  [  ] [  ] [  ] [  ]
              My cards are: [Jd] [Qd] [2h] [Qs]
1   >V demo990 0  9200  [  ] [  ] [  ] [  ]
2 B   demo989  15800 15000  [  ] [  ] [  ] [  ]
              My cards are: [Jd] [Qd] [2h] [Qs]
demo990 folds due to being a no-show
Uncalled 5800 returned to demo989

It looks like there are some assumptions in the code about not being able to fold when all-in. It should be easy enough to reproduce and then fix.

[ctm]

I got a different panic (but presumably due to the same issue) when I changed the starting stack from T20,000 to T200 in BBBR, called the initial bet and then let the other player be a no-show:

thread '<unnamed>' panicked at 'attempt to subtract with overflow', mb2/src/table.rs:2688:9
...
  16:        0x10816eaf1 - mb2::table::Table::fold::h64d0701055e8e55e
                               at /Users/ctm/poker/rust/poker/mb2/src/table.rs:2688:9
  17:        0x10816d931 - mb2::table::Table::muck_no_show::hb556e5960dc8a357
                               at /Users/ctm/poker/rust/poker/mb2/src/table.rs:2542:9

I'll see if I can quickly come up with the other panic. I believe I know how to fix them both, but I don't want to fix this new one before reproducing the previous one.

[ctm]

Just not doing the initial call is sufficient to get the original panic, so I will now put in a fix that I think will solve both. Unfortunately, there still could be other trouble associated with no-shows and bring-ins.

[ctm]

FWIW, I don't get either of those panics, but I'm seeing:

2021-02-07 13:57:21,072 WARN [mb2::table] table 1341: 1171 bust by ghost, seat: SeatIndex(0), seat_bounties: {}

So, I'll fix that issue before deploying.

[ctm]

Deployed.