Generated from the shipped type definitions.
Where a command was invoked from — SourceMod's *reply source*. Set by the dispatch path and
exposed as CommandInvocation.replySource; it is what CommandInvocation.reply
routes on.
- "server" — the server console or rcon (callerSlot is -1)
- "console" — a player's own developer console
- "chat" — a ! or / chat trigger
The parsed invocation handed to a command callback: who called it, its arguments (multiple typed
accessors), and a caller-appropriate reply channel. It is a plain object that captures no native
handle, so it MAY be retained and used after an await/.then — a deferred reply (e.g. from
inside delay(...).then(...) or an async DB/HTTP call) is safe to call once the awaited work
completes.
What it captures, though, is the caller's **slot** — not a stable identity. If the original caller
disconnects before the deferred reply runs and a different player has since taken that slot, the
reply routes to (or targets the console/chat channel of) whoever now occupies it, not the original
caller. Prefer replying synchronously where the timing matters, or re-check the caller (e.g. via
their user id) before trusting a slot held across a long-running await.
A parsed chat trigger: which command + args, and whether it was the silent (/) trigger.
Command-registry utilities: dispatch by name, parse/route chat triggers, and enumerate the global
registry. Commands themselves are registered through the plugin context (ctx.commands.register*).
import { Commands } from "@s2script/sdk/commands";
// sm_help backend: every registered command + its required admin flag mask.
const cmds = Commands.list().slice().sort((a, b) => (a.name < b.name ? -1 : 1));