هذه المقالة غير متوفرة بلغتك بعد. مصدرها باللغة الإنجليزية معروض أدناه.

Keep four kinds of authority separate

  • A remote room capability such as operator controls what the Total Battle provider permits in that room.
  • A Runekist role controls who may start a clan-scoped action. The chat page requires an active Leader or Superior for these changes.
  • A Total Battle clan rank is roster evidence used for selection and batch actions; it does not grant a Runekist role.
  • An exact player SUID identifies the remote target. A nickname or display name never authorizes membership or a mutation.

Runekist re-checks these boundaries when a queued action runs. A confirmation is not permission to continue after the actor, clan, room, or target changes.

Read the current-player snapshot

Current players shows the Total Battle name, exact SUID, latest safe roster match when available, operator state, and muted state. Runekist follows provider cursors to save one complete roster, searches that complete snapshot by nickname or exact ID, and paginates filtered results locally. Search and page changes do not fetch another provider page while the saved snapshot is usable.

If no complete snapshot exists, refresh and check room health. A failed, rate-limited, malformed, or incomplete provider refresh never replaces the last complete snapshot and is never treated as proof of an empty room.

Choose players by roster or exact ID

Prefer Invite a clan member. It searches the current member-mapping roster by member name or exact Total Battle ID and shows both values so duplicate names remain distinguishable. The selected immutable mapping revision supplies the clan-scoped membership set and exact identities.

If the source is missing, stale, empty, or identity-incomplete, the picker explains what needs attention and does not search application-wide Total Battle or provider users by nickname. Refresh the authoritative source before using a manual exception.

Use Invite by exact ID only when the player has confirmed the intended subaccount SUID. Under Clan + invited or Invite only, a successful Runekist invite grants durable invited access. In Clan only, a one-off outsider can be removed by later reconciliation. The bot and existing remote operators are protected.

Find your Total Battle ID

An invitation needs the exact Total Battle subaccount or progress that should join the room, not an overall account or profile identifier.

  • Mobile: open Menu, then Accounts.
  • Desktop/web: open Accounts from the account area in the top-right.

In the account switcher, find the intended subaccount or progress and use the copy icon beside that subaccount's ID. Use that copied value in Invite by exact ID or send it privately to the clan leader. If the player appears in the current roster picker, select that row instead.

Manage invited access

Clan + invited combines the current mapping-backed clan set with active exact- SUID exceptions added through Runekist. Invite only is roster-independent: it retains the Runekist account, protected operators, configured allowlist entries, and active exact-SUID exceptions, but not ordinary clan-roster members. Under either invited policy, full reconciliation may re-invite an absent listed player. Remove access revokes an absent player's local exception without claiming a remote kick. A successful Kick revokes the active exception as part of that action.

Switching between Clan + invited and Invite only keeps entries active. Switching to Clan only or Open retains entries but makes them inactive; deliberately returning to either invited policy activates them again. Under Clan + invited, an invited-access removal does not override the current clan roster: an eligible clan member can be invited again. Under Invite only, roster membership alone does not restore access.

Act by clan rank

The TB · rank badge is an effective selection rank for the current mapping roster, enriched with the latest available Clan Capital rank facts. For a safely matched active registered member, Runekist can map the current membership role into the game hierarchy; the observed rank remains in audit provenance. The badge is not authorization.

Use Act by clan rank to select one or more effective ranks and preview either invitations or operator promotions. Runekist reloads the mapping roster and room state, then explains missing IDs, already-complete players, and players not currently in the room. Confirmation creates one audited, retry-safe action per exact player. If roster or room state changes, the preview expires and must be reviewed again. Rank actions are unavailable when Clan Capital rank facts are disabled, stale, or incomplete; manual exact-ID invite remains the explicit fallback.

Manage room operators

Use Make operator or Remove operator, then review the exact player and room. These actions are safe to retry: an already-complete remote state is recorded without applying a second change.

The Runekist account must remain a remote operator for mutable management and cannot be targeted as an ordinary player. Other remote operators are protected from mute, kick, ban, and roster removal. Removing someone's operator role changes provider capability only; it does not remove them from the room or change their Runekist role or Total Battle clan rank.

Send a message as Runekist

Send message as Runekist is a deliberate two-step workflow:

  1. Write plain text and choose Review message.
  2. Confirm the exact room and final text before the action is queued.

The body is limited to 500 graphemes and 2,000 UTF-8 bytes. Emoji and control characters are rejected. This protects a predictable plain-text provider path; it is not a rich-text or attachment feature.

Sending is unavailable while the binding is disabled or locally read-only, or when the Runekist account lacks the required remote capability. Execution re-checks active leadership, the same clan and binding lifecycle, enabled and read-only state, and operator capability. Retrying the same accepted action is idempotent: Runekist does not intentionally send a second copy after a recorded provider success, and retryable provider/rate errors continue through the same audit action.

The action history shows the Runekist-authored message body with its action state and time. That outbound body is retained in the action audit; it is not covered by the separate rule that observed inbound room bodies are not stored. Use privacy and retention for the different retention windows.

تصفح المساعدة