zijunchiang/opendance-windows
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 7 Wiki Activity
50 Commits 2 Branches 7 Tags
main
Commit Graph
4 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 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