@s2script/sdk 0.6.0 → 0.8.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/chat.d.ts +7 -2
- package/commands.d.ts +10 -1
- package/dist/cli.js +3877 -1220
- package/package.json +5 -5
- package/transmit.d.ts +1 -1
- package/usercmd.d.ts +1 -1
- package/usermessages.d.ts +1 -1
package/chat.d.ts
CHANGED
|
@@ -11,8 +11,13 @@ export declare const Chat: {
|
|
|
11
11
|
/**
|
|
12
12
|
* An opaque prefix prepended to every chat message (NOT rcon/console replies). Color is content the
|
|
13
13
|
* caller owns (SourceMod-parity), so the engine-generic layer never picks one. A game/plugin sets this
|
|
14
|
-
* to a color control byte — e.g. `Chat.color = ChatColors.Green` from `@s2script/cs2`. `""` =
|
|
15
|
-
*
|
|
14
|
+
* to a color control byte — e.g. `Chat.color = ChatColors.Green` from `@s2script/cs2`. `""` = no prefix.
|
|
15
|
+
* A message may also embed its own colors mid-string.
|
|
16
|
+
*
|
|
17
|
+
* You do NOT need a leading space for color to render: every chat line is auto-prefixed with an invisible
|
|
18
|
+
* zero-width space (U+200B) so a Source 2 chat box doesn't swallow the message's first color byte. Just
|
|
19
|
+
* write `Chat.toSlot(slot, ChatColors.Green + "hi")` — the green lands. (Idempotent: a line you already
|
|
20
|
+
* lead with a space or a ZWSP is passed through unchanged.)
|
|
16
21
|
*/
|
|
17
22
|
color: string;
|
|
18
23
|
/** Print to the chat of the client in `slot` (0-based). */
|
package/commands.d.ts
CHANGED
|
@@ -13,7 +13,16 @@ export type ReplySource = "server" | "console" | "chat";
|
|
|
13
13
|
|
|
14
14
|
/**
|
|
15
15
|
* The parsed invocation handed to a command callback: who called it, its arguments (multiple typed
|
|
16
|
-
* accessors), and a caller-appropriate `reply` channel.
|
|
16
|
+
* accessors), and a caller-appropriate `reply` channel. It is a plain object that captures no native
|
|
17
|
+
* handle, so it MAY be retained and used after an `await`/`.then` — a deferred `reply` (e.g. from
|
|
18
|
+
* inside `delay(...).then(...)` or an async DB/HTTP call) is safe to call once the awaited work
|
|
19
|
+
* completes.
|
|
20
|
+
*
|
|
21
|
+
* What it captures, though, is the caller's **slot** — not a stable identity. If the original caller
|
|
22
|
+
* disconnects before the deferred reply runs and a different player has since taken that slot, the
|
|
23
|
+
* reply routes to (or targets the console/chat channel of) whoever now occupies it, not the original
|
|
24
|
+
* caller. Prefer replying synchronously where the timing matters, or re-check the caller (e.g. via
|
|
25
|
+
* their user id) before trusting a slot held across a long-running await.
|
|
17
26
|
*/
|
|
18
27
|
export interface CommandInvocation {
|
|
19
28
|
/** 0-based caller slot, or -1 for the server console. */
|