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 2026-11-04 14:31:55 +08:00
commit 645b64fe21
4388 files changed
+1405457

No files matched your search

@@ -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 不支持文件集修改。