feat(all): add hunting and events, commerce and rewards, binary calendars, GameData caching and login diagnostics
Implement hunting AP and progress, event tasks, exchanges, games, stories and actions; connect battle and reward handling. Add CashShop plugin and installation, server purchases and entitlements, recharge rules and plugin version metadata. Distribute binary calendars independently; cache GameData in memory and fix single-connection query deadlocks. Improve automatic login and recovery diagnostics; document configuration and release flows.
This commit is contained in:
@@ -0,0 +1,75 @@
|
||||
# BD2 Client Studio
|
||||
|
||||
BD2 Client Studio 是独立的 Windows / macOS 客户端配置工具，不是服务端，也不包含玩家存档、`auth.db`、OAuth secret 或 master key。Linux 可以运行服务端，但不提供游戏客户端工具。
|
||||
|
||||
Windows 使用 Wails 和系统 WebView2 Runtime 创建桌面窗口，macOS 使用 Cocoa 和系统 WKWebView。窗口由客户端进程管理；关闭窗口会退出整个工具，退出工具也会关闭窗口。Windows 首次使用前应确保已安装 Microsoft Edge WebView2 Runtime：<https://developer.microsoft.com/microsoft-edge/webview2/>。
|
||||
|
||||
当前本机发布脚本只生成 Windows 包。macOS 源码保留，后续找到测试者或公开发布时，将使用 GitHub Actions 的 macOS runner 进行原生构建、测试和 `.app` 打包；目前未完成 macOS 实机验证。
|
||||
|
||||
启动后会打开配置工作台：
|
||||
|
||||
1. 选择 Brown Dust II 安装目录。Windows 选择包含 `BrownDust II.exe` 的目录；macOS 可选择 `BrownDust II.app` 或它的父目录。
|
||||
2. 填写要进入的服务器 origin，例如 `https://play.example.com` 或 `http://127.0.0.1:8080`。
|
||||
3. 选择 CDN：
|
||||
- **官方 CDN**：玩家直接从版本锁定的官方节点下载资源，适合朋友通过 FRP 联机。
|
||||
- **本机已下载资源**：选择同时包含 `ServerData` 和 `GameData` 的 CDN 根目录；LI 插件会在游戏进程内启动仅监听 loopback 的只读资源服务。
|
||||
- **服主资源**：通过服务器 `PUT /client/resources` 取得版本锁定的资源 URL；服主自建和反代对玩家客户端是同一种模式。
|
||||
4. 点击“应用客户端补丁”和“安装 / 更新插件”。
|
||||
|
||||
工作台的“连接设置”提供“代理 → 设置代理”入口。默认直接连接，不自动读取系统或终端环境中的代理。需要代理时，选择“手动 HTTP 代理”，填写例如 `http://127.0.0.1:12451` 的地址，点击“保存连接设置”，再通过工作台启动游戏。不要填写 Markdown 链接或 SOCKS 地址。
|
||||
|
||||
代理地址必须包含端口，不包含账号密码、路径或查询参数。HTTP 代理可通过 CONNECT 转发 HTTPS 请求，证书仍正常验证；本机 loopback 地址始终直连。配置同时用于客户端资源策略请求和新启动游戏的 HTTP 请求。修改代理后，需要正常退出游戏再重新启动；浏览器 OAuth 登录仍使用浏览器自身的网络设置。
|
||||
|
||||
客户端配置写入：
|
||||
|
||||
```text
|
||||
Windows: <游戏目录>/BepInEx/config/bd2.client.json
|
||||
macOS: <BrownDust II.app 的父目录>/BepInEx/config/bd2.client.json
|
||||
```
|
||||
|
||||
macOS 同时兼容把 BepInEx 放在 `BrownDust II.app/Contents/BepInEx` 的布局；若两个位置都存在，优先使用 App Bundle 外的标准 BepInEx 目录。
|
||||
|
||||
工具只写入：
|
||||
|
||||
```json
|
||||
{
|
||||
"schema_version": 2,
|
||||
"server_origin": "https://play.example.com",
|
||||
"cdn_mode": "official",
|
||||
"proxy_url": "http://127.0.0.1:12451"
|
||||
}
|
||||
```
|
||||
|
||||
`proxy_url` 可选，省略或留空表示直接连接。
|
||||
|
||||
`bd2client.exe` 启动时严格读取同目录的 `versions.json`。`game_version` 是支持的官方游戏版本；`client_version` 与 `server_version` 是分别演进的软件发布版本，格式为 `游戏版本+client.X.Y.Z` 与 `游戏版本+server.X.Y.Z`。资源仍由 `bundle_version` 和 `game_data_version` 锁定：
|
||||
|
||||
- 从所选客户端的 `BrownDust II_Data/globalgamemanagers` 读取 Unity `bundleVersion`，必须精确等于 `game_version`。不能使用 `BrownDust II.exe` 的 Windows `FileVersion`，该值是 Unity 引擎版本。
|
||||
- 本机资源必须包含当前 `bundle_version` 对应的 `catalog_alpha.json` / `.hash`，以及当前 `game_data_version` 对应的 `common-dbdata.info` / `.bin`。
|
||||
- 服主资源接口返回的 Bundle 和 GameData 版本必须分别精确匹配，不能互相替代。
|
||||
- `versions.json` 缺失、字段错误、出现未知字段或尾随 JSON 时，客户端工具拒绝启动。
|
||||
|
||||
本机资源模式会额外保存玩家自己选择的目录：
|
||||
|
||||
```json
|
||||
{
|
||||
"schema_version": 2,
|
||||
"server_origin": "http://127.0.0.1:8080",
|
||||
"cdn_mode": "local",
|
||||
"local_resource_directory": "E:\\bd2\\dl"
|
||||
}
|
||||
```
|
||||
|
||||
本机路径不会发送给服务器。插件不会直接依赖各加载链对 `file://` 的兼容性，而是在游戏进程内通过随机 loopback 端口提供 `GET`、`HEAD` 和单段 Range；该端口不会暴露给局域网。
|
||||
|
||||
补丁只把 Intro 中的地址替换成固定的本地占位地址，并保留 `resources.assets.bak`。真实服务器地址由 `BD2LocalIdentity.dll` 从 `bd2.client.json` 读取，因此不受 Unity 内置 27-byte URL 替换限制。
|
||||
|
||||
选择服主资源时，服务器必须在同一版本的 `resources.json` 中启用统一的 `server` 模式；客户端会使用严格的 `PUT /client/resources` 读取版本锁定 URL。客户端不会接受模式不匹配、版本不匹配、非 HTTPS（loopback 除外）或带凭据的资源地址。
|
||||
|
||||
界面语言按系统时区自动选择：中国大陆、香港、澳门和台湾地区使用简体中文，其他地区使用英文。诊断日志始终使用英文；Windows 保存在 `bd2client.exe` 同目录的 `logs/bd2client.log`，macOS 保存在 `~/Library/Logs/BD2 Client Studio/bd2client.log`。单文件最大 `2 MiB`，并只保留一个 `bd2client.log.1` 备份；日志不会写入 UI session、OAuth token 或 secret。
|
||||
|
||||
工具需要玩家事先安装 BepInEx。服务端不再安装客户端插件，也不需要知道玩家的 Windows 游戏目录。关闭游戏后再执行补丁或插件安装。
|
||||
|
||||
补丁与插件安装均可重复安全执行。Intro 已经指向当前占位地址时不会再次改写 `resources.assets`；两个已安装 DLL 与发布包内容一致时不会再次复制，并会明确提示已经完成或已经是最新版本。连接配置仍会按当前界面设置进行原子保存。
|
||||
|
||||
工作台右上角的“启动游戏”会再次验证所选客户端及精确版本，然后通过 Windows 进程启动或 macOS Launch Services 打开游戏。macOS 不会打开 Terminal。
|
||||
@@ -0,0 +1,48 @@
|
||||
# 项目排期文件
|
||||
|
||||
服务端从发布目录中的固定 `schedules/` 目录读取全部 `.bd2schedule` 文件，完整校验后合并下发排期。文件采用项目自定义二进制格式；没有 JSON 排期入口或服主自定义配置功能。项目维护者可在游戏版本不变时单独发布排期文件，覆盖相应文件后重启服务端加载。文件中的游戏和 GameData 版本标签表示协议、静态设计兼容性，排期 `revision` 独立表示日历修订。
|
||||
|
||||
## 二进制格式版本 1
|
||||
|
||||
整数使用小端编码。文件头固定 46 字节：
|
||||
|
||||
| 偏移 | 长度 | 内容 |
|
||||
| --- | --- | --- |
|
||||
| 0 | 8 | 魔数 `BD2SCH` 后接两个零字节 |
|
||||
| 8 | 2 | uint16 格式版本，当前为 1 |
|
||||
| 10 | 4 | uint32 payload 字节数 |
|
||||
| 14 | 32 | payload 的 SHA-256 原始摘要 |
|
||||
| 46 | payload 长度 | 按固定顺序编码的记录 |
|
||||
|
||||
payload 首先编码 revision、game version、GameData version 三个字符串，再依次编码事件列表、抽卡列表、StepUp 列表、可选常规内容日历、可选魔物追踪日历、商品列表、活动 Hub 列表、小游戏 Hub 列表。
|
||||
|
||||
字符串编码为 uint32 字节长度及 UTF-8 字节；列表编码为 uint32 记录数量及逐条记录；可选记录先写 0/1 存在标记；布尔值只允许单字节 0 或 1；身份、数量等整数字段编码为 uint64。每类记录采用显式固定字段顺序，权威定义为 `go/internal/server/calendar/records.go`，不使用反射或嵌入 JSON。单文件最多 8 MiB，单字符串最多 64 KiB，记录总量最多 100000；错误魔数、版本、摘要、长度、布尔值及尾随内容都拒绝加载。
|
||||
|
||||
记录内时间采用 RFC3339 UTC 字符串并保留毫秒，以保留跨年份和永久窗口语义。永久事件起点 `1969-12-31T15:00:00.000Z` 对应协议有符号 int64 的 `-32400000` 毫秒。它不是无符号巨大日期。二进制校验用于发现文件损坏，不代表密码签名。
|
||||
|
||||
项目维护者在代码中构建具名 `calendar.Manifest` 并调用 `calendar.MarshalBinary` 生成发行文件；读取使用 `calendar.UnmarshalBinary`。项目不提供从公开 JSON 输入生成排期的服主管理命令。发布时保留所有要下发的排期文件；运行时不从版本化 seed 或抓包补齐缺失数据。
|
||||
|
||||
## 初始数据来源
|
||||
|
||||
当前 `local-20261005-1` 保留已有时间、编号和协议标记，没有推算后续官方日程：
|
||||
|
||||
| 文件 | 初始记录 | 原始来源 |
|
||||
| --- | --- | --- |
|
||||
| `gacha.bd2schedule` | 普通抽卡 11，StepUp 2 | 已迁移删除的 `go/seed/v2_35_10/gacha_schedule.json` |
|
||||
| `regular.bd2schedule` | 常规内容 9，regular 标记 5 | 已迁移删除的 `go/seed/v2_35_10/schedule.json` |
|
||||
| `monster_hunt.bd2schedule` | 魔物追踪窗口 1，历史 78 | 原 `go/seed/v2_35_10/readonly.json` 的 `/MonsterHuntScheduleInfo` |
|
||||
| `cash_shop.bd2schedule` | 商品窗口 37 | 原 readonly seed 的 `/CashShopInfo` 商品行 |
|
||||
| `event_hubs.bd2schedule` | 活动 Hub 2，小游戏 slot 6 | 原 readonly seed 的 `/EventHubInfo`、`/MiniGameHubInfo` |
|
||||
| `events.bd2schedule` | 事件排期 54 | `data/capture/2.35.10/20261001-004259/bodies/000004_response_EventScheduleInfoResponse.pb` |
|
||||
|
||||
事件文件将以上同版本响应的既有身份和起止时间维护为项目日历；捕获的 `is_active` 不复制，由服务端根据当前时间重新计算。来源仅用于审计，运行时不读取抓包。UID 为 0 的多条任务以类型和设计组 ID 区分，不制造公开 UID。任务进度和领奖也使用对应组的独立本地身份。
|
||||
|
||||
Hub 的 UID 是 Hub 身份；slot 内的 UID 按内容类型引用事件、魔物追踪赛季等不同领域。例如 MonsterHunt slot 引用赛季 77/78。旧 Hub 74 的原始时间和子身份作为归档保留，当前捕获事件列表主要对应 Hub 75；不据此虚构已结束 Hub 的子事件窗口。Hub 的 play_end 与 end 独立保留，setting 可以引用多个 UID。
|
||||
|
||||
事件类型 8 的 ID 引用 `PackTable.Id`，依据当前客户端 `PackInfo.IsProgressUseScheduleEventPack` 和 `IsFinishEventPackSchedule`；它与 Hub 的 `PackEventHubTable.id`、`packId` 分属不同身份。小游戏 Hub 的 progress_type 表示普通、首次开放或复刻状态，不等于静态小游戏的 eventClearType。
|
||||
|
||||
商品每日、每周、每月重置时间由运行时根据当前时间生成。`SkyWayScheduleInfo` 的 weekday/bonus 规则仍属于静态 seed，`PassInfo` 和 `SeasonRewardInfo` 属于玩家或奖励域。
|
||||
|
||||
## 更新和验证
|
||||
|
||||
排期更新由项目维护，相关文件的 revision 随数据修订更新。仅调整时间无需修改游戏版本；引用不同静态设计时必须更新相应版本标签并校验实际 GameData。加载同时校验跨文件重复身份、时间窗口和可玩设计引用，全部通过才下发。事件类型 0、1、4、5、7、8、9、10、11、12、13、17、19 和 20 至 25 校验对应 GameData；类型 3、6、14、15、16、18 当前仅校验协议范围和格式。魔物追踪可玩窗口校验实际 hunt 设计，归档历史仅校验显示记录格式；小游戏 Hub 的 progress_type 校验状态格式。公共日历保留未来、当前和归档记录，玩法入口及进行中标记根据时间和玩家状态限制。
|
||||
Reference in New Issue
Block a user