This describes the current game phase.
Note: It doesn't always move forward. Sometimes the system will correct itself
due to cards being occluded or intentionally moved.
When the round is over we go to DEALER_DONE.
In some situations we cannot determine if the round is over without more context
so we go to DEALER_MAYBE_DONE. For example: All players have busted,
but the dealer has to finish playing the hand anyways because of a side bet.
At the end we will go into ROUND_OVER if the round is supposed to be stored, and into
ROUND_CANCELED if we classify it as sensor noise.
This state will only be reached once, you should not miss this event.
We use this to mark what rounds we store in the database or show on the screen.
Even rounds with wrong dealer procedure will reach ROUND_OVER, they are marked
as such in the anomalies / diagnostics fields.
The length of this list is fixed and determined with the calibration procedure.
No Additional ItemsPlayers consist of 0 or more stacks. If the player has 0 stacks, it is inactive. If the player has >1 stack, then the player has split its cards.
No Additional ItemsThe cards might be removed as the system handles movement and occlusions.
No Additional ItemsMust contain a minimum of 2 items
Must contain a maximum of 2 items
Whether the stack was doubled.
All chip stacks associated with this player.
Must contain a minimum of 2 items
Must contain a maximum of 2 items
Contains the info about the dealer (mainly cards). Note: We don't guarantee that we won't take cards out of here. You should treat this as our current best guess for what cards are actually on the table, while handling occlusions, lighting changes, etc. The final value for the dealer cards is given when the phase is ROUND_OVER.
The number of frames since this round was started.
Used to communicate issues with this round. This is unstable in this form and undocumented. In the future we can expose a structured stable API here. We use it to identify: errors in the dealer procedure, issues with our system for debugging.
No Additional ItemsThe timestamp when this round was initialized. It also includes the number of frames passed since round begin.
The timestamp when a first card was assigned to the round. This is later than the initialization timestamp, because a round can be initialized by chip stack detections.
Must contain a minimum of 2 items
Must contain a maximum of 2 items
This describes the current game phase.
Note: It doesn't always move forward. Sometimes the system will correct itself
due to cards being occluded or intentionally moved.
When the round is over we go to DEALER_DONE.
In some situations we cannot determine if the round is over without more context
so we go to DEALER_MAYBE_DONE. For example: All players have busted,
but the dealer has to finish playing the hand anyways because of a side bet.
At the end we will go into ROUND_OVER if the round is supposed to be stored, and into
ROUND_CANCELED if we classify it as sensor noise.
This state will only be reached once, you should not miss this event.
We use this to mark what rounds we store in the database or show on the screen.
Even rounds with wrong dealer procedure will reach ROUND_OVER, they are marked
as such in the anomalies / diagnostics fields.
UUID v4. It is generated each new round. A round starts as soon as anything relevant is detected. Currently 'anything relevant' means cards, chips or cash. The latter two are only considered if these models are deployed and configured. Not every UUID should be treated as a full round — it might be canceled and never reach ROUNDOVER but only ROUNDCANCELED. Example: a chip stack is recognized and then disappears.
Side bet payout results for all players in the current round.
Sent whenever the results change. Will be sent multiple times per round as more cards are revealed.
The UUID of the round these results belong to.
One entry per player.
No Additional Items0-based index of the player, matching the players array in TcsAPI.
One entry per configured side bet for this player.
No Additional ItemsThe name of the side bet (e.g. '21+3', 'PerfectPairs').
True if the player placed a bet on this side bet this round.
The payout result for this side bet. NotYetDetermined if the round has not progressed far enough to calculate the result. PayoutTableUnknown if no payout table is configured for this side bet.
The side bet outcome has been fully evaluated.
outcome is a string label for the winning hand category (e.g. "STRAIGHT_FLUSH",
"PERFECT_PAIRS") or "LOSS" when the player loses. It is a plain string rather than
an enumeration so that operator-configured side bets with arbitrary hand categories can be
supported in the future without changing this type.
payout encodes the multiplier applied to the player's stake:
- -1.0 — loss (stake forfeited)
- A positive float — win multiplier (e.g. 3.0 means 3 : 1)
- "MAJOR" / "MINOR" — jackpot tier whose exact value is resolved by the casino's
progressive payout system rather than a fixed multiplier.