zijunchiang/opendance-windows
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 7 Wiki Activity
36 Commits 2 Branches 7 Tags
86e5decd1061d487628b77f90eaa627718220bb1
Commit Graph
10 Commits
Author SHA1 Message Date
zijunchiang 76244d2d0d docs(tasks): 更正「Gitea 附件通道坏了/磁盘写满」的误判，并记录正确的上传写法 
排查 Windows 整包上传时的 HTTP 500 曾被判成"Gitea 宿主机磁盘写满"，**这个结论是错的**：
Gitea 的 Release 附件接口 multipart 字段名是 **`attachment`**，用 `file=` 会得到

  HTTP 500 {"message":"","url":"https://gitea.kasugano.cn/api/swagger"}

空消息，极易误判成服务器故障。同一 1 KB 文件、同一 Release 的实测对照：
  -F "attachment=@probe.bin"                → 201
  --data-binary @probe.bin（带 ?name=）      → 201
  -F "file=@probe.bin"                      → 500（空消息）

**真实且仍然存在的唯一限制**：IIS `maxAllowedContentLength`（默认 30,000,000 字节）——
927 KB / 14 MB / 16,372,427 B 通过；30.5 MB / 38,245,602 B / 40 MB 一律 **HTTP 413**
（本轮用正确字段名复测整包：413，仅发出 917 KB 即被拒）。

tasks/014-full-package.md 的「实测记录」改写为两段：真实限制 + 误判更正，
并附两种可直接照抄的上传命令（multipart `attachment` / 裸 body + `?name=`）。
 2026-09-17 03:40:27 +08:00
zijunchiang cbd5001e98 docs(tasks): 修正整包上传失败结论——与体积无关，指向 Gitea 宿主机磁盘 
原先记的「16.4 MB 边界」是误判（当时磁盘正被失败的请求逐步填满）。补做隔离
测试后：1 KB 与 100 KB 也失败且是**瞬间**失败（不是读完请求体才判断），三个仓库的
Release 资产接口同样失败，而创建 Release / PATCH 说明（纯 JSON）都正常，
其间还有 927 KB 的附件成功过一次 —— 因此不是体积上限，而是「附件文件落盘」这条
通道坏了，最可能是 Gitea 宿主机磁盘/临时目录几乎写满（返回 500 而非 413）。

IIS 那一关已确认放开生效（38,245,661 字节请求体被完整接收，不再 413）。
整包与 SHA256SUMS 已就绪，待宿主机空间问题解除后立即上传（不生成分卷）。

详见 opendance-web/deploy/proxy/README.md 第九节 9.1。
 2026-09-17 01:51:33 +08:00
zijunchiang e4b33a9c98 docs(tasks): 记录 v0.2.0 整包上传的两阶段实测（IIS 已放开，Gitea 侧仍 500） 
按文档 §5.7 硬性要求 4 记录实测上限：
- IIS 未放开时 30.5 / 40 MB 返回 413；
- IIS 放开后，38,245,661 字节的整包请求体被**完整接收**（115 s），
  但 Gitea 返回 HTTP 500（API 错误信封 message 为空）；
- 同接口边界：914 KB 与 16,372,427 B 通过，16,400,000 B 及以上失败；
  多次大包失败后连 100 KB 都会在 0.3 秒内 500 —— 更像上传临时目录 /
  数据盘写满（Gitea 先写 data/tmp），而不是体积上限。

结论：只放开 IIS 不足以放行 38 MB 整包，还需清理/扩容 Gitea 数据盘
并调整 app.ini 的 [attachment] MAX_SIZE；详见
opendance-web/deploy/proxy/README.md 第九节。
 2026-09-17 01:40:33 +08:00
zijunchiang c3a227c6df feat(net): 连接保活 / 设备去重 / 连接状态机（T-WIN-015，契约 websocket-keypoints 0.2.0） 
与 Android 端 T-AND-011「两端一起改」：契约先在 opendance-web 修改并提升到
websocket-keypoints 0.2.0（向后兼容：子协议名与二进制帧 version 均不变，
只新增可选控制字段与一种新控制类型），再同步三端快照。

修掉本端的 3 处根因/放大器：
1. 静默超时 5s 过短且未声明，客户端无从得知。OkHttp 的协议层 ping 由底层库
   自动应答、**不暴露给应用层**，无法刷新 last_seen_ms，于是"画面里没人"时
   每 5 秒必然踢一次连接 -> 客户端重连 -> 再被踢。
   - CLIENT_TIMEOUT_MS 5s -> 15s，新增 HEARTBEAT_INTERVAL_MS = 5s；
   - welcome_payload() 在 welcome 中声明 silentTimeoutMs / heartbeatIntervalMs，
     config 广播同样带上（契约 §1.1：心跳必须 < 静默超时的一半，5000*2 < 15000）；
   - 处理应用层 ping 并回 pong（回显 sentAtMs + serverAtMs，供对端算 RTT）。
2. 反复重连被计成多台设备。按契约 §5 用 hello.deviceId 去重：同一设备只保留
   最新连接，旧连接以 close(1000) 关闭——刻意用 1000，因为对端按契约 §7
   收到 1000 不会重连，否则会形成"挤掉-重连-再挤掉"的循环；
   新增 device_count() 与 device_replaced 信号，界面一律显示去重后的设备数。
3. 只有 handshaken 布尔量，日志看不出卡在哪一步。按契约 §8 逐客户端维护与
   Android 端同名的状态（connecting -> handshaking -> streaming -> degraded，
   主动停止/超时/被替换为 stopped），并记录 close code/reason、协商子协议、
   连接/握手/首帧时间；degraded 保持时长做成可覆盖字段便于测试。

验收测试（tests/test_pose_server.gd 新增 7 项，总计 720 通过 / 0 失败）：
welcome 声明保活参数、ping->pong 回显、同 deviceId 去重（旧连接 1000 关闭且
设备数仍为 1）、8 个状态名与契约一致、状态随握手/首帧推进到 streaming、
丢帧进入 degraded 后恢复、snapshot 暴露设备数与保活参数。

同时更新 README/README.txt/tasks 与 Credits 的契约版本（0.2.0）。
 2026-09-17 01:11:48 +08:00
zijunchiang 5581cbe05d feat(scene): 场景选择与物理落地 + 整包发布（T-WIN-012/013/014） 
T-WIN-013：API 升级与场景选择
- 契约快照同步到 rest-api 0.5.0 / data-models 0.7.0 / database 0.4.0
- catalog_types.gd 新增 SceneConfig（物理/环境/出生点/相机）与 Scene；
  CatalogBundle 增加 scenes[]；from_dict 按契约 7.1 再收敛一次
  （缺项默认、越界夹紧、非法枚举回退），与服务端 normalizeSceneConfig 同规则
- 新增 src/scene/scene_runtime.gd：GLB 载入 -> 碰撞体（mesh 三角网 /
  auto 命名约定 *_col、*_colonly / none 不兜底）-> 场景级重力（Area3D
  SPACE_OVERRIDE_REPLACE，不改全局 ProjectSettings）-> 风（每物理帧
  apply_central_force，阵风正弦叠加，支持 local 坐标系）-> 环境光与雾
  -> 出生点与相机（follow/fixed/orbit）；无碰撞体时兜底地面
- CatalogStore 增加 scenes/default_scene/find_scene/ensure_scene_cached/
  fetch_thumbnail（场景缓存带 sha256 指纹，避免换包后仍用旧 GLB）
- 主界面改为 2x2 四个选择器（曲目/动作/模型/场景）+ 场景参数面板
  （缩略图 + 重力/摩擦/弹性/碰撞体/风摘要）
- 游戏界面载入场景并落地物理，角色落在出生点；场景缺失/下载失败/
  解析失败一律回退内置空场景并提示，不阻塞开始跟练

T-WIN-012：「关于」清单展示当前版本号
- 版本唯一来源为 project.godot 的 application/config/version（v0.2.0）
- about_manifest() 输出版本/引擎/契约/协议/地址/隐私清单；
  无头测试无 autoload，读取 AppConfig 走 get_node_or_null 容错
- Credits 的单个 CONTRACT_VERSION 常量改为 CONTRACT_VERSIONS 字典
  （六项契约各自独立递增），并双向核对 contracts/VERSION

T-WIN-014：发布必须是单个完整包
- build/package-release.sh 重写：只产出单个 zip + SHA256SUMS，
  清理历史 .partN，超限时告警而非回退分卷；新增源产物与解压后完整性
  自检（PE 头 MZ / pck 魔数 GDPC / exe+pck 同目录同名）与体积-上限对比
- deploy/proxy 相关的 Gitea IIS 256MB 上限说明见 opendance-web

测试：tests/test_scene_config.gd（12 例）+ tests/test_about.gd（4 例）；
无头测试 687 通过 / 0 失败（10 个套件），verify.sh 全部通过
 2026-09-17 00:45:23 +08:00
opendance 4913760a8b docs: 消除 Gitea 模棱两可 Unicode 告警（全角标点紧邻 ASCII 时改为半角） 
依据 Gitea v1.27.3 modules/charset/escape_stream.go 的判定规则
（analyzeDetectResults：仅当左右相邻字符都不是非 ASCII 时才标记，
且 _common 表恒定生效），把说明文档中会被标记的全角标点
（，：；？！（） 等）改为半角，并保证成对括号宽度一致。
中文语境中的全角标点（左右均为中文）保持原样，不动代码与契约语义。
 2026-09-15 21:45:51 +08:00
zijunchiang 8c1d24865c docs: 全角 ｜ ／ ？ 改 ASCII（Gitea 混淆字符检测的剩余触发项） 2026-09-15 21:36:41 +08:00
zijunchiang 68a5ca0a87 docs: 其余易混淆字符（x/>=/<=/~/OK 取代 × − ≥ ≤ ≈ ✓） 2026-09-15 21:34:50 +08:00
zijunchiang 9f7b926a9a docs: 新增「初次部署（从零跑起来）」；去混淆字符与真实内网信息 
- README.md / README.txt 新增初次部署章节：前置条件、获取代码、首次运行、
  配置服务端地址（API 3000 / 管理端 3001 分离）、与 Android 的 WebSocket 联通、
  打包导出、自检清单、常见问题
- 三库同源契约：':=' 写法修回、去掉真实 MariaDB 版本串
- 全文去除易被 Gitea 判为「模棱两可 Unicode」的字符（- - ... -> 取代 — – … § →）
- 真实内网地址与库名改占位符
 2026-09-15 21:33:27 +08:00
zijunchiang a83e4f6a1f docs(win): 任务说明、DSH 约束与交付文档 2026-09-14 20:04:54 +08:00