@helyx/module-counting

Counting runs one durable, server-scoped number sequence in a configured Discord channel. Atomic updates prevent duplicate gateway deliveries and concurrent workers from advancing the game twice.

Availability and deployment

Counting is Live and supported by Hosted Helyx and Helyx Self-Hosted. It uses Helyx runtime services and Discord capabilities available in both deployment modes.

What it does

Members take turns posting the next bare base-10 integer. Managers choose the starting number, direction, interval, optional target, target behavior, member cooldown, and handling for incorrect or non-number messages. A game can be inspected, reset, or deleted from its dashboard resource page.

Commands and interactions

| Path | Default access | Purpose | | ----------------- | -------------- | ------------------------------------------------ | | /games counting | Everyone | Privately show the current game and next number. |

Messages in the configured channel are handled only while the module and game are active. The eligibility check is read-only; durable game creation and updates occur within the execution boundary.

Dashboard configuration

The dashboard defines the game channel and sequence rules. Saving settings does not silently reset an existing game; use the confirmed Reset game action to apply a new starting state. Deleting a game tombstones it so ordinary message traffic cannot recreate it, while the explicit create action can start it again.

Discord requirements

Counting needs View Channel, Send Messages, and Manage Messages in its configured channel. The Message Content privileged intent is required solely to parse new candidate messages. It does not require Administrator or Server Members.

Data, privacy and retention

The game record retains bounded sequence state and the last participant reference. Accepted entries retain server, message, member, numeric, generation, and timestamp fields for 30 days. Incorrect content and message text are not retained. Privacy access and erasure cover participant references even while Counting is disabled.

Operations and failure behavior

Accepted entries, their audit record, retention schedule, and achievement-delivery task commit atomically using optimistic concurrency. Optional module Logging cannot fail an accepted entry or dashboard reset. Shared statistics and achievement events use idempotency keys so retries do not double-count activity. Missing required gameplay services are reported as unhealthy.

Documentation and support

See the Counting guide, commands, permissions, and FAQ.