joywayerandClaude Opus 5
ba7c885291
_handle_auto_cast 用 if 而非 while，每物理帧至多施法一次，故本属性存在饱和点 = (1/60) / 法杖基准间隔：wand_basic(0.5s) ≈ 0.033、wand_fast(0.25s) ≈ 0.05。 原 hard: 0.01 在两把主力杖上都深深落在饱和区内——玩家把 cast_delay_mod 从 0.033 一路买到 0.01，射速一点没变，属"承诺了循环交付不了的东西"。 取 0.05 使 wand_fast 恰在硬上限处饱和、wand_basic 全程无无效区间。 边界实测（同一套 _physics_process 帧距扫描）：wand_fast@0.05 = 1 帧/次(60/s)、 wand_basic@0.05 = 2 帧/次(30/s)、请求 0.01 被 maxf(hard,…) 钳回 0.05 后帧距不变、 soft(0.1) 对照仍 3 帧/次(20/s)、circuit_fork@0.05 = 2 帧/次。 未加任何代码钳制：下限已由 attributes.json + AttributeFormula 的 maxf(hard,…) 强制，代码里再加一个会形成重复权威，设计师调 hard 时立刻脱同步。 spec 新增 §2.2b 收录完整实测数据集（饱和点公式与三把杖的值、soft→hard 是台阶 而非曲线、周期恒为 ceil(T×60) 且整帧倍数多花一帧故实际射速恒 ≤ 名义值）—— 结论易得而数据难得，故一并留档。circuit_fork 的饱和点 0.0278 标注为公式推导。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
7 lines
561 B
JSON
7 lines
561 B
JSON
{
|
|
"cpu_limit": { "display_name": "运算力 cpu_limit", "base": 0.0, "soft": 20.0, "hard": 50.0, "combine": "add_int" },
|
|
"move_speed": { "display_name": "移动速度 move_speed", "base": 200.0, "soft": 600.0, "hard": 800.0, "combine": "hybrid" },
|
|
"cast_delay_mod": { "display_name": "施法延迟 cast_delay_mod", "base": 1.0, "soft": 0.1, "hard": 0.05, "combine": "inverse" },
|
|
"hp_max": { "display_name": "最大生命 hp_max", "base": 100.0, "soft": 2000.0, "hard": 0.0, "combine": "hybrid" }
|
|
}
|