@rpgm-tools/neo-angband-mod-sdk 1.14.0 → 1.16.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/dist/capabilities.d.ts +30 -2
- package/dist/capabilities.d.ts.map +1 -1
- package/dist/capabilities.js +44 -2
- package/dist/capabilities.js.map +1 -1
- package/docs/MOD_LIFECYCLE.md +37 -16
- package/docs/MOD_REACH.md +1 -1
- package/docs/MOD_SEAMS.md +19 -2
- package/docs/PLUGINS.md +16 -2
- package/package.json +1 -1
- package/src/capabilities.ts +45 -2
package/dist/capabilities.d.ts
CHANGED
|
@@ -82,8 +82,11 @@
|
|
|
82
82
|
* "registry:tval" reaches every question core asks
|
|
83
83
|
* about an item CLASS - is it a weapon, can it be
|
|
84
84
|
* worn or flavoured, is it good, what is it worth
|
|
85
|
-
* unidentified
|
|
86
|
-
*
|
|
85
|
+
* unidentified, and what a mod may adjust a
|
|
86
|
+
* computed real value TO once core's own faithful
|
|
87
|
+
* pricing has run (`valueAdjust`, keyed on tval).
|
|
88
|
+
* Distinct from shipping a new ITEM, which needs
|
|
89
|
+
* no capability at all.
|
|
87
90
|
* "registry:vocab" (W2.3) declares
|
|
88
91
|
* NEW vocabulary (flags/stats/any kind). Distinct
|
|
89
92
|
* from "command:add": that adds a command via the
|
|
@@ -155,6 +158,28 @@
|
|
|
155
158
|
* sold under the other's sentence. It is a shorter
|
|
156
159
|
* LIFETIME for the archive and not a smaller reach for
|
|
157
160
|
* the records: what composes, composes.
|
|
161
|
+
* - "mod:read" - resolve a repository reference through the SAME
|
|
162
|
+
* resolver the "install from a repository" door
|
|
163
|
+
* uses (the tags call, the channel filter, the
|
|
164
|
+
* manifest read at each candidate tag until one is
|
|
165
|
+
* engine-compatible), and hand back its manifest
|
|
166
|
+
* and payload listing. Nothing is installed and
|
|
167
|
+
* nothing is written to the player's library. Its
|
|
168
|
+
* own kind, like "backup:folder" and
|
|
169
|
+
* "display:replace": there is nothing to range
|
|
170
|
+
* over, so it has no wildcard either, and neither
|
|
171
|
+
* "mod:install" nor "mod:session" covers it - a
|
|
172
|
+
* mod that may put a pack in the library has not
|
|
173
|
+
* thereby been allowed to make network requests on
|
|
174
|
+
* the player's behalf to look one up. It is also
|
|
175
|
+
* not a "network:<host>" grant: that family gates
|
|
176
|
+
* a different, agent-facing door, and in-process
|
|
177
|
+
* plugin code can already fetch for itself with no
|
|
178
|
+
* capability at all (see this file's own header).
|
|
179
|
+
* What this buys is that the answer came from the
|
|
180
|
+
* host's own resolution rules rather than a
|
|
181
|
+
* second copy of them that could accept a
|
|
182
|
+
* reference the real installer would refuse.
|
|
158
183
|
* - "debug:spawn" - conjure an item or a creature into the live game the
|
|
159
184
|
* way the debug commands do. Its own kind and no
|
|
160
185
|
* wildcard, and here that is the whole point rather
|
|
@@ -251,6 +276,9 @@ export type ParsedCapability = {
|
|
|
251
276
|
} | {
|
|
252
277
|
kind: "mod";
|
|
253
278
|
action: "install" | "session";
|
|
279
|
+
} | {
|
|
280
|
+
kind: "mod-read";
|
|
281
|
+
action: "read";
|
|
254
282
|
} | {
|
|
255
283
|
kind: "debug";
|
|
256
284
|
action: "spawn" | "wizard";
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"capabilities.d.ts","sourceRoot":"","sources":["../src/capabilities.ts"],"names":[],"mappings":"AAAA
|
|
1
|
+
{"version":3,"file":"capabilities.d.ts","sourceRoot":"","sources":["../src/capabilities.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoPG;AAEH,OAAO,EAAY,KAAK,YAAY,EAAE,MAAM,eAAe,CAAC;AAE5D,qBAAa,eAAgB,SAAQ,KAAK;CAAG;AAE7C,2DAA2D;AAC3D,MAAM,MAAM,gBAAgB,GACxB;IAAE,IAAI,EAAE,SAAS,CAAC;IAAC,MAAM,EAAE,KAAK,CAAA;CAAE,GAClC;IAAE,IAAI,EAAE,OAAO,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,GAC/B;IAAE,IAAI,EAAE,OAAO,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,MAAM,EAAE,MAAM,CAAA;CAAE,GACjD;IAAE,IAAI,EAAE,SAAS,CAAC;IAAC,IAAI,EAAE,MAAM,CAAA;CAAE,GACjC;IAAE,IAAI,EAAE,UAAU,CAAC;IAAC,MAAM,EAAE,MAAM,CAAA;CAAE,GACpC;IAAE,IAAI,EAAE,SAAS,CAAC;IAAC,MAAM,EAAE,SAAS,GAAG,QAAQ,CAAA;CAAE,GACjD;IAAE,IAAI,EAAE,IAAI,CAAC;IAAC,MAAM,EAAE,MAAM,CAAC;IAAC,MAAM,EAAE,SAAS,GAAG,QAAQ,GAAG,OAAO,CAAA;CAAE,GACtE;IAAE,IAAI,EAAE,QAAQ,CAAC;IAAC,MAAM,EAAE,QAAQ,CAAA;CAAE,GACpC;IAAE,IAAI,EAAE,KAAK,CAAC;IAAC,MAAM,EAAE,SAAS,GAAG,SAAS,CAAA;CAAE,GAC9C;IAAE,IAAI,EAAE,UAAU,CAAC;IAAC,MAAM,EAAE,MAAM,CAAA;CAAE,GACpC;IAAE,IAAI,EAAE,OAAO,CAAC;IAAC,MAAM,EAAE,OAAO,GAAG,QAAQ,CAAA;CAAE,GAC7C;IAAE,IAAI,EAAE,QAAQ,CAAC;IAAC,MAAM,EAAE,OAAO,CAAA;CAAE,GACnC;IAAE,IAAI,EAAE,OAAO,CAAC;IAAC,MAAM,EAAE,UAAU,CAAA;CAAE,GACrC;IAAE,IAAI,EAAE,QAAQ,CAAC;IAAC,MAAM,EAAE,SAAS,CAAA;CAAE,GACrC;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,MAAM,EAAE,SAAS,CAAA;CAAE,GACnC;IAAE,IAAI,EAAE,sBAAsB,CAAC;IAAC,MAAM,EAAE,SAAS,CAAA;CAAE,GACnD;IAAE,IAAI,EAAE,WAAW,CAAC;IAAC,MAAM,EAAE,OAAO,CAAA;CAAE,CAAC;AAyE3C;;;;;;GAMG;AACH,wBAAgB,eAAe,CAAC,GAAG,EAAE,MAAM,GAAG,gBAAgB,CA8G7D;AAsGD;;;;GAIG;AACH,qBAAa,aAAa;IACxB,OAAO,CAAC,QAAQ,CAAC,MAAM,CAA8B;IACrD,OAAO,CAAC,QAAQ,CAAC,gBAAgB,CAAU;IAC3C,OAAO,CAAC,QAAQ,CAAC,eAAe,CAAU;IAE1C,OAAO;IAUP;;;;;;;OAOG;IACH,MAAM,CAAC,YAAY,CAAC,QAAQ,EAAE,YAAY,GAAG,aAAa;IAgB1D;;;;OAIG;IACH,GAAG,CAAC,GAAG,EAAE,MAAM,GAAG,OAAO;IAKzB;;;;;OAKG;IACH,KAAK,CAAC,GAAG,EAAE,MAAM,GAAG,IAAI;IAOxB,0EAA0E;IAC1E,kBAAkB,IAAI,OAAO;IAI7B,6DAA6D;IAC7D,iBAAiB,IAAI,OAAO;CAG7B"}
|
package/dist/capabilities.js
CHANGED
|
@@ -82,8 +82,11 @@
|
|
|
82
82
|
* "registry:tval" reaches every question core asks
|
|
83
83
|
* about an item CLASS - is it a weapon, can it be
|
|
84
84
|
* worn or flavoured, is it good, what is it worth
|
|
85
|
-
* unidentified
|
|
86
|
-
*
|
|
85
|
+
* unidentified, and what a mod may adjust a
|
|
86
|
+
* computed real value TO once core's own faithful
|
|
87
|
+
* pricing has run (`valueAdjust`, keyed on tval).
|
|
88
|
+
* Distinct from shipping a new ITEM, which needs
|
|
89
|
+
* no capability at all.
|
|
87
90
|
* "registry:vocab" (W2.3) declares
|
|
88
91
|
* NEW vocabulary (flags/stats/any kind). Distinct
|
|
89
92
|
* from "command:add": that adds a command via the
|
|
@@ -155,6 +158,28 @@
|
|
|
155
158
|
* sold under the other's sentence. It is a shorter
|
|
156
159
|
* LIFETIME for the archive and not a smaller reach for
|
|
157
160
|
* the records: what composes, composes.
|
|
161
|
+
* - "mod:read" - resolve a repository reference through the SAME
|
|
162
|
+
* resolver the "install from a repository" door
|
|
163
|
+
* uses (the tags call, the channel filter, the
|
|
164
|
+
* manifest read at each candidate tag until one is
|
|
165
|
+
* engine-compatible), and hand back its manifest
|
|
166
|
+
* and payload listing. Nothing is installed and
|
|
167
|
+
* nothing is written to the player's library. Its
|
|
168
|
+
* own kind, like "backup:folder" and
|
|
169
|
+
* "display:replace": there is nothing to range
|
|
170
|
+
* over, so it has no wildcard either, and neither
|
|
171
|
+
* "mod:install" nor "mod:session" covers it - a
|
|
172
|
+
* mod that may put a pack in the library has not
|
|
173
|
+
* thereby been allowed to make network requests on
|
|
174
|
+
* the player's behalf to look one up. It is also
|
|
175
|
+
* not a "network:<host>" grant: that family gates
|
|
176
|
+
* a different, agent-facing door, and in-process
|
|
177
|
+
* plugin code can already fetch for itself with no
|
|
178
|
+
* capability at all (see this file's own header).
|
|
179
|
+
* What this buys is that the answer came from the
|
|
180
|
+
* host's own resolution rules rather than a
|
|
181
|
+
* second copy of them that could accept a
|
|
182
|
+
* reference the real installer would refuse.
|
|
158
183
|
* - "debug:spawn" - conjure an item or a creature into the live game the
|
|
159
184
|
* way the debug commands do. Its own kind and no
|
|
160
185
|
* wildcard, and here that is the whole point rather
|
|
@@ -334,6 +359,17 @@ export function parseCapability(cap) {
|
|
|
334
359
|
if (cap === "mod:session") {
|
|
335
360
|
return { kind: "mod", action: "session" };
|
|
336
361
|
}
|
|
362
|
+
/* "mod:read": resolve a repository reference through the SAME resolver the
|
|
363
|
+
* install door uses and hand back its manifest and payload listing, without
|
|
364
|
+
* installing anything. A DIFFERENT kind from "mod", not a third action on
|
|
365
|
+
* it - "install" and "session" are two ways to put a pack IN the library,
|
|
366
|
+
* and this puts nothing anywhere, so "mod:*" covering it would be exactly
|
|
367
|
+
* the escalation grantCovers's action comparison exists to refuse. Its own
|
|
368
|
+
* kind, no wildcard, same reasoning as "backup:folder": there is nothing to
|
|
369
|
+
* range over. */
|
|
370
|
+
if (cap === "mod:read") {
|
|
371
|
+
return { kind: "mod-read", action: "read" };
|
|
372
|
+
}
|
|
337
373
|
/* "debug:spawn": put an item or a creature into the live game the way the debug
|
|
338
374
|
* commands do, marking the character the way they do. Its own kind and no
|
|
339
375
|
* wildcard on purpose - a player asking "which of my mods can conjure things"
|
|
@@ -439,6 +475,12 @@ function grantCovers(grant, request) {
|
|
|
439
475
|
* session. Neither is a superset of the other, there is no wildcard, and a
|
|
440
476
|
* kind-only comparison would have let one consent buy both. */
|
|
441
477
|
return grant.kind === "mod" && grant.action === request.action;
|
|
478
|
+
case "mod-read":
|
|
479
|
+
/* Exact match only, same reasoning as "backup" - there is exactly one
|
|
480
|
+
* mod-read capability and no wildcard grant could ever cover it, and
|
|
481
|
+
* neither "mod:install" nor "mod:session" reaches here: they are a
|
|
482
|
+
* different `kind` entirely, not a wider action of the same one. */
|
|
483
|
+
return grant.kind === "mod-read";
|
|
442
484
|
case "debug":
|
|
443
485
|
/* Exact match only, and here that is the point rather than a consequence:
|
|
444
486
|
* this is the grant a player is most likely to check for by name, so it
|
package/dist/capabilities.js.map
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"capabilities.js","sourceRoot":"","sources":["../src/capabilities.ts"],"names":[],"mappings":"AAAA
|
|
1
|
+
{"version":3,"file":"capabilities.js","sourceRoot":"","sources":["../src/capabilities.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GAoPG;AAEH,OAAO,EAAE,QAAQ,EAAqB,MAAM,eAAe,CAAC;AAE5D,MAAM,OAAO,eAAgB,SAAQ,KAAK;CAAG;AAsB7C,MAAM,QAAQ,GAAG,2BAA2B,CAAC;AAC7C;;;;;;;;;;;;GAYG;AACH,MAAM,KAAK,GAAG,wDAAwD,CAAC;AACvE;;;;;;;;;;;;;;;;;;;;GAoBG;AACH,MAAM,YAAY,GAAG,qBAAqB,CAAC;AAC3C;;;;;;;;;;;;;;;;;;;;;;;;;;GA0BG;AACH,MAAM,WAAW,GAAG,mBAAmB,CAAC;AACxC,MAAM,QAAQ,GAAG,oCAAoC,CAAC;AACtD,MAAM,UAAU,GAAG,+BAA+B,CAAC;AACnD,yEAAyE;AACzE,MAAM,WAAW,GACf,iJAAiJ,CAAC;AAEpJ;;;;;;GAMG;AACH,MAAM,UAAU,eAAe,CAAC,GAAW;IACzC,IAAI,GAAG,KAAK,aAAa,EAAE,CAAC;QAC1B,OAAO,EAAE,IAAI,EAAE,SAAS,EAAE,MAAM,EAAE,KAAK,EAAE,CAAC;IAC5C,CAAC;IACD;;;;+DAI2D;IAC3D,IAAI,GAAG,KAAK,iBAAiB,IAAI,GAAG,KAAK,gBAAgB,EAAE,CAAC;QAC1D,OAAO,EAAE,IAAI,EAAE,SAAS,EAAE,MAAM,EAAE,GAAG,KAAK,iBAAiB,CAAC,CAAC,CAAC,SAAS,CAAC,CAAC,CAAC,QAAQ,EAAE,CAAC;IACvF,CAAC;IACD;;;oFAGgF;IAChF,IAAI,GAAG,KAAK,eAAe,EAAE,CAAC;QAC5B,OAAO,EAAE,IAAI,EAAE,QAAQ,EAAE,MAAM,EAAE,QAAQ,EAAE,CAAC;IAC9C,CAAC;IACD;;;;oFAIgF;IAChF,IAAI,GAAG,KAAK,aAAa,EAAE,CAAC;QAC1B,OAAO,EAAE,IAAI,EAAE,KAAK,EAAE,MAAM,EAAE,SAAS,EAAE,CAAC;IAC5C,CAAC;IACD;;;;;;oFAMgF;IAChF,IAAI,GAAG,KAAK,aAAa,EAAE,CAAC;QAC1B,OAAO,EAAE,IAAI,EAAE,KAAK,EAAE,MAAM,EAAE,SAAS,EAAE,CAAC;IAC5C,CAAC;IACD;;;;;;;qBAOiB;IACjB,IAAI,GAAG,KAAK,UAAU,EAAE,CAAC;QACvB,OAAO,EAAE,IAAI,EAAE,UAAU,EAAE,MAAM,EAAE,MAAM,EAAE,CAAC;IAC9C,CAAC;IACD;;;;+BAI2B;IAC3B,IAAI,GAAG,KAAK,aAAa,EAAE,CAAC;QAC1B,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,EAAE,OAAO,EAAE,CAAC;IAC5C,CAAC;IACD;;;;;;;;;mBASe;IACf,IAAI,GAAG,KAAK,cAAc,EAAE,CAAC;QAC3B,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,EAAE,QAAQ,EAAE,CAAC;IAC7C,CAAC;IACD,IAAI,GAAG,KAAK,cAAc,EAAE,CAAC;QAC3B,OAAO,EAAE,IAAI,EAAE,QAAQ,EAAE,MAAM,EAAE,OAAO,EAAE,CAAC;IAC7C,CAAC;IACD,IAAI,GAAG,KAAK,gBAAgB;QAAE,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,EAAE,UAAU,EAAE,CAAC;IAC3E,IAAI,GAAG,KAAK,gBAAgB;QAAE,OAAO,EAAE,IAAI,EAAE,QAAQ,EAAE,MAAM,EAAE,SAAS,EAAE,CAAC;IAC3E,IAAI,GAAG,KAAK,cAAc;QAAE,OAAO,EAAE,IAAI,EAAE,MAAM,EAAE,MAAM,EAAE,SAAS,EAAE,CAAC;IACvE,IAAI,GAAG,KAAK,kBAAkB;QAAE,OAAO,EAAE,IAAI,EAAE,sBAAsB,EAAE,MAAM,EAAE,SAAS,EAAE,CAAC;IAC3F,IAAI,GAAG,KAAK,WAAW;QAAE,OAAO,EAAE,IAAI,EAAE,WAAW,EAAE,MAAM,EAAE,OAAO,EAAE,CAAC;IACvE,MAAM,EAAE,GAAG,KAAK,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;IAC3B,IAAI,EAAE,EAAE,CAAC;QACP,OAAO,EAAE,IAAI,EAAE,IAAI,EAAE,MAAM,EAAE,EAAE,CAAC,CAAC,CAAW,EAAE,MAAM,EAAE,SAAS,EAAE,CAAC;IACpE,CAAC;IACD;;uEAEmE;IACnE,IAAI,YAAY,CAAC,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC;QAC3B,OAAO,EAAE,IAAI,EAAE,IAAI,EAAE,MAAM,EAAE,QAAQ,EAAE,MAAM,EAAE,QAAQ,EAAE,CAAC;IAC5D,CAAC;IACD;;6DAEyD;IACzD,IAAI,WAAW,CAAC,IAAI,CAAC,GAAG,CAAC,EAAE,CAAC;QAC1B,OAAO,EAAE,IAAI,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,MAAM,EAAE,OAAO,EAAE,CAAC;IAC1D,CAAC;IACD,MAAM,KAAK,GAAG,QAAQ,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;IACjC,IAAI,KAAK,EAAE,CAAC;QACV,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,IAAI,EAAE,KAAK,CAAC,CAAC,CAAW,EAAE,CAAC;IACrD,CAAC;IACD,MAAM,KAAK,GAAG,QAAQ,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;IACjC,IAAI,KAAK,EAAE,CAAC;QACV,OAAO,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,EAAE,KAAK,CAAC,CAAC,CAAW,EAAE,MAAM,EAAE,MAAM,EAAE,CAAC;IACvE,CAAC;IACD,MAAM,OAAO,GAAG,UAAU,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;IACrC,IAAI,OAAO,EAAE,CAAC;QACZ,OAAO,EAAE,IAAI,EAAE,SAAS,EAAE,IAAI,EAAE,OAAO,CAAC,CAAC,CAAW,EAAE,CAAC;IACzD,CAAC;IACD,MAAM,QAAQ,GAAG,WAAW,CAAC,IAAI,CAAC,GAAG,CAAC,CAAC;IACvC,IAAI,QAAQ,EAAE,CAAC;QACb,OAAO,EAAE,IAAI,EAAE,UAAU,EAAE,MAAM,EAAE,QAAQ,CAAC,CAAC,CAAW,EAAE,CAAC;IAC7D,CAAC;IACD,MAAM,IAAI,eAAe,CAAC,6BAA6B,GAAG,GAAG,CAAC,CAAC;AACjE,CAAC;AAED;;;;GAIG;AACH,SAAS,WAAW,CAAC,KAAuB,EAAE,OAAyB;IACrE,QAAQ,OAAO,CAAC,IAAI,EAAE,CAAC;QACrB,KAAK,SAAS;YACZ,OAAO,KAAK,CAAC,IAAI,KAAK,SAAS,CAAC;QAClC,KAAK,OAAO;YACV,OAAO,KAAK,CAAC,IAAI,KAAK,OAAO,IAAI,KAAK,CAAC,IAAI,KAAK,OAAO,CAAC,IAAI,CAAC;QAC/D,KAAK,OAAO;YACV,OAAO,CACL,KAAK,CAAC,IAAI,KAAK,OAAO;gBACtB,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM;gBAC/B,CAAC,KAAK,CAAC,MAAM,KAAK,GAAG,IAAI,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC,CAC1D,CAAC;QACJ,KAAK,SAAS;YACZ,OAAO,CACL,KAAK,CAAC,IAAI,KAAK,SAAS;gBACxB,CAAC,KAAK,CAAC,IAAI,KAAK,GAAG,IAAI,KAAK,CAAC,IAAI,KAAK,OAAO,CAAC,IAAI,CAAC,CACpD,CAAC;QACJ,KAAK,UAAU;YACb,OAAO,CACL,KAAK,CAAC,IAAI,KAAK,UAAU;gBACzB,CAAC,KAAK,CAAC,MAAM,KAAK,GAAG,IAAI,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC,CAC1D,CAAC;QACJ,KAAK,SAAS;YACZ;;wDAE4C;YAC5C,OAAO,KAAK,CAAC,IAAI,KAAK,SAAS,IAAI,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC;QACrE,KAAK,QAAQ;YACX;8EACkE;YAClE,OAAO,KAAK,CAAC,IAAI,KAAK,QAAQ,CAAC;QACjC,KAAK,KAAK;YACR;;;;2EAI+D;YAC/D,OAAO,KAAK,CAAC,IAAI,KAAK,KAAK,IAAI,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC;QACjE,KAAK,UAAU;YACb;;;gFAGoE;YACpE,OAAO,KAAK,CAAC,IAAI,KAAK,UAAU,CAAC;QACnC,KAAK,OAAO;YACV;;;;;;;;;sEAS0D;YAC1D,OAAO,KAAK,CAAC,IAAI,KAAK,OAAO,IAAI,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC;QACnE,KAAK,QAAQ;YACX,OAAO,KAAK,CAAC,IAAI,KAAK,QAAQ,IAAI,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC;QACpE,KAAK,OAAO;YACV,OAAO,KAAK,CAAC,IAAI,KAAK,OAAO,IAAI,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC;QACnE,KAAK,QAAQ;YACX,OAAO,KAAK,CAAC,IAAI,KAAK,QAAQ,IAAI,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC;QACpE,KAAK,MAAM;YACT,OAAO,KAAK,CAAC,IAAI,KAAK,MAAM,IAAI,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC;QAClE,KAAK,sBAAsB;YACzB,OAAO,KAAK,CAAC,IAAI,KAAK,sBAAsB,IAAI,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC;QAClF,KAAK,WAAW;YACd,OAAO,KAAK,CAAC,IAAI,KAAK,WAAW,IAAI,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC;QACvE,KAAK,IAAI;YACP;;;;;;;;;;;;;;;;;6BAiBiB;YACjB,OAAO,CACL,KAAK,CAAC,IAAI,KAAK,IAAI;gBACnB,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM;gBAC/B,CAAC,KAAK,CAAC,MAAM,KAAK,GAAG,IAAI,KAAK,CAAC,MAAM,KAAK,OAAO,CAAC,MAAM,CAAC,CAC1D,CAAC;IACN,CAAC;AACH,CAAC;AAED;;;;GAIG;AACH,MAAM,OAAO,aAAa;IACP,MAAM,CAA8B;IACpC,gBAAgB,CAAU;IAC1B,eAAe,CAAU;IAE1C,YACE,MAAmC,EACnC,gBAAyB,EACzB,eAAwB;QAExB,IAAI,CAAC,MAAM,GAAG,MAAM,CAAC;QACrB,IAAI,CAAC,gBAAgB,GAAG,gBAAgB,CAAC;QACzC,IAAI,CAAC,eAAe,GAAG,eAAe,CAAC;IACzC,CAAC;IAED;;;;;;;OAOG;IACH,MAAM,CAAC,YAAY,CAAC,QAAsB;QACxC,MAAM,SAAS,GAAG,QAAQ,CAAC,YAAY,IAAI,EAAE,CAAC;QAC9C,IAAI,CAAC,QAAQ,CAAC,QAAQ,EAAE,QAAQ,CAAC,IAAI,SAAS,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;YAC1D,MAAM,IAAI,eAAe,CACvB,QAAQ,QAAQ,CAAC,EAAE,uDAAuD;gBACxE,wBAAwB,QAAQ,CAAC,KAAK,IAAI,CAC7C,CAAC;QACJ,CAAC;QACD,MAAM,MAAM,GAAG,SAAS,CAAC,GAAG,CAAC,CAAC,GAAG,EAAE,EAAE,CAAC,eAAe,CAAC,GAAG,CAAC,CAAC,CAAC;QAC5D,OAAO,IAAI,aAAa,CACtB,MAAM,EACN,QAAQ,CAAC,gBAAgB,IAAI,KAAK,EAClC,QAAQ,CAAC,eAAe,IAAI,KAAK,CAClC,CAAC;IACJ,CAAC;IAED;;;;OAIG;IACH,GAAG,CAAC,GAAW;QACb,MAAM,OAAO,GAAG,eAAe,CAAC,GAAG,CAAC,CAAC;QACrC,OAAO,IAAI,CAAC,MAAM,CAAC,IAAI,CAAC,CAAC,KAAK,EAAE,EAAE,CAAC,WAAW,CAAC,KAAK,EAAE,OAAO,CAAC,CAAC,CAAC;IAClE,CAAC;IAED;;;;;OAKG;IACH,KAAK,CAAC,GAAW;QACf,IAAI,IAAI,CAAC,GAAG,CAAC,GAAG,CAAC;YAAE,OAAO;QAC1B,MAAM,IAAI,eAAe,CACvB,iCAAiC,GAAG,yCAAyC,CAC9E,CAAC;IACJ,CAAC;IAED,0EAA0E;IAC1E,kBAAkB;QAChB,OAAO,IAAI,CAAC,gBAAgB,CAAC;IAC/B,CAAC;IAED,6DAA6D;IAC7D,iBAAiB;QACf,OAAO,IAAI,CAAC,eAAe,CAAC;IAC9B,CAAC;CACF"}
|
package/docs/MOD_LIFECYCLE.md
CHANGED
|
@@ -283,27 +283,48 @@ which is correct, while a field the pack PATCHED on a core record simply returns
|
|
|
283
283
|
to its unpatched value, because a patch lives in the composition and not in the
|
|
284
284
|
save. `docs/PLANNED.md` carries the second as open work.
|
|
285
285
|
|
|
286
|
-
### From a git repository
|
|
287
|
-
|
|
288
|
-
|
|
289
|
-
|
|
290
|
-
|
|
291
|
-
|
|
292
|
-
|
|
293
|
-
|
|
286
|
+
### From a git repository
|
|
287
|
+
|
|
288
|
+
The heading used to read "(proposed design, not the shipped path)" and step 4
|
|
289
|
+
below used to carry its own `[PROPOSED]`. Step 4, the pre-install summary, is
|
|
290
|
+
now built (issue #23): `mod-preinstall.ts` (`packages/web/src`) reads the
|
|
291
|
+
candidate's own declared content files at its pinned tag and reports what it
|
|
292
|
+
adds, what it patches, replaces or removes - each touched record paired with
|
|
293
|
+
its owning pack and whether that owner is actually enabled right now, rather
|
|
294
|
+
than a claim about a load order nothing has composed yet - alongside its
|
|
295
|
+
capabilities (in `capability-describe.ts`'s own words, not a second copy of
|
|
296
|
+
them), license, and any `conflicts` claim that applies once the candidate
|
|
297
|
+
joins the player's enabled set in either direction (`mod-conflicts.ts`'s
|
|
298
|
+
`declaredConflicts`, reused rather than reimplemented). Size, author and
|
|
299
|
+
screenshots were already shown by discovery (`mod-discover.ts`) before this
|
|
300
|
+
work; the summary carries them alongside the new sections rather than
|
|
301
|
+
duplicating them. `mod-browse.ts`'s `showRepoInstallSummary` is what shows it,
|
|
302
|
+
between pasting a repository address and the existing install action - the
|
|
303
|
+
player confirms or cancels there, and confirming runs the same install path
|
|
304
|
+
(`installOne`) the other doors already use.
|
|
305
|
+
|
|
306
|
+
Steps 1, 3 and 5 remain `[PROPOSED]`: the shipped installer reads
|
|
307
|
+
`manifest.json` at a TAG and nothing else (no branch head and no bare commit),
|
|
308
|
+
a full schema/dependency-availability check still happens only at the actual
|
|
309
|
+
install rather than ahead of the summary, and an install still appends to the
|
|
310
|
+
load order rather than inserting at a dependency-resolved position. What the
|
|
311
|
+
installer actually does, including how it picks which release to offer and
|
|
312
|
+
what an install pins, is in [MOD_COMPATIBILITY.md](MOD_COMPATIBILITY.md) and
|
|
313
|
+
[../MODS.md](https://github.com/neostryder/neo-angband/blob/master/docs/MODS.md). The numbered list below is kept as the design of
|
|
314
|
+
record for where the rest of the installer is going.
|
|
294
315
|
|
|
295
316
|
The user pastes a repository URL (or picks a ref). The app:
|
|
296
317
|
|
|
297
|
-
1. Resolves a specific ref (tag preferred, else branch head, else
|
|
318
|
+
1. [PROPOSED] Resolves a specific ref (tag preferred, else branch head, else
|
|
298
319
|
commit) and pins it - installs are reproducible, not "latest".
|
|
299
320
|
2. Fetches the tree at that ref and reads `manifest.json`.
|
|
300
|
-
3. Validates: schema, `engine` compatibility, dependency
|
|
301
|
-
and version ranges, and (for plugins) the capability list.
|
|
302
|
-
4. Shows a pre-install summary: what it adds, what it patches
|
|
303
|
-
removes
|
|
304
|
-
requests in plain language, size, license, author, screenshots, and
|
|
305
|
-
|
|
306
|
-
5. On confirm, materializes the mod into local storage
|
|
321
|
+
3. [PROPOSED] Validates: schema, `engine` compatibility, dependency
|
|
322
|
+
availability and version ranges, and (for plugins) the capability list.
|
|
323
|
+
4. Shows a pre-install summary: what it adds, what it patches, replaces or
|
|
324
|
+
removes and whether each touched record's owner is enabled, capabilities it
|
|
325
|
+
requests in plain language, size, license, author, screenshots, and any
|
|
326
|
+
conflicts with already-enabled mods.
|
|
327
|
+
5. [PROPOSED] On confirm, materializes the mod into local storage
|
|
307
328
|
(content-addressed by hash), enables it, and inserts it into the load
|
|
308
329
|
order at the dependency-correct position.
|
|
309
330
|
|
package/docs/MOD_REACH.md
CHANGED
|
@@ -903,7 +903,7 @@ and the host constructs it for real:
|
|
|
903
903
|
| `registry:glyph` | `GlyphFacade` | `GlyphRegistry` (`RoomRegistry.glyphs`, `gen/glyph.ts`) | - |
|
|
904
904
|
| `registry:effect-info` | `EffectInfoFacade` (four tables) | `EffectInfoRegistry` (`effects/effect-info-registry.ts`, module-level) | - |
|
|
905
905
|
| `registry:randart` | `RandartFacade` (four tables) | `RandartRegistry` (`obj/randart-registry.ts`, module-level) | - |
|
|
906
|
-
| `registry:tval` | `TvalFacade` (
|
|
906
|
+
| `registry:tval` | `TvalFacade` (five tables) | `TvalRegistry` (`obj/tval-registry.ts`, module-level) | - |
|
|
907
907
|
| `registry:vocab` | `VocabFacade` | `VocabularyRegistry` | `:231-256` |
|
|
908
908
|
|
|
909
909
|
- Gating is real: `requireCap` throws `AgentCapabilityError` (`:165`);
|
package/docs/MOD_SEAMS.md
CHANGED
|
@@ -213,6 +213,8 @@ document has no test behind it and rots on the next commit.
|
|
|
213
213
|
| `levelRevisited(chunk, frozenAt, now)` | `all-observe` | `session/game.ts` (persistent-level and single-combat restore paths) | nothing: resume the frozen chunk unchanged |
|
|
214
214
|
| `messageText(raw)` | `chained` | `packages/web/src/main.ts` (the HOST's single message sink, not core) | `?? raw` - show what core was given, warts and all |
|
|
215
215
|
| `optionsChanged(snapshot)` | `all-observe` | `packages/web/src/options.ts` (`notifyOptionsChanged`, at the end of `runOptionsMenu`) | nothing happens; core reads no answer |
|
|
216
|
+
| `monsterBecameVisible(mon)` | `all-observe` | `game/known.ts` (`updateMon`'s "it was previously unseen" branch, reached from `updateMonsters`, `monsterSwap`, and every other `updateMon` call site) | nothing: the visibility flag was already set with no mod loaded |
|
|
217
|
+
| `artifactIdentified(obj, artifact)` | `all-observe` | `obj/known-object.ts` (`objectTouch`'s ASSESSED transition, reached from `pickup.ts`'s `playerPickupAux`, `game/known.ts`'s `squareKnowPile`, and `wizard.ts`'s item-edit path) | nothing: the object was already assessed with no mod loaded |
|
|
216
218
|
|
|
217
219
|
`optionsChanged` and `levelRevisited` are the notification members: core does
|
|
218
220
|
not ask either a QUESTION. Every other hook's return value changes what the
|
|
@@ -223,6 +225,20 @@ chunk plus unrounded turn endpoints, so a tracking mod can reproduce the engine'
|
|
|
223
225
|
world-tick boundary exactly. `optionsChanged` is the host-owned case: it tells a
|
|
224
226
|
mod that the player has finished changing settings.
|
|
225
227
|
|
|
228
|
+
`monsterBecameVisible` and `artifactIdentified` are the same shape of
|
|
229
|
+
notification, fired from inside core rather than the host. Each carries a live
|
|
230
|
+
reference so a mod can identify the subject without a second lookup:
|
|
231
|
+
`monsterBecameVisible` hands over the `Monster` itself (its `race` and its
|
|
232
|
+
grid), and `artifactIdentified` hands over both the `GameObject` and its
|
|
233
|
+
already-resolved `Artifact` record, rather than an `aidx` a mod would have to
|
|
234
|
+
look up in the artifact registry the way `artifactCommit` requires. Both fire
|
|
235
|
+
on the TRANSITION only: `monsterBecameVisible` on the same "it was previously
|
|
236
|
+
unseen" branch that already increments the race's "sights" lore counter, so it
|
|
237
|
+
fires once per fresh sighting and never on a turn where an already-visible
|
|
238
|
+
monster simply stays visible; `artifactIdentified` on the object's
|
|
239
|
+
`OBJ_NOTICE.ASSESSED` bit flipping from unset to set, which happens once per
|
|
240
|
+
object because that bit is never cleared once it is set.
|
|
241
|
+
|
|
226
242
|
Three details that are contract, not implementation:
|
|
227
243
|
|
|
228
244
|
- It fires **only when something actually changed**. A player who opened the `=`
|
|
@@ -291,8 +307,9 @@ discarded and there is nothing for load order to decide. Per fold:
|
|
|
291
307
|
read as a lexicographic chain: the last mod's ordering is the primary key and
|
|
292
308
|
earlier mods break only the ties it leaves. Still a total order, and still
|
|
293
309
|
later-wins.
|
|
294
|
-
- **`all-observe`** (`optionsChanged`, `levelRevisited`
|
|
295
|
-
|
|
310
|
+
- **`all-observe`** (`optionsChanged`, `levelRevisited`, `monsterBecameVisible`,
|
|
311
|
+
`artifactIdentified`) runs every contributor in load order and reads no
|
|
312
|
+
answer, so there is nothing to win.
|
|
296
313
|
|
|
297
314
|
`composeModHooks` returns `undefined` when nothing contributed,
|
|
298
315
|
so the host leaves the field ABSENT rather than storing an empty object. That
|
package/docs/PLUGINS.md
CHANGED
|
@@ -108,6 +108,18 @@ Your handle on your own bag is the `data` argument `migrateBag` is given, and th
|
|
|
108
108
|
value the host writes back for you. Reaching for `ctx.state.mods` finds nothing,
|
|
109
109
|
because there is no such field.
|
|
110
110
|
|
|
111
|
+
**`migrateBag` is not a WRITE seam.** It only brings an old bag forward at
|
|
112
|
+
mod-load time; it gives you no way to write a new one during play. For that,
|
|
113
|
+
use `ctx.characterStore` (neo-angband#171): `get()` and `set(value)` on your
|
|
114
|
+
own bag, live, keyed to the actual character rather than to a fingerprint of
|
|
115
|
+
one. Before this existed, a mod that needed to remember something about a
|
|
116
|
+
character had to approximate a save key from birth-fixed facts (name, race,
|
|
117
|
+
class, birth stats) and keep it in `ctx.prefs` instead. That store covers the
|
|
118
|
+
whole install rather than one character, so it collides between two
|
|
119
|
+
characters who happen to match on all of those facts. `ctx.characterStore.set()`
|
|
120
|
+
stamps your write with whatever `saveSchema` your manifest currently declares,
|
|
121
|
+
so `migrateBag` still sees a coherent number on the next load.
|
|
122
|
+
|
|
111
123
|
When you change the SHAPE of that data, bump `saveSchema` and ship a
|
|
112
124
|
`migrateBag`:
|
|
113
125
|
|
|
@@ -169,13 +181,15 @@ What `ctx` carries:
|
|
|
169
181
|
| `newCharacter` | whether this session's character was just created, rather than loaded |
|
|
170
182
|
| `registries` | the whole bound `CoreRegistries`: every race, kind, feature, trap, store, projection, room, profile, constant, quest and hint this session actually runs on (absent during content composition) |
|
|
171
183
|
| `log` | a diagnostic line; the host decides where it goes |
|
|
172
|
-
| `backupFolder` |
|
|
184
|
+
| `backupFolder` | `{ name(), choose(), forget(), write(name, text), onSave(fn), list() }`, a player-chosen folder for automatic save backups. Present only when your manifest declared `backup:folder` and the platform can actually offer a folder picker; absent everywhere else, so test for it rather than assuming it. `list()` (#24) answers every `.neochar` file currently in the folder, cheaply identified by lineage and character name/level - never a full decode, never an import |
|
|
173
185
|
| `debug` | `{ spawnObject(kind), spawnMonster(race) }`, conjuring one item or creature into the live game. Present only when your manifest declared `debug:spawn` and there is a game to conjure into. The **first** use in a character asks the game's own debug question and marks that character permanently, so tell the player before they press your button |
|
|
174
186
|
| `wizard` | the game's whole debug set - depth, experience, gold, stats, acquirement, mapping, plus a catalogue of every item, creature and artifact this game has and which pack added each. Present only when your manifest declared `debug:wizard` and there is a game to drive. **Every method refuses until you call `sandbox()`**, which cuts the session loose from its save slot and cannot be undone: the character on disk keeps whatever the last save left, and nothing after that is written. Call `attached()` first to get the name for the question you put to the player. See `MOD_SEAMS.md` section 4f |
|
|
175
187
|
| `installMod` | `(bytes) => Promise<{ok, id, version, lines} \| {ok, problem, lines}>`, installing a **content** mod from the bytes of an archive. Present only when your manifest declared `mod:install`. Code is refused, and what you install lands **switched off** - the player enables it themselves, and a mod takes effect on reload. `lines` is the wording the Mods screen prints for the same outcome, per-requirement rows and all; print it rather than writing a second vocabulary for one concept |
|
|
176
188
|
| `reloadGame` | `() => Promise<void>`, the game's own mod-change reload: every plugin's `uninstall()`, the autoplayer's keyboard handed back, the live character written down, and the session resumed on that character. Present on exactly the terms `installMod` is, because installing something the process will never load is half an act. Not a permission - a plugin reaches `location` regardless - but `location.reload()` skips all four steps, and the third is the player's progress |
|
|
177
189
|
| `loadModForSession` | `(bytes) => Promise<{ok, id, version, survivesReload} \| {ok, problem}>`, loading a **content** mod for this session only. Present only when your manifest declared `mod:session`. Code is refused on the same terms. It is **on** from the next reload rather than waiting to be switched on, and the archive is forgotten when the game closes - but what it did to a character is not. Say that to the player |
|
|
178
190
|
| `ui` | `{ openPanel(spec), openPanels }`, panels of **real HTML** rather than character cells. Present only when your manifest declared `ui:panel.mount`; absent everywhere else, so test for it. See `MOD_SEAMS.md` section 4b - the two things that surprise everybody are that Escape is the player's and that a non-modal panel's container takes no pointer events |
|
|
191
|
+
| `keyRepeat` | `() => { isRepeat, reportedRepeat, intervalMs, ageMs } \| null`, the host's own judgment on the most recent root-screen keydown - a genuine key-repeat versus a fresh press. Entirely ungated, like `subwindows`; `null` before the root handler has classified a keydown this session. Read-side only for now - nothing here yet suppresses or alters a command from it (#35) |
|
|
192
|
+
| `characterStore` | `{ get(), set(value) }`, this mod's own live per-character storage - the same save bag `migrateBag` migrates, read and written during play instead of only at mod-load time. Scoped by mod id like `prefs`; entirely ungated. Present only once there is a live character. A write is stamped with your manifest's CURRENT `saveSchema` (0 if you declare none), the same number `migrateBag` reads back on a later load (#171) |
|
|
179
193
|
|
|
180
194
|
`flags` is sliced per mod on purpose: a mod must not be able to read or act on
|
|
181
195
|
another mod's toggles, or its behaviour would silently depend on which other mods
|
|
@@ -1421,7 +1435,7 @@ written down, and the table below is a reading of it:
|
|
|
1421
1435
|
| `registry:ui-entry` | what a `combine:` or an `entry-renderer:` `code:` *means* on the second character screen and the equipment comparison: `uiEntry.combiners.set("my-mod:worst-of", ...)` (how a row's per-slot values reduce to the one that colours its label) and `uiEntry.backends.set("my-mod:bars", ...)` (how a value becomes a cell symbol and colour). Adding a `ui_entry.json` ROW needs no capability; a row naming a combiner or renderer nothing answers for draws as an empty row rather than failing, so this is what makes your row mean something |
|
|
1422
1436
|
| `registry:glyph` | what one character of a room-template or vault layout means when the level is drawn: `glyphs.set("vault", "Q", ...)`. The behaviour half of shipping a vault with a symbol core has never seen |
|
|
1423
1437
|
| `registry:effect-info` | what the game *says* about an effect: `effectInfo.text` (the menu row and the recall sentence), `.summary` (the object properties an activation grants), `.subtype` (the named subtypes it accepts) and `.request` (which item it prompts for). This is the description half of `registry:effect`: without it your new effect works and the game has nothing to say about it |
|
|
1424
|
-
| `registry:tval` | what an item CLASS *is*: `tval.classes` (keyed on the predicate's own name, so `handlerFor("tvalIsWeapon")` returns core's arm and a mod ORs its own tval into it), `.good` (whether a template counts as good for allocation)
|
|
1438
|
+
| `registry:tval` | what an item CLASS *is*: `tval.classes` (keyed on the predicate's own name, so `handlerFor("tvalIsWeapon")` returns core's arm and a mod ORs its own tval into it), `.good` (whether a template counts as good for allocation), `.valueBase` (what an unidentified item of the class is worth), `.valueAdjust` (a post-computation nudge to `object_value_real`'s own faithful result - `{ reg, obj, qty, baseValue, totalAc }` in, a possibly-different number out; unregistered is a no-op) and `.basename` (what the class is CALLED - without it every message, menu row and shop line naming the class reads the literal "(nothing)"). Shipping a new *item* needs no capability; this is the class |
|
|
1425
1439
|
| `registry:randart` | how RANDOM artifacts are built: `randart.abilities` (what a power does), `.prep` (what an item class starts with), `.census` (which frequency bucket it feeds) and `.redundancy` (whether an activation duplicates something the artifact already has). Shipping a *fixed* artifact needs no capability; this is the generator |
|
|
1426
1440
|
| `registry:rune` | what a RUNE is: the unit of object knowledge. `rune.desc` (the recall line), `.name` (the display decoration), `.knows` / `.learn` (the knowledge pair, handed the player so YOUR mod keeps the store, since core never grew a slot for it), `.objectHas` (whether an item carries it) and `.modMessage` (the "You feel stronger!" line, keyed on the modifier). Plus `.contribute`, which is how your rune gets into the list every consumer enumerates, and without it the six tables above are handlers nothing ever calls |
|
|
1427
1441
|
| `registry:vocab` | declare genuinely new vocabulary (flags, stats, mod-coined kinds) and store per-entity values |
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@rpgm-tools/neo-angband-mod-sdk",
|
|
3
|
-
"version": "1.
|
|
3
|
+
"version": "1.16.0",
|
|
4
4
|
"description": "Pack schemas, validation, and tooling for Neo Angband mods (content packs, tile packs, scripted plugins)",
|
|
5
5
|
"license": "GPL-2.0-only",
|
|
6
6
|
"author": "neostryder (RPGM Tools)",
|
package/src/capabilities.ts
CHANGED
|
@@ -82,8 +82,11 @@
|
|
|
82
82
|
* "registry:tval" reaches every question core asks
|
|
83
83
|
* about an item CLASS - is it a weapon, can it be
|
|
84
84
|
* worn or flavoured, is it good, what is it worth
|
|
85
|
-
* unidentified
|
|
86
|
-
*
|
|
85
|
+
* unidentified, and what a mod may adjust a
|
|
86
|
+
* computed real value TO once core's own faithful
|
|
87
|
+
* pricing has run (`valueAdjust`, keyed on tval).
|
|
88
|
+
* Distinct from shipping a new ITEM, which needs
|
|
89
|
+
* no capability at all.
|
|
87
90
|
* "registry:vocab" (W2.3) declares
|
|
88
91
|
* NEW vocabulary (flags/stats/any kind). Distinct
|
|
89
92
|
* from "command:add": that adds a command via the
|
|
@@ -155,6 +158,28 @@
|
|
|
155
158
|
* sold under the other's sentence. It is a shorter
|
|
156
159
|
* LIFETIME for the archive and not a smaller reach for
|
|
157
160
|
* the records: what composes, composes.
|
|
161
|
+
* - "mod:read" - resolve a repository reference through the SAME
|
|
162
|
+
* resolver the "install from a repository" door
|
|
163
|
+
* uses (the tags call, the channel filter, the
|
|
164
|
+
* manifest read at each candidate tag until one is
|
|
165
|
+
* engine-compatible), and hand back its manifest
|
|
166
|
+
* and payload listing. Nothing is installed and
|
|
167
|
+
* nothing is written to the player's library. Its
|
|
168
|
+
* own kind, like "backup:folder" and
|
|
169
|
+
* "display:replace": there is nothing to range
|
|
170
|
+
* over, so it has no wildcard either, and neither
|
|
171
|
+
* "mod:install" nor "mod:session" covers it - a
|
|
172
|
+
* mod that may put a pack in the library has not
|
|
173
|
+
* thereby been allowed to make network requests on
|
|
174
|
+
* the player's behalf to look one up. It is also
|
|
175
|
+
* not a "network:<host>" grant: that family gates
|
|
176
|
+
* a different, agent-facing door, and in-process
|
|
177
|
+
* plugin code can already fetch for itself with no
|
|
178
|
+
* capability at all (see this file's own header).
|
|
179
|
+
* What this buys is that the answer came from the
|
|
180
|
+
* host's own resolution rules rather than a
|
|
181
|
+
* second copy of them that could accept a
|
|
182
|
+
* reference the real installer would refuse.
|
|
158
183
|
* - "debug:spawn" - conjure an item or a creature into the live game the
|
|
159
184
|
* way the debug commands do. Its own kind and no
|
|
160
185
|
* wildcard, and here that is the whole point rather
|
|
@@ -234,6 +259,7 @@ export type ParsedCapability =
|
|
|
234
259
|
| { kind: "ui"; region: string; action: "replace" | "create" | "mount" }
|
|
235
260
|
| { kind: "backup"; action: "folder" }
|
|
236
261
|
| { kind: "mod"; action: "install" | "session" }
|
|
262
|
+
| { kind: "mod-read"; action: "read" }
|
|
237
263
|
| { kind: "debug"; action: "spawn" | "wizard" }
|
|
238
264
|
| { kind: "keymap"; action: "write" }
|
|
239
265
|
| { kind: "query"; action: "snapshot" }
|
|
@@ -357,6 +383,17 @@ export function parseCapability(cap: string): ParsedCapability {
|
|
|
357
383
|
if (cap === "mod:session") {
|
|
358
384
|
return { kind: "mod", action: "session" };
|
|
359
385
|
}
|
|
386
|
+
/* "mod:read": resolve a repository reference through the SAME resolver the
|
|
387
|
+
* install door uses and hand back its manifest and payload listing, without
|
|
388
|
+
* installing anything. A DIFFERENT kind from "mod", not a third action on
|
|
389
|
+
* it - "install" and "session" are two ways to put a pack IN the library,
|
|
390
|
+
* and this puts nothing anywhere, so "mod:*" covering it would be exactly
|
|
391
|
+
* the escalation grantCovers's action comparison exists to refuse. Its own
|
|
392
|
+
* kind, no wildcard, same reasoning as "backup:folder": there is nothing to
|
|
393
|
+
* range over. */
|
|
394
|
+
if (cap === "mod:read") {
|
|
395
|
+
return { kind: "mod-read", action: "read" };
|
|
396
|
+
}
|
|
360
397
|
/* "debug:spawn": put an item or a creature into the live game the way the debug
|
|
361
398
|
* commands do, marking the character the way they do. Its own kind and no
|
|
362
399
|
* wildcard on purpose - a player asking "which of my mods can conjure things"
|
|
@@ -464,6 +501,12 @@ function grantCovers(grant: ParsedCapability, request: ParsedCapability): boolea
|
|
|
464
501
|
* session. Neither is a superset of the other, there is no wildcard, and a
|
|
465
502
|
* kind-only comparison would have let one consent buy both. */
|
|
466
503
|
return grant.kind === "mod" && grant.action === request.action;
|
|
504
|
+
case "mod-read":
|
|
505
|
+
/* Exact match only, same reasoning as "backup" - there is exactly one
|
|
506
|
+
* mod-read capability and no wildcard grant could ever cover it, and
|
|
507
|
+
* neither "mod:install" nor "mod:session" reaches here: they are a
|
|
508
|
+
* different `kind` entirely, not a wider action of the same one. */
|
|
509
|
+
return grant.kind === "mod-read";
|
|
467
510
|
case "debug":
|
|
468
511
|
/* Exact match only, and here that is the point rather than a consequence:
|
|
469
512
|
* this is the grant a player is most likely to check for by name, so it
|