DNF90 服务端与启动器完整源码（含 GM 工具功能增强）
服务端（Go）： - GM 塞背包/带属性装备发放：在线角色推送 op14 增量物品行，背包实时刷新，无需回角色选择界面 - GM 改金币/改等级：去掉在线拒绝，落库后推送 op14 钱包/op37 等级状态，在线实时刷新 - 等级端点统一切换到新版 GMSetCharacterLevel（自带在线刷新） - 无限/锁死疲劳模式 + 燃烧疲劳：每房间消耗 2 点、打怪与通关经验双倍 - 燃烧疲劳开关时给所有在线角色推送系统提示（op12 mode 0） - 深渊史诗掉率：GM 全局倍率 + 城镇增益药剂窗口倍率，真实接入掉落结算 启动器（Python/JS）： - 标题栏自绘、窗口 1204x717、禁止拖拽改大小、仅最小化/关闭 - GM 工具：疲劳与燃烧、深渊史诗掉率、拍卖行上架（单一定价对齐） - 拍卖行上架前端对齐服务端单一价格语义，修复 400 报错
This commit is contained in:
hanfuit committed
commit
645b64fe21
4388 files changed
+1405457
No files matched your search
@@ -0,0 +1,33 @@
|
||||
---
|
||||
name: pvfine-drop-rates
|
||||
description: 读取和修改 PVF 深渊、翻牌、普通及精英怪物基础掉率，以及全局掉落权重；通过 pvfine MCP 实施。
|
||||
---
|
||||
|
||||
# 掉率
|
||||
|
||||
先区分用户要改稀有度分布、物品池权重还是实际掉落次数；范围或概率口径不明确时先询问。
|
||||
|
||||
## 基础稀有度分布
|
||||
|
||||
GUI 支持 TW、90US/90CN、100CN、110US。内部路径拼写必须保留：
|
||||
|
||||
|场景|路径|前置值个数|组数|
|
||||
|---|---|---:|---:|
|
||||
|深渊|etc/itemdropinfo_monster_hell.etc|1|2|
|
||||
|翻牌|etc/itemdropinfo_clearreward.etc|0|1|
|
||||
|普通怪物|etc/itemdropinfo_monseter.etc|0|4|
|
||||
|精英怪物|etc/itemdropinfo_monseter_extra.etc|0|4|
|
||||
|
||||
目标 section 是 `[basis of rarity dicision]`（原始拼写）。每组宽度可为 6、7、8、9；验证总长度=前置值+组数×组宽，不凭版本名跳过长度校验。GUI 的组顺序：深渊为困难、非常困难；普通及精英为普通、冒险、王者、地狱；五种稀有度依次为白云、蓝天、稀有、神器、史诗。读取当前标注交叉核对实际版本含义。
|
||||
|
||||
每组前五项是累计阈值，不是独立概率。相邻差值 / 10000 为百分数，首项相对 0；第五阈值兼容 1000000～1000002。GUI 按 0.01% 量化，用最大余数法归一为总和 100%。写入时五种概率合计须 100%，按 0.01% 单位取整数，总和为 10000；各项乘 100 再累加写回前五项。保留组内第六项及后续扩展值、深渊前置值。不要把尾部额外阈值当作另外五类概率的一部分。
|
||||
|
||||
例如独立概率 50%、30%、15%、4%、1%，累计值为 500000、800000、950000、990000、1000000。只改变明确选中的组；不能以「史诗提升」为由自行决定从哪一类扣除概率。
|
||||
|
||||
## 全局掉落池
|
||||
|
||||
路径 `etc/worlddrop.etc` 或 `etc/(r)worlddrop.etc`，两者独立，先确认目标。唯一 `[world drop]` 中每个等级块：`等级 0`，随后若干 `物品ID 权重`，以单个 `-1` 结束。等级正整数且不重复，权重非负 32 位整数；新增物品 ID 应为正数并验证关联存在。保留原有未知 ID，不能自行清理。
|
||||
|
||||
权重是相对值，不直接等于百分数，更不能保证实际总掉落率。可报告同等级池内权重占比，明确它仅是池内相对比例。修改某个权重应保持其他等级、成对条目和 -1 分隔完整。
|
||||
|
||||
操作前阅读 [MCP 操作流程](references/mcp-workflow.md)，按其查询、验证、预览、应用和保存规则执行。
|
||||
@@ -0,0 +1,19 @@
|
||||
# MCP 操作流程
|
||||
|
||||
此 skill 面向正在运行的 pvfine MCP 服务。安装 skill 不会自动配置连接；先在 pvfine「偏好设置 → MCP 服务」启用服务，将连接配置加入 AI 客户端。以下是服务端工具名，客户端可能增加前缀。
|
||||
|
||||
1. 调用 `pvf_workspace_info`，确认归档、workspaceId、revision 和 versionLoading。未打开归档时先根据用户指定的本机绝对路径使用 `pvf_archive_open`，传入 workspaceEpoch 作为 expectedWorkspaceEpoch；不擅自丢弃未保存内容。
|
||||
2. 查询用 `pvf_search`（mode=path/content）、`pvf_read_file`。查询读取工具传入 workspaceId 与 expectedRevision=revision。read_file 每页最多 100 行，根据 nextLine 继续；搜索按返回分页继续，不能把第一页当作完整结果。
|
||||
3. 不清楚字段时用 `pvf_annotation_search`（filePath、section、workspaceId），再以返回的 documentId/rulesRevision 调用 `pvf_annotation_get`。用 `pvf_annotation_explain` 查看当前文件的枚举、字符串引用和关联目标。说明缺失时先读取实际结构，不猜测字段含义。
|
||||
4. 编写脚本前读取 `pvf_script_help(topic="types")` 获取当前完整声明，必要时读取 sections/lists/strings 帮助。沙箱只有 `pvf`，没有 Node、网络或本机文件系统；查询通过 `pvf.log(JSON.stringify(result))` 输出，限定文件范围，避免输出整个归档。
|
||||
5. 脚本先 `pvf_script_validate(source)`；通过后 `pvf_script_run(workspaceId, expectedRevision, source, label, requestId)`。轮询 `pvf_script_status(taskId)` 至完成，检查日志与诊断，取得 planId。查询脚本无修改时可以没有 planId。
|
||||
6. 有变更时用 `pvf_script_preview(planId, cursor, limit)` 看完全部差异，核对文件、字段、旧值、新值与范围。只应用符合用户指令的 changeKey；引用新增 .str 文本时一并选择对应字符串表依赖。调用 `pvf_script_apply(workspaceId, expectedRevision, planId, changeKeys, requestId)` 后用 `pvf_task_status` 等待结束。
|
||||
7. 应用仅修改内存工作区。重新获取 workspace_info 并读取验证；用户要求保存时才调用 `pvf_archive_save`。`pvf_archive_save_as` 生成副本，后续保存仍写源归档。最终明确说明修改路径、数值、应用状态和磁盘保存状态。
|
||||
|
||||
每个新修改请求使用唯一 requestId；同一次请求的网络重试复用原 ID。遇到 STALE_WORKSPACE 重新查询和生成预览，不用新修订号强行应用旧计划。TASK_BUSY、前端草稿或冲突时先处理阻塞；失败不盲目重试。废弃预览用 pvf_script_discard。
|
||||
|
||||
## 脚本读写
|
||||
|
||||
文件路径是归档内部路径。`pvf.find(path)` 返回句柄或 null；`file.parse()` 得到文档，`doc.sections(path)` 返回全部同名 section，路径与嵌套参数以当前 types 声明为准。`section.get(i)`/`set(value,i)` 访问零基索引；`values()`/`setValues()` 操作直接值；修改文档后须 `file.write(doc)`。每次先验证 section 数量、长度、类型与旧值，再改目标字段。不要用 setValues 重建含子 section 的复合块。必要时用 file.text()/setText() 做精确的局部文本替换，保留未涉及内容、类型标记和闭合标签。
|
||||
|
||||
读取 `<表号::键名>` 用 `getOriStrValue`；修改时按当前 strings API 保留引用语义。ID 不等于文件索引；使用标注关联或 `pvf.lst(path)` 解析路径。新建文件要同步正确 lst 注册，删除文件不会自动注销。MCP 不支持文件集修改。
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
name: pvfine-npc-shops
|
||||
description: 通过 pvfine MCP 读取和修改 NPC 商店商品、分页、分类、金币价格与材料兑换成本。
|
||||
---
|
||||
|
||||
# NPC 商店
|
||||
|
||||
先定位 NPC，再通过关联标注追踪实际 `.shp` 路径；必要时搜索 `**/*.shp`，用 NPC/商店列表确认 ID。不能猜测 NPC ID 就是商店文件名。
|
||||
|
||||
商店商品位于 `sell info/tab/item list` 或 `sell info/tab/category entry/item list`。tab 可重复，category entry 的 id 标识分类；修改前明确目标分页与分类。`[use category]` 关联的分类定义来自 `etc/itemshop/itemshopcategory.etc`，结构是 itemshop category/category name 与 category entry/id、text。未要求时不改共享分类定义。
|
||||
|
||||
item list 是商品 ID 列表，不是 ID/数量配对。读取实际 section 及标注后追加/移除目标商品，保留商品顺序与其他分页；新增前验证物品存在，并说明重复商品如何处理。不要把加入商店理解成创建新的物品文件。
|
||||
|
||||
金币和材料成本在商品自身文件（通常 .equ/.stk），不是商店列表：
|
||||
|
||||
- `[price]` 单个非负整数。删除 price 与显式设 0 含义不同。
|
||||
- `[need material]` 以 `材料ID 数量` 成对存储，不能只改前半对或把多个材料改成单值。
|
||||
|
||||
用标注关联或物品 lst 联合解析商品，不把 ID 当文件索引。修改物品成本会影响所有引用该物品的商店；用户只想修改单个 NPC 价格时必须说明共享成本的影响，先确认所需效果，不能默改全局商品成本或自行复制物品。
|
||||
|
||||
把商店列表与物品成本的相关变更放在同一个脚本预览；涉及名称引用时一并包含 .str 依赖。对同名 tab、同一分类的多个 entry 要显式定位 occurrence，不选第一个充数。应用后同时复查商店列表、商品成本和关联是否正确。
|
||||
|
||||
操作前阅读 [MCP 操作流程](references/mcp-workflow.md)，按其查询、验证、预览、应用和保存规则执行。
|
||||
@@ -0,0 +1,19 @@
|
||||
# MCP 操作流程
|
||||
|
||||
此 skill 面向正在运行的 pvfine MCP 服务。安装 skill 不会自动配置连接；先在 pvfine「偏好设置 → MCP 服务」启用服务，将连接配置加入 AI 客户端。以下是服务端工具名，客户端可能增加前缀。
|
||||
|
||||
1. 调用 `pvf_workspace_info`，确认归档、workspaceId、revision 和 versionLoading。未打开归档时先根据用户指定的本机绝对路径使用 `pvf_archive_open`，传入 workspaceEpoch 作为 expectedWorkspaceEpoch；不擅自丢弃未保存内容。
|
||||
2. 查询用 `pvf_search`（mode=path/content）、`pvf_read_file`。查询读取工具传入 workspaceId 与 expectedRevision=revision。read_file 每页最多 100 行，根据 nextLine 继续；搜索按返回分页继续，不能把第一页当作完整结果。
|
||||
3. 不清楚字段时用 `pvf_annotation_search`（filePath、section、workspaceId），再以返回的 documentId/rulesRevision 调用 `pvf_annotation_get`。用 `pvf_annotation_explain` 查看当前文件的枚举、字符串引用和关联目标。说明缺失时先读取实际结构，不猜测字段含义。
|
||||
4. 编写脚本前读取 `pvf_script_help(topic="types")` 获取当前完整声明，必要时读取 sections/lists/strings 帮助。沙箱只有 `pvf`，没有 Node、网络或本机文件系统；查询通过 `pvf.log(JSON.stringify(result))` 输出，限定文件范围，避免输出整个归档。
|
||||
5. 脚本先 `pvf_script_validate(source)`；通过后 `pvf_script_run(workspaceId, expectedRevision, source, label, requestId)`。轮询 `pvf_script_status(taskId)` 至完成，检查日志与诊断，取得 planId。查询脚本无修改时可以没有 planId。
|
||||
6. 有变更时用 `pvf_script_preview(planId, cursor, limit)` 看完全部差异，核对文件、字段、旧值、新值与范围。只应用符合用户指令的 changeKey；引用新增 .str 文本时一并选择对应字符串表依赖。调用 `pvf_script_apply(workspaceId, expectedRevision, planId, changeKeys, requestId)` 后用 `pvf_task_status` 等待结束。
|
||||
7. 应用仅修改内存工作区。重新获取 workspace_info 并读取验证；用户要求保存时才调用 `pvf_archive_save`。`pvf_archive_save_as` 生成副本，后续保存仍写源归档。最终明确说明修改路径、数值、应用状态和磁盘保存状态。
|
||||
|
||||
每个新修改请求使用唯一 requestId；同一次请求的网络重试复用原 ID。遇到 STALE_WORKSPACE 重新查询和生成预览，不用新修订号强行应用旧计划。TASK_BUSY、前端草稿或冲突时先处理阻塞；失败不盲目重试。废弃预览用 pvf_script_discard。
|
||||
|
||||
## 脚本读写
|
||||
|
||||
文件路径是归档内部路径。`pvf.find(path)` 返回句柄或 null；`file.parse()` 得到文档，`doc.sections(path)` 返回全部同名 section，路径与嵌套参数以当前 types 声明为准。`section.get(i)`/`set(value,i)` 访问零基索引；`values()`/`setValues()` 操作直接值；修改文档后须 `file.write(doc)`。每次先验证 section 数量、长度、类型与旧值，再改目标字段。不要用 setValues 重建含子 section 的复合块。必要时用 file.text()/setText() 做精确的局部文本替换，保留未涉及内容、类型标记和闭合标签。
|
||||
|
||||
读取 `<表号::键名>` 用 `getOriStrValue`；修改时按当前 strings API 保留引用语义。ID 不等于文件索引；使用标注关联或 `pvf.lst(path)` 解析路径。新建文件要同步正确 lst 注册，删除文件不会自动注销。MCP 不支持文件集修改。
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
name: pvfine-quests
|
||||
description: 通过 pvfine MCP 读取和修改 PVF 任务条件、NPC、等级限制、对话、固定奖励和自选奖励。
|
||||
---
|
||||
|
||||
# 任务
|
||||
|
||||
搜索实际 `.qst` 路径，用名称、quest lst 与关联标注确认任务 ID。读取现有字段及字符串引用，再确定是条件数值调整、任务类型转换还是奖励修改。未知字段原样保留。
|
||||
|
||||
基础字段：name、grade、difficulty、npc index（发布 NPC）、complete npc index、job、grow type（-1 为不限）、level（下限/上限）。grade 常见字符串值 `[daily]`、`[normaly repeat]`、`[common unique]`、`[achievement]`、`[epic]`，保留原始拼写，写入的是字符串值而非新 section。
|
||||
|
||||
条件由 type（字符串）、sub type（整数）、int data（整数组）共同决定：
|
||||
|
||||
|条件 type|sub type|int data 一组参数|
|
||||
|---|---:|---|
|
||||
|[hunt monster]|-1|副本ID、难度、怪物ID、数量（可重复）|
|
||||
|[clear map]|-1|地图ID|
|
||||
|[seeking]|-1|物品ID、数量（可重复）|
|
||||
|[meet npc]|-1|NPC ID|
|
||||
|[condition under clear]|6|副本ID、难度|
|
||||
|[condition under clear]|11|副本ID、难度、房间数量|
|
||||
|[condition under clear]|0|副本ID、难度、时间（秒）|
|
||||
|[condition under clear]|5|副本ID、难度、人数|
|
||||
|
||||
切换条件需同步这三个字段，并验证目标 ID，不能沿用旧参数宽度。未知组合先查当前标注。
|
||||
|
||||
奖励：reward type 决定 reward int data 布局。`[item]` 是物品ID/数量对（可重复）；`[title]` 是称号ID/数量；`[grow type]` 是转职ID；`[awakening type]` 是觉醒次数。`reward selection int data` 为自选奖励，读取实际标注确认布局，不把它替换成固定奖励。quest point 是 QP。
|
||||
|
||||
对话字段 depend message、condition message、solve message 以及 name 可能使用 `<表号::键名>` 引用；先解析译文，修改时保留引用机制并预览字符串表依赖。不要把占位引用当作名称全文覆盖。重复字段、特殊 token 或未知布局先逐项确认，保留闭合标签与原有类型。新建/删除任务还必须同步正确 lst；不在单纯调整奖励时重建整个任务。
|
||||
|
||||
预览应说明任务身份、前后条件参数、奖励与文本引用，再应用并重新读取验证。
|
||||
|
||||
操作前阅读 [MCP 操作流程](references/mcp-workflow.md)，按其查询、验证、预览、应用和保存规则执行。
|
||||
@@ -0,0 +1,19 @@
|
||||
# MCP 操作流程
|
||||
|
||||
此 skill 面向正在运行的 pvfine MCP 服务。安装 skill 不会自动配置连接；先在 pvfine「偏好设置 → MCP 服务」启用服务，将连接配置加入 AI 客户端。以下是服务端工具名，客户端可能增加前缀。
|
||||
|
||||
1. 调用 `pvf_workspace_info`，确认归档、workspaceId、revision 和 versionLoading。未打开归档时先根据用户指定的本机绝对路径使用 `pvf_archive_open`，传入 workspaceEpoch 作为 expectedWorkspaceEpoch；不擅自丢弃未保存内容。
|
||||
2. 查询用 `pvf_search`（mode=path/content）、`pvf_read_file`。查询读取工具传入 workspaceId 与 expectedRevision=revision。read_file 每页最多 100 行，根据 nextLine 继续；搜索按返回分页继续，不能把第一页当作完整结果。
|
||||
3. 不清楚字段时用 `pvf_annotation_search`（filePath、section、workspaceId），再以返回的 documentId/rulesRevision 调用 `pvf_annotation_get`。用 `pvf_annotation_explain` 查看当前文件的枚举、字符串引用和关联目标。说明缺失时先读取实际结构，不猜测字段含义。
|
||||
4. 编写脚本前读取 `pvf_script_help(topic="types")` 获取当前完整声明，必要时读取 sections/lists/strings 帮助。沙箱只有 `pvf`，没有 Node、网络或本机文件系统；查询通过 `pvf.log(JSON.stringify(result))` 输出，限定文件范围，避免输出整个归档。
|
||||
5. 脚本先 `pvf_script_validate(source)`；通过后 `pvf_script_run(workspaceId, expectedRevision, source, label, requestId)`。轮询 `pvf_script_status(taskId)` 至完成，检查日志与诊断，取得 planId。查询脚本无修改时可以没有 planId。
|
||||
6. 有变更时用 `pvf_script_preview(planId, cursor, limit)` 看完全部差异，核对文件、字段、旧值、新值与范围。只应用符合用户指令的 changeKey；引用新增 .str 文本时一并选择对应字符串表依赖。调用 `pvf_script_apply(workspaceId, expectedRevision, planId, changeKeys, requestId)` 后用 `pvf_task_status` 等待结束。
|
||||
7. 应用仅修改内存工作区。重新获取 workspace_info 并读取验证；用户要求保存时才调用 `pvf_archive_save`。`pvf_archive_save_as` 生成副本，后续保存仍写源归档。最终明确说明修改路径、数值、应用状态和磁盘保存状态。
|
||||
|
||||
每个新修改请求使用唯一 requestId；同一次请求的网络重试复用原 ID。遇到 STALE_WORKSPACE 重新查询和生成预览，不用新修订号强行应用旧计划。TASK_BUSY、前端草稿或冲突时先处理阻塞；失败不盲目重试。废弃预览用 pvf_script_discard。
|
||||
|
||||
## 脚本读写
|
||||
|
||||
文件路径是归档内部路径。`pvf.find(path)` 返回句柄或 null；`file.parse()` 得到文档，`doc.sections(path)` 返回全部同名 section，路径与嵌套参数以当前 types 声明为准。`section.get(i)`/`set(value,i)` 访问零基索引；`values()`/`setValues()` 操作直接值；修改文档后须 `file.write(doc)`。每次先验证 section 数量、长度、类型与旧值，再改目标字段。不要用 setValues 重建含子 section 的复合块。必要时用 file.text()/setText() 做精确的局部文本替换，保留未涉及内容、类型标记和闭合标签。
|
||||
|
||||
读取 `<表号::键名>` 用 `getOriStrValue`；修改时按当前 strings API 保留引用语义。ID 不等于文件索引；使用标注关联或 `pvf.lst(path)` 解析路径。新建文件要同步正确 lst 注册，删除文件不会自动注销。MCP 不支持文件集修改。
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
name: pvfine-skill-values
|
||||
description: 通过 pvfine MCP 读取和修改 .skl 技能数值，区分地下城与 PVP、静态数据与等级成长参数。
|
||||
---
|
||||
|
||||
# 技能数值
|
||||
|
||||
用路径搜索 `skill/**/*.skl` 或实际目录，并通过名称、职业、lst 与标注定位技能；不要直接把技能 ID 当作文件名。先读取原文件，明确地下城 `[dungeon]` 或 `[pvp]`，以及目标等级区间与参数含义。二者独立，未要求时不同时改动。
|
||||
|
||||
- 模式中的 `[static data]` 是平铺静态参数；按标注或说明模板定位零基索引，不能把第一个数统一当作伤害。
|
||||
- `[level info]` 第一项是每级列宽 W，必须为正整数；余下数值数量必须能被 W 整除。第 L 级、第 C 列（L 从 1、C 从 0）对应索引 `1+(L-1)*W+C`。保留宽度项和未选择的等级/列。
|
||||
- `[level property]` 提供说明模板及参数绑定。先解析字符串引用，再核对占位符与 static/level 数据的对应关系；模板可能在模式内，也可能共享。不要把绑定索引、列宽和说明中的展示数字当成可调技能参数。
|
||||
- 重复 static data/level info、非数值、宽度异常时停止自动修改该区域，先解释实际结构。不要默取第一个重复 section。
|
||||
|
||||
使用当前 script types 声明选择嵌套 section，读取 values/get 记录旧值，按确定的索引 set，然后 file.write(doc)。保留 integer/float 类型：整数范围和原有小数含义都需要核对。只有明确知道含义才换算百分比、毫秒或倍率；无法判断时用原始值说明并询问。
|
||||
|
||||
预览应列出技能路径、模式、等级区间、列/字段、旧值和新值；应用后重新读取，确认另一模式与列宽未被修改。
|
||||
|
||||
操作前阅读 [MCP 操作流程](references/mcp-workflow.md)，按其查询、验证、预览、应用和保存规则执行。
|
||||
@@ -0,0 +1,19 @@
|
||||
# MCP 操作流程
|
||||
|
||||
此 skill 面向正在运行的 pvfine MCP 服务。安装 skill 不会自动配置连接；先在 pvfine「偏好设置 → MCP 服务」启用服务，将连接配置加入 AI 客户端。以下是服务端工具名，客户端可能增加前缀。
|
||||
|
||||
1. 调用 `pvf_workspace_info`，确认归档、workspaceId、revision 和 versionLoading。未打开归档时先根据用户指定的本机绝对路径使用 `pvf_archive_open`，传入 workspaceEpoch 作为 expectedWorkspaceEpoch；不擅自丢弃未保存内容。
|
||||
2. 查询用 `pvf_search`（mode=path/content）、`pvf_read_file`。查询读取工具传入 workspaceId 与 expectedRevision=revision。read_file 每页最多 100 行，根据 nextLine 继续；搜索按返回分页继续，不能把第一页当作完整结果。
|
||||
3. 不清楚字段时用 `pvf_annotation_search`（filePath、section、workspaceId），再以返回的 documentId/rulesRevision 调用 `pvf_annotation_get`。用 `pvf_annotation_explain` 查看当前文件的枚举、字符串引用和关联目标。说明缺失时先读取实际结构，不猜测字段含义。
|
||||
4. 编写脚本前读取 `pvf_script_help(topic="types")` 获取当前完整声明，必要时读取 sections/lists/strings 帮助。沙箱只有 `pvf`，没有 Node、网络或本机文件系统；查询通过 `pvf.log(JSON.stringify(result))` 输出，限定文件范围，避免输出整个归档。
|
||||
5. 脚本先 `pvf_script_validate(source)`；通过后 `pvf_script_run(workspaceId, expectedRevision, source, label, requestId)`。轮询 `pvf_script_status(taskId)` 至完成，检查日志与诊断，取得 planId。查询脚本无修改时可以没有 planId。
|
||||
6. 有变更时用 `pvf_script_preview(planId, cursor, limit)` 看完全部差异，核对文件、字段、旧值、新值与范围。只应用符合用户指令的 changeKey；引用新增 .str 文本时一并选择对应字符串表依赖。调用 `pvf_script_apply(workspaceId, expectedRevision, planId, changeKeys, requestId)` 后用 `pvf_task_status` 等待结束。
|
||||
7. 应用仅修改内存工作区。重新获取 workspace_info 并读取验证；用户要求保存时才调用 `pvf_archive_save`。`pvf_archive_save_as` 生成副本，后续保存仍写源归档。最终明确说明修改路径、数值、应用状态和磁盘保存状态。
|
||||
|
||||
每个新修改请求使用唯一 requestId；同一次请求的网络重试复用原 ID。遇到 STALE_WORKSPACE 重新查询和生成预览，不用新修订号强行应用旧计划。TASK_BUSY、前端草稿或冲突时先处理阻塞；失败不盲目重试。废弃预览用 pvf_script_discard。
|
||||
|
||||
## 脚本读写
|
||||
|
||||
文件路径是归档内部路径。`pvf.find(path)` 返回句柄或 null；`file.parse()` 得到文档，`doc.sections(path)` 返回全部同名 section，路径与嵌套参数以当前 types 声明为准。`section.get(i)`/`set(value,i)` 访问零基索引；`values()`/`setValues()` 操作直接值；修改文档后须 `file.write(doc)`。每次先验证 section 数量、长度、类型与旧值，再改目标字段。不要用 setValues 重建含子 section 的复合块。必要时用 file.text()/setText() 做精确的局部文本替换，保留未涉及内容、类型标记和闭合标签。
|
||||
|
||||
读取 `<表号::键名>` 用 `getOriStrValue`；修改时按当前 strings API 保留引用语义。ID 不等于文件索引；使用标注关联或 `pvf.lst(path)` 解析路径。新建文件要同步正确 lst 注册，删除文件不会自动注销。MCP 不支持文件集修改。
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
name: pvfine-upgrade
|
||||
description: 通过 pvfine MCP 读取和修改强化、增幅、锻造的概率、失败处理和材料金币成本，识别旧表及 typed 表。
|
||||
---
|
||||
|
||||
# 强化、增幅与锻造
|
||||
|
||||
目标路径：强化 `etc/upgrade.etc`，增幅 `etc/amplifyupgrade.etc`，锻造 `etc/upgrade_separate.etc`。先核对表布局与版本，以下列索引均从 0 开始。
|
||||
|
||||
## 强化与增幅
|
||||
|
||||
存在 `[table type]` 时，按 table 自己的 type 值选择 `normal`（强化）或 `amplify`（增幅），不是全文件找到任一 type 后套给所有表。type 后的数值可能仍归在未闭合的 table type 子 section 下，读取时不能只数 table 的直接值。重复匹配、缺失匹配要停止。无 type 的旧格式仅在唯一 table 时接受。
|
||||
|
||||
|布局|每级宽度|失败率|失败操作|降级参数|材料ID|数量|
|
||||
|---|---:|---:|---:|---:|---:|---:|
|
||||
|旧表|17|6|7|8|9|10|
|
||||
|typed 武器|24|8|10|11|14|15|
|
||||
|typed 防具|24|9|12|13|14|15|
|
||||
|
||||
表内第一个数值行对应 +1；旧 GUI 最多展示 31 行，超出部分保留。原始失败率 F 为 0～100000 的整数，成功率百分数 P 的写入公式是 `round((100-P)*1000)`，不是 P×100，也不是成功率字段。武器/防具概率和失败处理独立，材料共用。失败操作合法值 1～3，具体语义先查枚举；从降级操作 2 切换到其他操作时把降级参数清零。其余可编辑成本应为非负 32 位整数。
|
||||
|
||||
`[safe upgrade]` 每条 8 个整数：列 0 是原等级（GUI 显示 +原等级+1），列 2 失败率、列 3 失败补正原始值、列 5 材料 ID、列 6 数量、列 7 金币。列 1、4 保留。安全强化输入的是失败率，百分数乘 1000；不要套用普通强化的成功率转换。按原等级筛选行，而非假定行序号就是等级。
|
||||
|
||||
## 锻造
|
||||
|
||||
`[table]` 每级 4 项：属性系数 A、属性系数 B、成功率、材料消耗倍率。成功率原值 0～10000，百分数 P 对应 round(P×100)。A/B 在 GUI 只读，未要求时保留。倍率与系数可能为浮点，保留类型。
|
||||
|
||||
`[separate upgrade max]` 唯一整数，范围 1～表行数。`[item weights by grade]` 及可选 `[item weights by grade 100lv]` 每条为装备等级、材料 ID、数量基数；装备等级递增且大于 0。材料实际消耗还受锻造倍率等参数影响，不能把数量基数直接描述成最终成本。保留其他 section。
|
||||
|
||||
预览时分别说明概率口径、等级、武器/防具范围、材料与金币变化，再应用并读取验证。
|
||||
|
||||
操作前阅读 [MCP 操作流程](references/mcp-workflow.md)，按其查询、验证、预览、应用和保存规则执行。
|
||||
@@ -0,0 +1,19 @@
|
||||
# MCP 操作流程
|
||||
|
||||
此 skill 面向正在运行的 pvfine MCP 服务。安装 skill 不会自动配置连接；先在 pvfine「偏好设置 → MCP 服务」启用服务，将连接配置加入 AI 客户端。以下是服务端工具名，客户端可能增加前缀。
|
||||
|
||||
1. 调用 `pvf_workspace_info`，确认归档、workspaceId、revision 和 versionLoading。未打开归档时先根据用户指定的本机绝对路径使用 `pvf_archive_open`，传入 workspaceEpoch 作为 expectedWorkspaceEpoch；不擅自丢弃未保存内容。
|
||||
2. 查询用 `pvf_search`（mode=path/content）、`pvf_read_file`。查询读取工具传入 workspaceId 与 expectedRevision=revision。read_file 每页最多 100 行，根据 nextLine 继续；搜索按返回分页继续，不能把第一页当作完整结果。
|
||||
3. 不清楚字段时用 `pvf_annotation_search`（filePath、section、workspaceId），再以返回的 documentId/rulesRevision 调用 `pvf_annotation_get`。用 `pvf_annotation_explain` 查看当前文件的枚举、字符串引用和关联目标。说明缺失时先读取实际结构，不猜测字段含义。
|
||||
4. 编写脚本前读取 `pvf_script_help(topic="types")` 获取当前完整声明，必要时读取 sections/lists/strings 帮助。沙箱只有 `pvf`，没有 Node、网络或本机文件系统；查询通过 `pvf.log(JSON.stringify(result))` 输出，限定文件范围，避免输出整个归档。
|
||||
5. 脚本先 `pvf_script_validate(source)`；通过后 `pvf_script_run(workspaceId, expectedRevision, source, label, requestId)`。轮询 `pvf_script_status(taskId)` 至完成，检查日志与诊断，取得 planId。查询脚本无修改时可以没有 planId。
|
||||
6. 有变更时用 `pvf_script_preview(planId, cursor, limit)` 看完全部差异，核对文件、字段、旧值、新值与范围。只应用符合用户指令的 changeKey；引用新增 .str 文本时一并选择对应字符串表依赖。调用 `pvf_script_apply(workspaceId, expectedRevision, planId, changeKeys, requestId)` 后用 `pvf_task_status` 等待结束。
|
||||
7. 应用仅修改内存工作区。重新获取 workspace_info 并读取验证；用户要求保存时才调用 `pvf_archive_save`。`pvf_archive_save_as` 生成副本，后续保存仍写源归档。最终明确说明修改路径、数值、应用状态和磁盘保存状态。
|
||||
|
||||
每个新修改请求使用唯一 requestId；同一次请求的网络重试复用原 ID。遇到 STALE_WORKSPACE 重新查询和生成预览，不用新修订号强行应用旧计划。TASK_BUSY、前端草稿或冲突时先处理阻塞；失败不盲目重试。废弃预览用 pvf_script_discard。
|
||||
|
||||
## 脚本读写
|
||||
|
||||
文件路径是归档内部路径。`pvf.find(path)` 返回句柄或 null；`file.parse()` 得到文档，`doc.sections(path)` 返回全部同名 section，路径与嵌套参数以当前 types 声明为准。`section.get(i)`/`set(value,i)` 访问零基索引；`values()`/`setValues()` 操作直接值；修改文档后须 `file.write(doc)`。每次先验证 section 数量、长度、类型与旧值，再改目标字段。不要用 setValues 重建含子 section 的复合块。必要时用 file.text()/setText() 做精确的局部文本替换，保留未涉及内容、类型标记和闭合标签。
|
||||
|
||||
读取 `<表号::键名>` 用 `getOriStrValue`；修改时按当前 strings API 保留引用语义。ID 不等于文件索引；使用标注关联或 `pvf.lst(path)` 解析路径。新建文件要同步正确 lst 注册，删除文件不会自动注销。MCP 不支持文件集修改。
|
||||
Reference in new issue
Block a user