Button didn't move in Bomb Pot Double Board NLHE & PLO mix

[ctm]

Make the button move.

I don't know if this was in both NLHE & PLO, but it definitely happened.

[ts4z]

both NLHE & PLO

[ctm]

I'm just starting working on this now. I expect it will be drop dead simple. I'm getting a late start due to my laptop being ready to be picked up on my way back from King of the Hill. So not only have I been putting things away from KotH, but I've been pushing around some files from my backup laptop.

I'll be gobsmacked if I don't have this fixed well before this evening's game.

[ctm]

Table's advance_button contains:

        if let Some(ref blinds) = self.blind_seats {

and of course commit #b9511d95 contains:

diff --git a/mb2/src/tournament/structure/bomb_pot_double_nlhe_plo.rs b/mb2/src/tournament/structure/bomb_pot_double_nlhe_plo.rs
index bb007692..09230a24 100644
--- a/mb2/src/tournament/structure/bomb_pot_double_nlhe_plo.rs
+++ b/mb2/src/tournament/structure/bomb_pot_double_nlhe_plo.rs
@@ -60,7 +60,7 @@ pub(crate) fn bomb_pot_double_nlhe_plo() -> TournamentStructure {
         let stakes = Stakes {
             bring_in: None,
             split_bets: Some((ante.into(), ante.into())),
-            blinds: Some((0.into(), 0.into())),
+            blinds: None,
...

because it was taking the 0 big blind as a sign that there were blinds and therefore the minimum bet had effectively been made on the flop.

So, I need to keep blinds as None, but I need to look for another way to determine if we should advance the button. At first glance it appears that introducing a uses_button predicate to the GameGroup trait is the way to go, although that leaves room for many regressions since if we use that as the source of truth and then botch it for some odd game, that odd game will then regress.

However, GameGroup already has a has_blinds predicate and it's quite possible that blind_seats is set from that, so there may be some "safe" examination of has_blinds (or the code that sets up blind_seats) that can be used.

Ugh.

[ctm]

FWIW, the first code snippet comes from advance_button_via_blinds and not advance_button, so the exact problem is different, but the cause is the same.

[ctm]

Turns out button_must_move is already a predicate in GameGroup, so it was just a matter of patching hold_em.rs and omaha.rs:

diff --git a/lib/commands/src/game/omaha.rs b/lib/commands/src/game/omaha.rs
index 3b03078b..fd445468 100644
--- a/lib/commands/src/game/omaha.rs
+++ b/lib/commands/src/game/omaha.rs
@@ -86,6 +86,16 @@ impl Omaha {
 }

 impl GameGroup for Omaha {
+    fn button_must_move(&self) -> bool {
+        // This may seem strange, but any game with blinds will
+        // automatically move the button. However, bomb_pot doesn't
+        // have blinds so we return true in that case.  In the future,
+        // there might be other places where we need to return true,
+        // but this is the conservative way to fix the non-moving
+        // button issue. #1344.
+        self.bomb_pot
+    }
+

Deploying now.