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.
Whether the system can currently see the table. It reports at most one issue at a time, e.g. a camera that is not connected or that was moved out of position. This is sent as soon as the issue appears, not only on round changes.
kind
The machine readable issue, see CameraIssueKind.
message
The same issue as a sentence, meant to be shown to an operator. Unstable, don't parse it.
since
When the issue first appeared. Issues are reported as soon as they appear, including short
lived ones such as a stream that stalls for a second. Use since to alert only on issues
that persist.
The camera issues we report, most severe first.
NO_FRAMES
The camera delivers no frames at all. Usually it is not connected.
NOT_YET_CALIBRATED
The system has no table calibration (or no configured player positions) yet, so there is
nothing to judge the camera against. This is also reported while an operator is running the
calibration procedure.
CAMERA_MOVED
Configured table positions (the initial card and the main bet spot of a player) are outside
of the camera image. The camera has to be moved back, or the table has to be recalibrated.
LAYOUT_NOT_VISIBLE
We cannot recognize the table layout in the camera image and fall back to the calibrated
camera position. Usually the layout is covered, unlit, or the camera points somewhere else.
Only reported when the automatic homography is enabled: with it turned off, the calibrated
camera position is what the system is meant to run on.
This contains the side bet payout results for all active players in the current round.
A player position is seen as active any cards are assigned to it.
This is sent whenever the results change as more cards are revealed.
For most side bets the result is known when the player has its first two
cards and the dealer has an upcard.
The UUID of the round these results belong to.
One entry per active 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').
The id of the side bet (e.g. 'PP', 'S16'). This is the stable identifier the side bet is configured and keyed by; unlike the display name it is unique.
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)
- "GRAND" / "MAJOR" / "MINOR" — jackpot tier whose exact value is resolved by the
casino's progressive payout system rather than a fixed multiplier.