From a6c6fdbf1e4752ebb0f930cdf3c40130bf283e2c Mon Sep 17 00:00:00 2001 From: Joywayer Date: Fri, 31 Jul 2026 11:58:21 +0800 Subject: [PATCH] =?UTF-8?q?docs(plan):=20Task5=20=E8=A1=A5=20Step7b?= =?UTF-8?q?=E2=80=94=E2=80=94=E5=AE=88=E5=8D=AB=E9=9B=B6=E8=AF=AF=E6=8A=A5?= =?UTF-8?q?=E5=AE=9E=E6=B5=8B=20+=20cast=5Fdelay=5Fmod=20=E9=A5=B1?= =?UTF-8?q?=E5=92=8C=E7=82=B9=E4=B8=8A=E6=8A=A5?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Task 3 复审转来两项： ① 守卫搬到 equip_wand 后需跑一局确认零误报——六条进入路径靠眼读弱于跑一局， 且误报的症状与它要报的故障一模一样，是自伤式回归。 ② hard: 0.01 承诺了循环交付不了的东西：_handle_auto_cast 用 if 非 while， 每帧至多一次施法，wand_basic 在 cast_delay_mod≈0.033 即饱和，且速率按整帧 量化成 60/30/20/15 的台阶。需人定：写明饱和区，或把 hard 提到 ~0.05。 明确不在代码里加下限钳制——会与 attributes.json 形成重复权威。 另收两条 Minor：注释里会腐烂的行号引用改函数名、combat_test 注入补理由交叉引用。 Co-Authored-By: Claude Opus 5 --- .../plans/2026-07-31-player-attributes.md | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/docs_dev/plans/2026-07-31-player-attributes.md b/docs_dev/plans/2026-07-31-player-attributes.md index 9089d63..332cf9c 100644 --- a/docs_dev/plans/2026-07-31-player-attributes.md +++ b/docs_dev/plans/2026-07-31-player-attributes.md @@ -718,6 +718,30 @@ Co-Authored-By: Claude Opus 5 EOF ``` +- [ ] **Step 7b: 守卫零误报 + `cast_delay_mod` 饱和点（Task 3 复审转来）** + +**① 开一局，确认日志里零条 `cpu_limit=0` 报错。** +Task 3 把守卫从施法处搬到了 `PlayerManager.equip_wand`。复审静态核对了全部六条进入路径（`start_game` 58→76、`resume_game` 68→76、`switch_core` 139→140、`_apply_padded` 184→185、`apply_wand_save_data` 299 无 `equip_wand`、`combat_test.gd` 18-19→20），确认 `_rebuild_wand`/显式注入总在 `equip_wand` 之前。但**六条路径靠眼读弱于跑一局** —— 若守卫误报，症状看起来和它要报的故障一模一样，是自伤式回归。 + +Run: `play_scene` 开一局，`get_editor_errors` / `get_output_log` 确认**零条** `cpu_limit=0`。换一次杖（商店「法杖」按钮）后再确认一次。 + +**② `cast_delay_mod` 的 `hard: 0.01` 承诺了循环交付不了的东西 —— 这是设计决策，需上报而非在代码里解决。** + +`_handle_auto_cast` 用 `if` 而非 `while`，故**每物理帧至多一次施法**，硬顶约 60 次/秒。于是该属性存在饱和点： +- `wand_basic`（0.5s 基准）：`cast_delay_mod ≈ 0.033` 即饱和，从那里到 `hard` 0.01 之间**买不到任何东西**。 +- `wand_fast`（0.25s）：饱和点约 0.067。 +- 且 `:81` 是**赋值**而非累积溢出，故实际速率按整帧量化 —— 60 / 30 / 20 / 15 次/秒，快端是台阶而非平滑。 + +设计区间（`soft` 0.1 → 0.05s = 3 帧）是诚实的，问题只在 soft→hard 那段。**两个选项，需人定**： +- (a) 保持 `hard: 0.01`，在 `numerical_design.md` 与 `attributes.json` 注释里写明「0.033 以下为饱和区，不再提升实际射速」； +- (b) 把 `hard` 提到 ~0.05，让 JSON 承诺的是真能交付的东西。 + +**不要在代码里加下限钳制** —— 下限已由 `attributes.json` + `AttributeFormula` 的 `maxf(hard, ...)` 强制，在 `player_manager` 再加一个会形成重复权威，设计师调 `hard` 时立刻脱同步，违反「纯数据驱动，代码不含硬编码副本或回退」。 + +**③ 顺带收两条 Task 3 复审的 Minor**（可并入本步任一提交）： +- `player_manager.gd:96` 注释里的 `player_stats.gd:173/191` 行号引用会腐烂，改为函数名：「已分别由 `PlayerStats._load_attr_definitions` 与 `add_modifier` 报出」。 +- `scenes/main/combat_test.gd:17-19` 的注入只有不变式没有理由，补一句 `# 顺序理由见 combat_manager._rebuild_wand`。 + - [ ] **Step 8: 回填本计划为实际执行版** 实现过程中若因评审而改动了代码或断言，**本计划里对应的代码块与脚本必须回填为实际落地的版本**，并勾上各任务的复选框。否则任何人按这份计划复跑，得到的是过时代码和可能已失效的断言 —— 归航那期就踩过这个坑。