refactor: 重构效果参数处理逻辑
All checks were successful
ci/woodpecker/push/my-first-workflow Pipeline was successful
All checks were successful
ci/woodpecker/push/my-first-workflow Pipeline was successful
This commit is contained in:
@@ -1,648 +0,0 @@
|
||||
# Effect 重构会话总结(2026-03-28)
|
||||
|
||||
## 1. 本次会话完成内容
|
||||
|
||||
### 1.1 注释与说明统一
|
||||
- 已将 `logic/service/fight/effect` 下效果注释统一为:
|
||||
- `// Effect <id>: <desc>`
|
||||
- 说明来源:
|
||||
- `public/config/effectInfo.json`
|
||||
|
||||
### 1.2 结构整理与公共能力抽取
|
||||
- 新增并使用了子效果统一挂载 helper:
|
||||
- `addSubEffect(...)`
|
||||
- 已清理 `effect` 目录中的 `GenSub(...)` 直接调用残留,统一走 helper。
|
||||
|
||||
### 1.3 回合类基类(组合继承)已落地
|
||||
- 当前已引入的 base(位于 `logic/service/fight/effect/sub_effect_helper.go`):
|
||||
- `RoundEffectArg0Base`
|
||||
- `RoundEffectSideArg0Base`
|
||||
- `FixedDuration1Base`
|
||||
- `FixedDurationNeg1Base`
|
||||
- `FixedDuration2Base`
|
||||
- `RoundEffectArg1Base`
|
||||
- `RoundEffectSideArg1Base`
|
||||
- `RoundEffectSideArg0Minus1Base`
|
||||
- `RoundEffectSideArg0Minus1CanStackBase`
|
||||
|
||||
- 已有大量效果结构体改为嵌入上述 base,删除重复 `SetArgs` 模板代码。
|
||||
|
||||
### 1.4 编译状态
|
||||
- 已多轮执行并通过:
|
||||
- `go test ./logic/service/fight/effect`
|
||||
|
||||
### 1.5 本轮新增 effect 实现
|
||||
- 新增缺失效果实现:
|
||||
- `400` 若和对手属性相同,则技能威力翻倍
|
||||
- `480` `{0}`回合内自身所有攻击威力为两倍
|
||||
- `586` `{0}`回合内自己的属性攻击必中
|
||||
- `599` `{0}`回合内受到`{1}`伤害减少`{2}%`
|
||||
- `610` 遇到天敌时先制+`{0}`
|
||||
- `611` 下`{0}`回合自身使用攻击技能则附加`{1}`点固定伤害
|
||||
- `613` `{0}`回合内自身令对手使用的`{1}`系攻击技能无效
|
||||
- `573` `{0}`回合内若自身能力提升状态被消除或吸取则`{1}`%使对手`{2}``{3}`回合
|
||||
- `587` `{0}`回合内若被对手击败则对手损失`{1}`点体力,造成致命伤害时,对手剩余1点体力
|
||||
- `591` 造成伤害大于`{0}`,则下`{1}`回合自己所有直接攻击先制+`{2}`
|
||||
- `592` 下`{0}`回合每回合使用攻击技能`{1}`%令对手`{2}`
|
||||
- `594` 造成的伤害低于`{0}`时`{1}`%令对手`{2}`
|
||||
- `596` 技能使用成功时,`{0}`%给予对手冻伤、中毒、烧伤中任意一种异常状态
|
||||
- `597` `{0}`回合内每回合使用技能吸取对手最大体力的1/`{1}`
|
||||
- `598` `{0}`%恢复自己所有技能PP值`{1}`点
|
||||
- `627` 对手处于能力提升状态时附加其`{0}`值`{1}`%的百分比伤害
|
||||
- `628` 若对手处于能力下降状态则造成伤害的`{0}`%恢复体力
|
||||
- `629` 消除`{0}`状态,消除成功下回合自身先制+`{1}`
|
||||
- `630` `{0}`回合内`{1}`状态被消除,则有`{2}`%概率使对手`{3}`
|
||||
- `631` 消除`{0}`状态,消除成功下回合造成伤害提升`{1}`%
|
||||
- `632` 造成伤害`{0}``{1}`,则下`{2}`回合必定暴击
|
||||
- `633` 造成伤害`{0}``{1}`,则造成伤害的`{2}`%恢复体力
|
||||
- `634` 若当前体力`{0}`对手,则造成伤害的`{1}`%恢复体力
|
||||
- `635` 吸收对手能力上升状态,吸收成功,下回合先制+`{0}`
|
||||
- `636` 消除`{0}`状态,消除成功则令对手`{1}`
|
||||
- `637` 若对手处于异常状态,则对手`{0}``{1}`
|
||||
- `638` 若对手`{0}`,技能威力提升`{1}`%
|
||||
- `639` 造成伤害`{0}``{1}`,则下`{2}`回合所有技能附带`{3}`点固定伤害
|
||||
- `640` 命中后`{0}`%使对手`{1}``{2}`回合,遇到天敌概率翻倍
|
||||
- `641` 命中后`{0}`%使对手进入流血状态
|
||||
- `401` 若和对手属性相同,则技能威力翻倍
|
||||
- `585` 技能使用成功时,`{0}`
|
||||
- `589` 复制对手`{0}`的能力提升状态
|
||||
- `590` 使对手`{0}`,`{6}`%弱化效果翻倍
|
||||
- `593` 附加`{0}`的`{1}`值的`{2}`%的百分比伤害
|
||||
- `595` 技能使用成功时,`{0}`%使对手`{1}`,若没有触发,则对手`{2}`
|
||||
|
||||
- 已同步更新:
|
||||
- `logic/service/fight/effect/effect_info_map.go`
|
||||
|
||||
### 1.6 本轮新增文件
|
||||
- `logic/service/fight/effect/400_480_586_599_610_611_613.go`
|
||||
- `logic/service/fight/effect/573_587_591_592_594_596_597_598.go`
|
||||
- `logic/service/fight/effect/627_631.go`
|
||||
- `logic/service/fight/effect/632_636.go`
|
||||
- `logic/service/fight/effect/637_641.go`
|
||||
- `logic/service/fight/effect/effect_info_map.go`
|
||||
|
||||
### 1.7 本轮验证
|
||||
- 已执行:
|
||||
- `go test ./service/fight/effect`
|
||||
- 结果:
|
||||
- 通过
|
||||
|
||||
### 1.8 本轮结论
|
||||
- 当前这轮更适合按“低风险、可复用现有模式”的 effect 小批次推进,而不是一次性追求 `effectInfo.json` 全量覆盖。
|
||||
- 现有 `effect` 目录里已经有不少“共享实现 + 批量注册”的写法,后续判断缺失项时不能只靠 grep `InitEffect(...)`。
|
||||
- 文档第 3 节里的“未实现”列表目前仍是历史扫描快照,只能作为候选列表,不能直接当最终事实使用。
|
||||
|
||||
---
|
||||
|
||||
## 2. 当前仍保留自定义 `SetArgs` 的效果(建议下一轮重点)
|
||||
|
||||
以下属于“非纯模板”或“仍待抽象”的 SetArgs:
|
||||
|
||||
- `Effect570`(`570.go`)
|
||||
- `Effect123`(`effect_119_123.go`)
|
||||
- `Effect41`(`effect_41.go`)
|
||||
- `Effect42`(`effect_42.go`)
|
||||
- `Effect46`(`effect_46.go`)
|
||||
- `Effect47`(`effect_47.go`)
|
||||
- `Effect48`(`effect_48.go`)
|
||||
- `Effect60`(`effect_60.go`)
|
||||
- `EffectPropSyncReverse`(`effect_attr.go`)
|
||||
- `SelfKill`(`selfkill.go`)
|
||||
|
||||
建议分三类继续抽 base:
|
||||
- 随机回合/随机次数类(如 41、42)
|
||||
- 次数型常驻类(如 46、47、48、SelfKill、570)
|
||||
- “SetArgs + 额外上下文初始化”类(如 Effect123、EffectPropSyncReverse)
|
||||
|
||||
---
|
||||
|
||||
## 3. 未实现(或疑似未实现)效果清单
|
||||
|
||||
### 3.0 从 `effectInfo.json` 提取的“未实现”总览(自动扫描)
|
||||
- JSON 配置总效果数:`2112`
|
||||
- 代码已注册效果数(Skill):`338`
|
||||
- JSON 中存在但代码未注册:`1779`
|
||||
- 代码中注册但 JSON 无对应条目:`5`(`21, 31, 41, 42, 174`)
|
||||
|
||||
说明:
|
||||
- 这个口径是“配置覆盖率”,不是“bug 数量”。
|
||||
- 其中大量属于未来版本/未迁移内容,不建议一次性全补;建议按战斗系统实际启用范围分批实现。
|
||||
- 以下列表为上一轮扫描快照,未随本轮新增实现实时回算。
|
||||
- 此外,扫描脚本若未把“共享实现中的批量注册”统计进去,也会把已实现效果误判成缺失。
|
||||
|
||||
JSON 中存在但代码未注册(示例前 60 项):
|
||||
- 2, 10, 11, 12, 14, 15, 16, 17, 22, 30
|
||||
- 38, 40, 45, 51, 55, 56, 61, 64, 66, 67
|
||||
- 70, 78, 84, 86, 92, 94, 96, 97, 99, 102
|
||||
- 103, 104, 106, 108, 109, 114, 118, 132, 133, 139
|
||||
- 141, 158, 162, 167, 168, 185, 401, 421, 431, 529
|
||||
- 543, 554, 569, 573, 581, 582, 583, 584, 585, 586
|
||||
|
||||
### 3.1 明确标记未实装
|
||||
- 文件存在明确标记:
|
||||
- `logic/service/fight/effect/529.go未实装`
|
||||
|
||||
### 3.2 已注册但缺少同名 `Effect{id}` 结构体(需人工确认是否由合并实现覆盖)
|
||||
- `53`
|
||||
- `74`
|
||||
- `75`
|
||||
- `186`
|
||||
- `402`
|
||||
- `433`
|
||||
- `446`
|
||||
- `451`
|
||||
- `463`
|
||||
- `497`
|
||||
- `564`
|
||||
- `588`
|
||||
|
||||
说明:
|
||||
- 这类通常可能是“多个 id 共用一个结构体实现”或“命名与 id 不一致”,需要逐个确认是否真正缺失行为。
|
||||
|
||||
### 3.3 疑似未实现(扫描规则:存在 `Effect{id}` 类型,但没有核心战斗 Hook)
|
||||
- `519`(`effect_519.go`)
|
||||
- `532`(`532.go`)
|
||||
- `552`(`552.go`)
|
||||
- `560`(`560.go`)
|
||||
- `576`(`576.go`)
|
||||
|
||||
说明:
|
||||
- 这批是“高优先级人工复查项”,不一定真的没实现,可能通过组合/间接机制生效。
|
||||
|
||||
### 3.4 当前更可信的“下一批候选”
|
||||
这一组是结合本轮人工核对后,仍然值得优先继续补的缺失 effect 候选:
|
||||
|
||||
- 当前文档 3.4 中这批候选已在本轮补齐。
|
||||
|
||||
说明:
|
||||
- 这批大多是 58x/59x 段的新效果,和当前目录中已有实现重叠较少。
|
||||
- 相比继续深挖旧扫描误差,这批更适合直接新增文件推进。
|
||||
|
||||
---
|
||||
|
||||
## 4. 下次继续的建议顺序
|
||||
|
||||
建议严格按下面顺序继续,不要重新从全量扫描开始:
|
||||
|
||||
1. 先复核文档 3.4 里的候选项是否仍未实现。
|
||||
2. 优先补“单次触发、命中附加、固定伤害、恢复、概率状态”这类低风险逻辑。
|
||||
3. 再处理“复制对手状态 / 多分支条件 / 触发链式子效果”的 58x/59x 复杂效果。
|
||||
4. 最后再回头处理文档 2 中那些仍保留自定义 `SetArgs` 的结构整理。
|
||||
|
||||
本轮更推荐的下一批实现顺序:
|
||||
|
||||
- 第一组:`529 / 552 / 560 / 576`
|
||||
- 第二组:`10 / 11 / 12 / 14 / 15 / 16`
|
||||
- 第三组:`94 / 99 / 103 / 114`
|
||||
|
||||
---
|
||||
|
||||
## 5. 下一次继续让我实现时可直接复制的指令
|
||||
|
||||
可直接用下面这句发起:
|
||||
|
||||
`继续处理 effect,按 docs/effect-refactor-summary-2026-03-28.md 的 3.3 和 4 执行:先复核 529/552/560/576,再补低风险状态附加类 10/11/12/14/15/16,每实现一批就更新同一文档和 effect_info_map.go,并跑 go test ./service/fight/effect。`
|
||||
|
||||
如果你希望按 JSON 覆盖率推进,可用这句:
|
||||
|
||||
`继续处理 effect,按 docs/effect-refactor-summary-2026-03-28.md 的 3.0 从低风险效果开始补实现:先补状态附加类(10/11/12/14/15/16/94/99/103/114),每实现一批就更新文档中的“已实现列表”和“剩余列表”。`
|
||||
|
||||
---
|
||||
|
||||
## 6. 扫描口径说明(供后续排查)
|
||||
|
||||
- 已注册效果 ID 扫描来源:
|
||||
- `InitEffect(input.EffectType.Skill, <id>, ...)`
|
||||
- `initskill(<id>, ...)`
|
||||
- 但这还不够,后续扫描必须额外统计这些“共享实现/批量注册”文件:
|
||||
- `sterStatusEffects.go`
|
||||
- `effect_power_doblue.go`
|
||||
- `EffectAttackMiss.go`
|
||||
- `EffectPhysicalAttackAddStatus.go`
|
||||
- `EffectDefeatTrigger.go`
|
||||
- `effect_attr.go`
|
||||
- `effect_EffectConditionalAddDamage.go`
|
||||
- `effect_74_75.go`
|
||||
- `effect_104_109.go`
|
||||
- `Effect{id}` 结构体与方法扫描来源:
|
||||
- `logic/service/fight/effect/*.go`
|
||||
- “疑似未实现”判断是启发式,不是最终结论,仍需代码级确认。
|
||||
|
||||
---
|
||||
|
||||
## 7. 这次改动涉及的关键文件
|
||||
|
||||
- `public/config/effectInfo.json`
|
||||
- `logic/service/fight/effect/400_480_586_599_610_611_613.go`
|
||||
- `logic/service/fight/effect/573_587_591_592_594_596_597_598.go`
|
||||
- `logic/service/fight/effect/effect_info_map.go`
|
||||
- `logic/service/fight/effect/sub_effect_helper.go`
|
||||
- `docs/effect-refactor-summary-2026-03-28.md`
|
||||
|
||||
---
|
||||
|
||||
## 8. 2026-03-29 增量记录
|
||||
|
||||
### 8.1 本轮补齐的 effect
|
||||
- `663` `{0}回合内若对手使用攻击技能则{1}%使对手{2}`
|
||||
- `664` 若先出手则当回合对手无法造成攻击伤害
|
||||
- `665` 造成的伤害低于`{0}`则`{1}`回合内自身受到的伤害减少`{2}`
|
||||
- `666` 使自身下回合攻击必定先手、必定暴击
|
||||
- `667` 自身为满体力时`{0}{1}`
|
||||
|
||||
### 8.2 实现口径
|
||||
- `663` 复用与 `614` 同类的“对手使用攻击技能时触发”路径,在 `Skill_Use_ex()` 中按概率给对手附加状态。
|
||||
- `664` 复用 `170` 的先手免伤模式,在 `DamageLockEx()` 中将当回合受到的攻击伤害归零。
|
||||
- `665` 按技能实参 `250 3 100` 的实际使用方式,落为“低于阈值则给自己挂 3 回合 100 点固定减伤子效果”,不是百分比减伤。
|
||||
- `666` 落为仅对下回合攻击技能生效的先手与暴击保证:`ComparePre()` 强制先手,`ActionStart()` 强制暴击。
|
||||
- `667` 按配置说明“自身攻击+a、防御+b、特攻+c、特防+d、速度+e、命中+f”处理,仅在满体力时给自己附加前 6 项能力等级。
|
||||
|
||||
### 8.3 本轮新增文件
|
||||
|
||||
---
|
||||
|
||||
## 16. 2026-03-31 增量记录
|
||||
|
||||
### 16.1 本轮补齐的 effect
|
||||
- `764` `{0}回合内若对手使用攻击技能降低对手最大体力的1/{1}`
|
||||
- `765` `{0}回合对手无法使自身能力出现提升状态`
|
||||
- `766` 消除对手能力提升状态,消除成功则`{0}`回合内对手造成的攻击伤害不超过`{1}`点
|
||||
- `767` `{0}`回合内每回合使用技能且出手流程结束后若对手处于能力下降状态则附加给对手`{1}`点固定伤害
|
||||
- `768` 对手每处于一种异常状态则附加`{0}`点固定伤害
|
||||
- `774` 若自身当前体力高于对手则附加对手最大体力1/`{0}`的百分比伤害
|
||||
- `775` `{0}`回合内若受到的伤害大于`{1}`,则恢复自身所有体力
|
||||
- `777` 消除对手能力上升状态,消除成功下`{0}`回合必定先出手
|
||||
- `778` 反转对手的能力提升状态,反转成功则恢复自身所有体力
|
||||
- `779` 若对手处于能力提升状态则先制+2
|
||||
|
||||
### 9.2 已存在并复核通过
|
||||
- `776` 已实现于 `logic/service/fight/effect/effect_776.go`
|
||||
|
||||
### 9.3 本轮新增文件
|
||||
- `logic/service/fight/effect/764_768.go`
|
||||
- `logic/service/fight/effect/774_779.go`
|
||||
|
||||
### 9.4 本轮同步更新
|
||||
- `logic/service/fight/effect/effect_info_map.go`
|
||||
|
||||
### 9.5 本轮顺手修复的同包编译阻塞
|
||||
- `logic/service/fight/effect/2195_2219.go`
|
||||
- 修正 `uint32 * int` 的类型不匹配
|
||||
- `logic/service/fight/effect/2220_2244.go`
|
||||
- 修正将 `info.Category` 误当函数调用的问题,改为 `info.EnumCategory`
|
||||
|
||||
### 9.6 本轮验证
|
||||
- 已执行:
|
||||
- `cd /workspace/logic && go test ./service/fight/effect`
|
||||
- `cd /workspace/logic && go build ./...`
|
||||
- 结果:
|
||||
- 通过
|
||||
|
||||
### 9.7 任务文档状态
|
||||
- `task-031-effects-764-768.md` 本轮已可视为完成
|
||||
- `task-033-effects-774-779.md` 本轮已可视为完成(`776` 为既有实现)
|
||||
- 本轮未删除任务文档;如下一轮继续清理 backlog,可直接移除这两份任务文件
|
||||
|
||||
### 9.8 后续增量
|
||||
- 已继续补齐:
|
||||
- `785` 若自身攻击对手时克制关系为微弱则先制+2
|
||||
- `786` 令对手随机进入`{0}`种异常状态
|
||||
- `787` `{0}`回合内使用技能后若对手处于能力提升状态则附加对手最大体力1/`{1}`的百分比伤害
|
||||
- `788` 消除对手能力提升,消除成功`{0}`回合内免疫异常状态
|
||||
- `789` 消除对手回合类效果,消除成功对手下`{0}`回合受到的伤害翻倍
|
||||
- 新增文件:
|
||||
- `logic/service/fight/effect/785_789.go`
|
||||
- `logic/service/fight/effect/795_799.go`
|
||||
- 已继续补齐:
|
||||
- `795` 每次使用则当回合造成的攻击伤害额外提升`{0}`%,最高额外提升`{1}`%
|
||||
- `796` `{0}`回合内每回合吸取对手当前体力的1/`{1}`
|
||||
- `797` 消除对手回合类效果,消除成功`{0}`回合内对手无法通过自身技能恢复体力
|
||||
- `798` 若对手处于能力提升状态,则对手`{0}`回合内造成的伤害不超过`{1}`
|
||||
- `799` 恢复自身最大体力的1/`{0}`并给对手造成等量百分比伤害,自身体力低于1/`{1}`时效果翻倍
|
||||
- `logic/service/fight/effect/663_667.go`
|
||||
|
||||
### 8.4 本轮同步更新
|
||||
- `logic/service/fight/effect/effect_info_map.go`
|
||||
- `docs/effect-unimplemented-tasks/task-013-effects-663-667.md` 已完成,可从任务目录移除
|
||||
|
||||
### 8.5 本轮验证
|
||||
- `cd /workspace/logic && go test ./service/fight/effect`
|
||||
- `cd /workspace/logic && go build ./...`
|
||||
|
||||
---
|
||||
|
||||
## 9. 2026-03-29 增量记录(二)
|
||||
|
||||
### 16.1 本轮补齐的 effect
|
||||
- `668` 若对手处于能力提升状态则先制额外+1
|
||||
- `669` 当回合击败对手则下回合自身攻击先制+1
|
||||
- `670` `{0}`回合,每回合附加`{1}`的`{2}`值的`{3}%`的百分比伤害
|
||||
- `671` 若对手处于异常状态则恢复造成伤害的`{0}%`的体力
|
||||
- `672` 当回合击败对手则恢复自身全部体力
|
||||
|
||||
### 16.2 实现口径
|
||||
- `668` 复用 `539` 的条件先制模式,在 `ComparePre()` 中于对手存在能力提升状态时直接给当前技能先制+1。
|
||||
- `669` 按“当回合击败后,为下回合攻击技能生效”处理:在 `SwitchOut()` 中标记击败成立,下一回合 `ComparePre()` 仅对攻击技能追加先制+1。
|
||||
- `670` 参照 `419` 与 `593` 的组合语义,实现为回合类附加伤害:效果持续期间每次使用技能时,附加一次基于指定目标属性值的固定伤害。
|
||||
- `671` 复用 `687` 的伤害回血模式,但条件改为“对手处于任意异常状态”。
|
||||
- `672` 按击败即时触发处理:在对手因本次攻击退场时,立刻将自身体力回复至满值。
|
||||
|
||||
### 9.3 本轮新增文件
|
||||
- `logic/service/fight/effect/668_672.go`
|
||||
|
||||
### 9.4 本轮同步更新
|
||||
- `logic/service/fight/effect/effect_info_map.go`
|
||||
- `docs/effect-unimplemented-tasks/task-014-effects-668-672.md` 已完成,可从任务目录移除
|
||||
|
||||
### 9.5 本轮验证
|
||||
- `cd /workspace/logic && go test ./service/fight/effect`
|
||||
- `cd /workspace/logic && go build ./...`
|
||||
|
||||
---
|
||||
|
||||
## 10. 2026-03-29 增量记录(三)
|
||||
|
||||
### 10.1 本轮补齐的 effect
|
||||
- `642` `{0}回合内若对手攻击技能命中则己方在场精灵{1}%做出{2}`
|
||||
- `643` `{0}%概率使对手{1}回合内{2}能力每回合变化{3}`
|
||||
- `644` 当回合未击败对手,则减少对手当前体力`1/{0}`
|
||||
- `645` 体力低于`1/{0}`时威力`{1}`倍
|
||||
- `646` 体力高于对手时,此技能命中后 100% 使对手能力下降
|
||||
|
||||
### 10.2 实现口径
|
||||
- `642` 按 `moves.json` 中 `1000642` 的说明实现反击档位映射:`0-5` 分别对应 `50/100/150/200/250/300` 点固定伤害;挂在 defender 侧 `Skill_Use_ex()`,仅对命中的攻击技能生效。
|
||||
- `643` 按真实技能实参 `55 2 1 -1` 这类布局处理为“命中后按概率给对手挂回合子效果”,子效果在 `TurnEnd()` 对指定能力执行一次 `SetProp`。
|
||||
- `644` 复用 `579` 的“未击败对手”判定时机,落在 `Action_end()`,按对手当前体力结算 `1/n` 的百分比伤害。
|
||||
- `645` 复用 `37` 的低血线威力倍率模式,在 `SkillHit()` 中按当前体力是否低于最大体力 `1/n` 改写技能威力。
|
||||
- `646` 未按任务文档里的占位 `param` 硬编码;改按实际技能配置的 6 段能力变化参数通用处理,仅在自身体力高于对手且本次技能命中后生效。
|
||||
|
||||
### 10.3 本轮新增文件
|
||||
- `logic/service/fight/effect/642_646.go`
|
||||
|
||||
### 10.4 本轮同步更新
|
||||
- `logic/service/fight/effect/effect_info_map.go`
|
||||
- `docs/effect-unimplemented-tasks/task-009-effects-642-646.md` 已完成,可从任务目录移除
|
||||
|
||||
---
|
||||
|
||||
## 11. 2026-03-29 增量记录(四)
|
||||
|
||||
### 11.1 本轮补齐的 effect
|
||||
- `769` 若对手不处于异常状态则造成的攻击伤害额外提升`{0}%`
|
||||
- `770` 若对手处于异常状态,则恢复自身全部体力
|
||||
- `771` `{0}`回合内每次使用攻击技能都有`{1}%`概率使对手进入任意一种异常状态
|
||||
- `772` `{0}`回合内若对手使用攻击技能则有`{1}%`概率随机进入烧伤、冻伤、中毒、麻痹、害怕、睡眠中的一种异常状态
|
||||
- `773` 若自身体力低于对手则与对手互换体力
|
||||
|
||||
### 11.2 实现口径
|
||||
- `769` 复用 `1103` 的条件增伤写法,在 `SkillHit()` 中仅对攻击技能生效,并在对手不存在任意异常状态时追加威力百分比。
|
||||
- `770` 按技能结算后触发处理,落在 `Skill_Use()`,满足“对手处于异常状态”时直接回复自身满体力。
|
||||
- `771` 作为回合类自身增益实现,持续期间在 `OnSkill()` 针对每次攻击技能按概率给对手附加一项随机异常状态。
|
||||
- `772` 参照 `559` 的 defender 侧监听时机,落在 `Skill_Use_ex()`;对手使用攻击技能时按概率附加六选一异常状态。
|
||||
- `773` 复用 `529` 的直接改写当前体力思路,在满足“自身体力低于对手”时交换双方当前体力,并分别按各自最大体力上限截断。
|
||||
|
||||
### 11.3 本轮新增文件
|
||||
- `logic/service/fight/effect/769_773.go`
|
||||
|
||||
### 11.4 本轮同步更新
|
||||
- `logic/service/fight/effect/effect_info_map.go`
|
||||
- `docs/effect-unimplemented-tasks/task-032-effects-769-773.md` 已完成,可从任务目录移除
|
||||
|
||||
---
|
||||
|
||||
## 12. 2026-03-29 增量记录(五)
|
||||
|
||||
### 12.1 本轮补齐的 effect
|
||||
- `1498` 随机附加烧伤、冻伤、失明、失神中的 `{0}` 种异常状态,未触发则自身下 `{1}` 回合造成的伤害提升 `{2}%`
|
||||
- `1499` 体力低于最大体力的 `1/3` 时先制 `+3`
|
||||
- `1500` 1 回合做 `{0}-{1}` 次攻击,自身处于护盾状态下连击上限为 `{2}`
|
||||
- `1501` 命中后为对手种下一颗黑暗之种
|
||||
- `1502` 对手身上存在黑暗之种时先制 `+1`
|
||||
|
||||
### 12.2 实现口径
|
||||
- `1498` 复用 `1111` 的“未触发则挂自身增伤子效果”模式;随机状态池按任务文案落为烧伤、冻伤、失明、失神,若本次一个状态都未成功挂上,则给自身添加持续 `{1}` 回合的增伤子效果。
|
||||
- `1499` 复用现有条件先制写法,在 `ComparePre()` 中按当前体力是否低于最大体力 `1/3` 直接修改当前技能优先级。
|
||||
- `1500` 参照仓库现有多段技能处理口径,不做逐段攻击,而是在 `Damage_Mul()` 中按随机连击次数折算红伤倍率;若自身当前存在护盾,则用 `{2}` 约束连击上限。
|
||||
- `1501` 作为挂在 defender 身上的持久子效果实现:命中后附加“黑暗之种”,前 4 次 `TurnEnd()` 随机扣 1 个技能 PP,成熟后每回合所有技能 PP `-1`;下场后清除。
|
||||
- `1502` 在 `ComparePre()` 中检查对手是否持有 `1501` 的子效果,存在时当前技能先制 `+1`。
|
||||
|
||||
### 12.3 模型假设
|
||||
- 仓库当前未注册“失神”状态,本轮按状态 ID `29` 追加了一个最小可用实现,行为复用 `StatusCannotAct`。
|
||||
- `1500` 仍受当前战斗模型限制,只能按总连击数折算伤害,不能表现逐段命中、逐段触发的细粒度行为。
|
||||
|
||||
### 12.4 本轮新增文件
|
||||
- `logic/service/fight/effect/1498_1502.go`
|
||||
|
||||
### 12.5 本轮同步更新
|
||||
- `logic/service/fight/effect/effect_info_map.go`
|
||||
- `docs/effect-unimplemented-tasks/README.md`
|
||||
- `docs/effect-unimplemented-tasks/task-177-effects-1498-1502.md` 已完成,可从任务目录移除
|
||||
|
||||
### 12.6 本轮验证
|
||||
- `cd /workspace/logic && go test ./service/fight/effect`
|
||||
- `cd /workspace/logic && go build ./...`
|
||||
|
||||
---
|
||||
|
||||
## 13. 2026-03-29 增量记录(六)
|
||||
|
||||
### 13.1 本轮补齐的 effect
|
||||
- `1503` 清除对手身上的黑暗之种,清除成功则令对手随机受到 `1-500` 点固定伤害
|
||||
- `1504` `40%` 令对手诅咒,若对手身上存在黑暗之种则概率翻倍
|
||||
- `1505` 黑暗之种成长期时附加 `200` 点固定伤害,黑暗之种长大后固定伤害翻倍
|
||||
- `1506` 若对手不是龙系精灵则恢复自身 `{0}` 点体力
|
||||
- `1507` `{0}` 回合内自身受到攻击则令对手随机进入 `{1}` 种异常状态,未触发则消除对手回合类效果
|
||||
|
||||
### 13.2 实现口径
|
||||
- `1503` 复用本轮新增的黑暗之种清理 helper,在 `Skill_Use()` 中清除对手持有的 `1501` 子效果;仅当成功清除时追加一次 `1-500` 的随机固定伤害。
|
||||
- `1504` 按任务文案直接实现为基础 `40%` 概率,若对手当前仍持有黑暗之种则翻倍到 `80%`;仓库尚无诅咒状态注册,本轮补了一个最小可用的状态壳以承接后续联动。
|
||||
- `1505` 读取 `1501` 子效果当前成长阶段:成长期附加 `200` 固定伤害,成熟后附加 `400` 固定伤害;若对手不存在黑暗之种则不触发。
|
||||
- `1506` 使用宠物当前系别组合判断是否包含龙系;仅在对手主属性、副属性均不为龙系时恢复自身体力。
|
||||
- `1507` 复用 `1228` 的 defender 侧监听模式,落在 `Skill_Use_ex()`:对手使用攻击技能命中本体时,随机附加若干异常状态;若整段持续时间内一次都未成功触发,则在最后一回合结束时清除对手回合类效果。
|
||||
|
||||
### 13.3 模型假设
|
||||
- 仓库当前缺少“诅咒”状态实现,本轮按状态 ID `23` 注册了一个最小 `BaseStatus` 版本,只提供状态存在性与常规下场清理,不额外附带持续结算逻辑。
|
||||
- `1505` 的“黑暗之种成长期/长大后”判断直接复用 `1501` 子效果内部阶段计数:前 4 次回合结束视为成长期,第 5 次起视为成熟。
|
||||
|
||||
### 13.4 本轮新增文件
|
||||
- `logic/service/fight/effect/1503_1507.go`
|
||||
|
||||
### 13.5 本轮同步更新
|
||||
- `logic/service/fight/effect/effect_info_map.go`
|
||||
- `docs/effect-unimplemented-tasks/README.md`
|
||||
- `docs/effect-unimplemented-tasks/task-178-effects-1503-1507.md` 已完成,可从任务目录移除
|
||||
|
||||
### 13.6 本轮验证
|
||||
- `cd /workspace/logic && go test ./service/fight/effect`
|
||||
- `cd /workspace/logic && go build ./...`
|
||||
|
||||
---
|
||||
|
||||
## 14. 2026-03-30 增量记录(一)
|
||||
|
||||
### 14.1 本轮补齐的 effect
|
||||
- `1508` 先出手时无视攻击免疫效果
|
||||
- `1509` 令对手全属性-`{0}` 且随机 `{1}` 个技能 PP 值归零,技能无效时消耗自身全部体力并令对手全属性-1,然后对手下 3 次使用技能消耗的 PP 值为 3 倍
|
||||
- `1510` `{0}` 回合内对手主动切换精灵则登场精灵 `{1}%` 随机进入 `{2}` 种异常状态
|
||||
- `1511` 先出手时免疫当回合受到的攻击伤害,若对手为自身天敌则免疫并反弹给对手造成伤害值 `{0}%` 的百分比伤害
|
||||
- `1512` 集结天幕四龙之神力,使自身下 2 回合先制+3且攻击必定命中、必定致命
|
||||
|
||||
### 14.2 实现口径
|
||||
- `1508` 采用仓库现有模型下的局部支持方案:若自身本次先出手且使用攻击技能,则在伤害结算前临时屏蔽若干常见“攻击伤害清零类” immunity effect,并在技能结算结束后恢复。
|
||||
- `1509` 正常命中时直接令对手全属性下降并随机清空若干技能 PP;若本次技能实体存在但 `AttackTime == 0`,则按“技能无效”分支处理:自损全部体力、令对手全属性-1,并给对手挂 3 次 PP 三倍消耗子效果。
|
||||
- `1510` 复用 `1562` 的“主动切换后对登场精灵生效”模式:效果挂在对手侧,仅在对手主动切换下场时置 pending,登场后按概率随机附加若干异常状态。
|
||||
- `1511` 复用 `170/1011` 的免疫伤害写法,落在 `DamageLockEx()`;若自身先出手则直接免疫本回合受到的红伤,若对手同时为自身天敌,则按原伤害值 `{0}%` 追加一次百分比伤害反弹。
|
||||
- `1512` 作为持续 2 回合的自身子效果实现,在 `ComparePre()` 中固定追加先制 `+3`,并在 `ActionStart()` 中对攻击技能同时赋予必中与必定致命。
|
||||
|
||||
### 14.3 模型假设
|
||||
- `1508` 当前没有通用“无视攻击免疫”标记位,本轮仅覆盖仓库内已识别的常见攻击免疫 effect:`170/525/570/850/1011/1511`。对其他未来新增或语义不同的 defender 侧免疫实现,不保证自动生效。
|
||||
- `1509` 的“技能无效时”按仓库现有口径解释为“技能实体存在,但本次结算后 `AttackTime == 0`”,不把被控未出手、无 PP 无法释放这类情况算作技能无效。
|
||||
|
||||
### 14.4 本轮新增文件
|
||||
- `logic/service/fight/effect/1508_1512.go`
|
||||
|
||||
### 14.5 本轮同步更新
|
||||
- `logic/service/fight/effect/effect_info_map.go`
|
||||
- `docs/effect-unimplemented-tasks/README.md`
|
||||
- `docs/effect-unimplemented-tasks/task-179-effects-1508-1512.md` 已完成,可从任务目录移除
|
||||
|
||||
### 14.6 本轮验证
|
||||
- `cd /workspace/logic && go test ./service/fight/effect`
|
||||
- `cd /workspace/logic && go build ./...`
|
||||
|
||||
---
|
||||
|
||||
## 15. 2026-03-31 增量记录(二)
|
||||
|
||||
### 15.1 本轮新增实现
|
||||
- `780` `{0}` 回合内受到攻击则 `{1}%` 令对手随机 `{2}` 个技能 PP 值归零
|
||||
- `781` 消除对手回合类效果,消除成功则 `{0}` 回合内令对手使用的属性技能无效
|
||||
- `782` `{0}%` 令对手 `{1}`,每次使用概率增加 `{2}%`,最高概率 `{3}%`
|
||||
- `783` `{0}` 回合内自身能力提升状态被消除或吸取时附加对手最大体力 `1/{1}` 的百分比伤害
|
||||
- `784` 若本回合击败对手则将对手的能力提升效果转移到自己身上
|
||||
- `790` `{0}` 回合内自身所有攻击无视伤害限制效果
|
||||
- `791` `{0}` 回合内每回合使用技能恢复自身最大体力的 `1/{1}`,当前体力低于对手时恢复翻倍
|
||||
- `792` 先出手时对手当回合攻击技能无效
|
||||
- `793` 若造成的伤害低于 `{0}`,则下 `{1}` 回合每回合造成 `{2}` 点固定伤害
|
||||
- `794` 消除对手能力提升,消除成功则抵挡 `{0}` 回合内对手的攻击伤害
|
||||
|
||||
### 15.2 本轮复核后确认已存在
|
||||
- `637-641` 已在 `637_641.go` 落地,相关任务文档可删除
|
||||
- `764-768` 已在 `764_768.go` 落地,相关任务文档可删除
|
||||
- `774-779` 已在 `774_779.go` 落地,相关任务文档可删除
|
||||
- `785-789` 已在 `785_789.go` 落地,相关任务文档可删除
|
||||
|
||||
### 15.3 本轮同步更新
|
||||
- 新增 `logic/service/fight/effect/780_784.go`
|
||||
- 新增 `logic/service/fight/effect/790_794.go`
|
||||
- 删除 `docs/effect-unimplemented-tasks/task-008-effects-637-641.md`
|
||||
- 删除 `docs/effect-unimplemented-tasks/task-031-effects-764-768.md`
|
||||
- 删除 `docs/effect-unimplemented-tasks/task-033-effects-774-779.md`
|
||||
- 删除 `docs/effect-unimplemented-tasks/task-034-effects-780-784.md`
|
||||
- 删除 `docs/effect-unimplemented-tasks/task-035-effects-785-789.md`
|
||||
- 删除 `docs/effect-unimplemented-tasks/task-036-effects-790-794.md`
|
||||
|
||||
### 15.4 本轮验证
|
||||
- `cd /workspace/logic && go test ./service/fight/effect`
|
||||
- `cd /workspace/logic && go build ./...`
|
||||
|
||||
## 16. 2026-03-31 增量记录
|
||||
|
||||
### 16.1 本轮补齐的 effect
|
||||
- `1067` `{0}回合内每回合使用技能恢复自身最大体力的1/{1},恢复体力时若自身体力低于最大体力的1/{2}则恢复效果转变为吸取对手最大体力的1/{3}`
|
||||
- `1068` 下`{0}`回合受到致命伤害时残留`{1}`点体力
|
||||
- `1069` 反转自身能力下降状态,反转成功则`{0}`回合内躲避所有攻击
|
||||
- `1070` 对手处于能力下降状态时自身先制+1
|
||||
- `1071` `{0}`回合内若对手恢复体力(药剂恢复除外),则`{1}`回合内自身攻击附加`{2}`点固定伤害
|
||||
|
||||
### 16.2 实现口径
|
||||
- `1067` 复用 `707` 的“每回合使用技能后回复”模式,在低血线时改为按对手最大体力比例吸取并同步治疗自身。
|
||||
- `1068` 通过回合子效果在致命伤害结算前锁定剩余体力值,满足“下{0}回合保留{1}点体力”。
|
||||
- `1069` 先反转自身全部能力下降,再在成功时挂载受击 MISS 子效果,仅拦截攻击技能。
|
||||
- `1070` 复用现有 `1243` 同类优先级判断,对手存在任一能力下降时自身先制+1。
|
||||
- `1071` 在对手身上挂恢复监听子效果,排除药剂恢复;触发后给自身挂固定伤害增益子效果。
|
||||
|
||||
### 16.3 本轮同步项
|
||||
- 已补 `logic/service/fight/effect/effect_info_map.go` 中 `1067-1071` 的说明映射。
|
||||
- `docs/effect-unimplemented-tasks/task-091-effects-1067-1071.md` 已删除。
|
||||
|
||||
## 17. 2026-03-31 增量记录
|
||||
|
||||
### 17.1 本轮补齐的 effect
|
||||
- `1072` 附加自身当前体力`{0}`%的百分比伤害,连续使用每次增加`{1}`%,最高`{2}`%
|
||||
- `1073` `{0}`回合内受到的伤害大于`{1}`则主动恢复自身全部体力并造成等同于恢复量的固定伤害
|
||||
- `1074` 造成的伤害大于`{0}`则对手`{1}`%`{2}`,未触发则自身下`{3}`回合攻击有`{4}`%的概率使对手`{5}`
|
||||
- `1075` 恢复自身最大体力的1/`{0}`,自身体力低于1/`{1}`时回满
|
||||
- `1076` 对手不处于能力提升状态时先制+2
|
||||
|
||||
### 17.2 实现口径
|
||||
- `1072` 参考 `1280`,按当前体力百分比追加伤害并在连续使用时累计加成,封顶于实参上限。
|
||||
- `1073` 参考 `775`,在受击伤害超过阈值时于行动结束节点回满自身,并按实际恢复量反打固定伤害。
|
||||
- `1074` 参考 `1256/1271`,先按本次造成伤害判定即时概率状态;未触发时再给自身挂后续攻击概率附加状态的回合子效果。
|
||||
- `1075` 参考 `704/900`,常态回复最大体力的分数值,低血线时改为直接补满缺失体力。
|
||||
- `1076` 参考 `779` 的反向条件,对手不存在能力提升状态时令自身先制+2。
|
||||
|
||||
### 17.3 本轮同步项
|
||||
- 已补 `logic/service/fight/effect/effect_info_map.go` 中 `1072-1076` 的说明映射。
|
||||
- `docs/effect-unimplemented-tasks/task-092-effects-1072-1076.md` 已删除。
|
||||
|
||||
## 18. 2026-03-31 增量记录
|
||||
|
||||
### 18.1 本轮补齐的 effect
|
||||
- `1077` `{0}`回合内对手使用攻击技能后使对手`{1}`,未触发则对手下`{2}`回合属性技能命中效果失效
|
||||
- `1078` 使对手随机进入`{0}`种异常状态,未触发则下`{1}`回合自身属性技能先制+`{2}`
|
||||
- `1079` 命中后`{0}`%令对手`{1}`,未触发则下`{2}`回合自身攻击技能先制+`{3}`
|
||||
- `1080` 连续使用时先制+1
|
||||
- `1081` 若对手处于能力提升状态则先制+1
|
||||
|
||||
### 18.2 实现口径
|
||||
- `1077` 参考 `1267/998`,在己方身上挂对手攻击技能监听,若整段持续期未触发则给对手补一段属性技能失效子效果。
|
||||
- `1078` 先尝试随机附加异常,若没有新增异常状态成功落到对手身上,再给自身挂属性技能先制子效果。
|
||||
- `1079` 参考概率异常+后续先制类效果,命中后先判即时异常,未触发则给自身挂攻击技能先制子效果。
|
||||
- `1080` 复用 `AddLvelEffect` 的连续使用计数,在连续使用同一技能时给当前技能先制+1。
|
||||
- `1081` 直接复用 `779` 的同类判断,只是条件改为“对手处于能力提升状态”且先制值为+1。
|
||||
|
||||
### 18.3 本轮同步项
|
||||
- 已补 `logic/service/fight/effect/effect_info_map.go` 中 `1077-1081` 的说明映射。
|
||||
- `docs/effect-unimplemented-tasks/task-093-effects-1077-1081.md` 已删除。
|
||||
|
||||
## 18. 2026-03-31 增量记录
|
||||
|
||||
### 18.1 本轮补齐的 effect
|
||||
- `1077` `{0}`回合内对手使用攻击技能后使对手`{1}`,未触发则对手下`{2}`回合属性技能命中效果失效
|
||||
- `1078` 使对手随机进入`{0}`种异常状态,未触发则下`{1}`回合自身属性技能先制+`{2}`
|
||||
- `1079` 命中后`{0}`%令对手`{1}`,未触发则下`{2}`回合自身攻击技能先制+`{3}`
|
||||
- `1080` 连续使用时先制+1
|
||||
- `1081` 若对手处于能力提升状态则先制+1
|
||||
|
||||
### 18.2 实现口径
|
||||
- `1077` 参考 `1267/1490/738`,在己方身上挂对手攻击技能监听;状态未成功挂上时,再给对手挂属性技能命中效果失效子效果。
|
||||
- `1078` 参考 `786/1100`,先尝试随机异常状态;未触发时给自身挂仅对属性技能生效的先制子效果。
|
||||
- `1079` 参考 `756/1230`,命中后按概率给对手附加状态;未触发时给自身挂仅对攻击技能生效的回合先制子效果。
|
||||
- `1080` 记录上次使用技能 ID,在连续使用同一技能时给予先制+1。
|
||||
- `1081` 复用 `779` 的同类条件判断,对手存在能力提升状态时自身先制+1。
|
||||
|
||||
### 18.3 本轮同步项
|
||||
- 已补 `logic/service/fight/effect/effect_info_map.go` 中 `1077-1081` 的说明映射。
|
||||
- `docs/effect-unimplemented-tasks/task-093-effects-1077-1081.md` 已删除。
|
||||
|
||||
|
||||
## 19. 2026-04-03 同类实现合并记录
|
||||
|
||||
### 19.1 本轮抽取的公共 base
|
||||
- `RandomDurationArg01Base`:封装 `args[0]/args[1]` 随机持续回合。
|
||||
- `FixedDurationNeg1Arg0CountBase`:封装 `Duration(-1)` 且从 `args[0]` 初始化次数上限。
|
||||
|
||||
### 19.2 本轮合并到公共实现的 effect
|
||||
- `41/42`:改为复用随机持续回合 base。
|
||||
- `47/48`:改为复用 `arg0` 持续回合 base。
|
||||
- `60`:改为复用 `SideEffectArgs[0]` 持续回合 base。
|
||||
- `46/570`:改为复用“永久持续 + arg0 次数耗尽” base。
|
||||
|
||||
### 19.3 本轮未动的同类候选
|
||||
- `SelfKill`:文件 `logic/service/fight/effect/selfkill.go` 已存在本地改动,本轮为避免覆盖,未继续并入 `FixedDurationNeg1Base`。
|
||||
- `Effect123`、`EffectPropSyncReverse`:仍包含额外上下文初始化,不适合只靠 SetArgs 模板直接下沉。
|
||||
|
||||
### 19.4 本轮验证
|
||||
- 已执行 `cd /workspace/logic && go test ./service/fight/effect`
|
||||
- 已执行 `cd /workspace/logic && go build ./...`
|
||||
@@ -1,218 +0,0 @@
|
||||
---
|
||||
name: fight-effect-impl
|
||||
description: Implement or repair Go fight effects in the Blazing battle system. Use when working in logic/service/fight/effect or nearby boss hooks, especially for missing effect tasks, effect registration, hook selection, delayed/round effects, status application, effect_info_map updates, and package-level validation.
|
||||
---
|
||||
|
||||
# Fight Effect Impl
|
||||
|
||||
Implement effect work in the existing battle framework instead of inventing a parallel pattern.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. Read the task source first.
|
||||
If the request comes from `docs/effect-unimplemented-tasks/`, open the task file and extract effect IDs, arg counts, and description text.
|
||||
|
||||
2. Confirm whether each effect is actually missing.
|
||||
Search for both type names and registrations. Do not rely only on direct `InitEffect(...)` grep results.
|
||||
Also inspect shared registration files such as:
|
||||
- `logic/service/fight/effect/sterStatusEffects.go`
|
||||
- `logic/service/fight/effect/effect_power_doblue.go`
|
||||
- `logic/service/fight/effect/EffectAttackMiss.go`
|
||||
- `logic/service/fight/effect/EffectPhysicalAttackAddStatus.go`
|
||||
- `logic/service/fight/effect/EffectDefeatTrigger.go`
|
||||
- `logic/service/fight/effect/effect_attr.go`
|
||||
|
||||
3. Reuse the nearest local pattern.
|
||||
Open effects with similar timing or semantics before writing code. Prefer matching existing hooks, helper bases, registration style, and comments over building a generic abstraction.
|
||||
|
||||
4. Choose the hook from battle flow, not from description text alone.
|
||||
Read `logic/service/fight/input/interface.go`, `logic/service/fight/fightc.go`, and `logic/service/fight/loop.go` when timing is unclear.
|
||||
|
||||
## Effect Hooks
|
||||
|
||||
Use this section when effect timing is unclear.
|
||||
|
||||
### Core call order
|
||||
|
||||
The main references are:
|
||||
- `logic/service/fight/input/interface.go`
|
||||
- `logic/service/fight/fightc.go`
|
||||
- `logic/service/fight/loop.go`
|
||||
|
||||
Typical attack flow inside `processSkillAttack` and `enterturn` is:
|
||||
1. defender `SkillHit_ex()`
|
||||
2. attacker `SkillHit()`
|
||||
3. attacker `CalculatePre()`
|
||||
4. attacker `OnSkill()`
|
||||
5. defender `Damage(...)` settles red/fixed/true damage
|
||||
6. defender `Skill_Use_ex()`
|
||||
7. attacker `Skill_Use()`
|
||||
8. defender `Action_end_ex()`
|
||||
9. attacker `Action_end()`
|
||||
10. both sides `TurnEnd()` at round end
|
||||
11. all live effects `OnBattleEnd()` at fight end
|
||||
|
||||
### Hook selection cheatsheet
|
||||
|
||||
- `SkillHit_ex()`
|
||||
Use for defender-side pre-hit interception, miss forcing, and hit-rate disruption.
|
||||
|
||||
- `SkillHit()`
|
||||
Use for attacker-side power, crit, or skill-property changes before damage is computed.
|
||||
|
||||
- `CalculatePre()`
|
||||
Use for temporary state rewrites that must exist during power calculation and then be restored.
|
||||
|
||||
- `OnSkill()`
|
||||
Use for on-hit side effects, extra fixed damage setup, healing, status attach, or delayed-effect spawning.
|
||||
|
||||
- `ActionStartEx()`
|
||||
Use for defender-side pre-action gates.
|
||||
|
||||
- `ActionStart()`
|
||||
Use for attacker-side action gating, forced no-action behavior, and same-turn priority-sensitive logic.
|
||||
|
||||
- `Skill_Use_ex()`
|
||||
Use for defender-side after-being-targeted behavior.
|
||||
|
||||
- `Skill_Use()`
|
||||
Use for attacker-side after-using-skill behavior.
|
||||
|
||||
- `ComparePre()`
|
||||
Use for priority changes before turn order is finalized.
|
||||
|
||||
- `TurnStart()`
|
||||
Use for per-round setup or replacing the current round's selected action before execution.
|
||||
|
||||
- `TurnEnd()`
|
||||
Use for countdown or expiry. The default node decrements positive durations and clears zero-duration effects.
|
||||
|
||||
- `OnBattleEnd()`
|
||||
Use only when the effect truly settles at battle end. Confirm any reward path can be persisted from this hook.
|
||||
|
||||
### Repo-specific cautions
|
||||
|
||||
- `EffectCache` matters.
|
||||
Parsed skill effects are stored in `EffectCache` before execution. If a first-turn charge effect must suppress the rest of the skill's side effects, explicitly disable sibling cached effects for that turn.
|
||||
|
||||
- `addSubEffect(...)` is lightweight.
|
||||
Read `logic/service/fight/effect/sub_effect_helper.go` before assuming helper behavior. The current helper forwards IDs and args, but does not automatically apply the `duration` argument to the sub-effect instance.
|
||||
|
||||
- Team-wide healing is limited by current model.
|
||||
There is no generic battle-target abstraction for friendly bench targets. If the effect heals all owned pets, iterate `AllPet` and mutate non-active pets carefully.
|
||||
|
||||
- Static task scans can be false positives.
|
||||
Task documents may flag effects as missing even when they already exist in grouped files or shared registration files. Verify before editing.
|
||||
|
||||
## Implementation Rules
|
||||
|
||||
- Prefer existing base structs in `logic/service/fight/effect/sub_effect_helper.go` when they already match duration behavior.
|
||||
- Verify helper semantics before using them. In this repo, some helpers are thinner than their names suggest.
|
||||
- For status effects, create them through `InitEffect(input.EffectType.Status, ...)` and add them through `AddEffect(...)` on the target input.
|
||||
- For healing, use `Input.Heal(...)` for the active battler and mutate non-active owned pets only when the current model already stores them in `AllPet`.
|
||||
- For battle-end rewards or delayed settlement, confirm the hook is actually executed in `loop.go` before coding against it.
|
||||
- Keep comments short and effect-focused.
|
||||
|
||||
## Batch Work Rules
|
||||
|
||||
When continuing `docs/effect-unimplemented-tasks/` in batches:
|
||||
|
||||
- Split work by grouped file and assign disjoint write ranges.
|
||||
- Avoid touching `logic/service/fight/effect/effect_info_map.go` during parallel effect implementation unless the user explicitly asks for description-map updates in the same pass.
|
||||
- Treat task docs as a backlog, not ground truth. A task file may still exist even when some IDs in the slice were already implemented or partially repaired.
|
||||
- Prefer finishing the easiest grounded IDs in a partial slice instead of repeatedly rescanning the entire slice.
|
||||
- Keep a clear list of:
|
||||
- newly implemented IDs,
|
||||
- already-existing IDs,
|
||||
- still-partial IDs,
|
||||
- task docs safe to delete.
|
||||
|
||||
## Frequent Compile Pitfalls
|
||||
|
||||
Before considering a slice done, check these repo-specific issues:
|
||||
|
||||
- `input.InitEffect(...)` always needs all three args: effect type, numeric ID, effect instance.
|
||||
- If a new sub-effect type is added, also register the sub-effect explicitly in `init()`.
|
||||
- `SkillEntity.XML.Power` and `Priority` are `int`-based in current generated structs; avoid mixing with `int8`, `int32`, or `int64` arithmetic.
|
||||
- Skill PP on runtime battle state is commonly `uint32`; cast carefully when subtracting or restoring PP.
|
||||
- `model.SkillInfo` does not expose fields like `MaxPP` or `Category`; look them up through `xmlres.SkillMap[int(skill.ID)]`.
|
||||
- `xmlres.Move` does not expose every runtime field. Use runtime state such as `SkillEntity.AttackTime` when the XML struct lacks a field.
|
||||
- `input.Input` does not always expose nested objects assumed by task text, such as `Opp.SkillEntity`; verify available runtime fields before coding.
|
||||
- Decimal math must use `alpacadecimal` values, not raw integer literals.
|
||||
- Large grouped files can accidentally keep stale duplicate `init()` registration blocks after manual merges or batch patches. Check the file tail before closing out a slice.
|
||||
|
||||
## Partial Slice Strategy
|
||||
|
||||
When a grouped file is only partially grounded:
|
||||
|
||||
- Do not delete the task docs for that slice yet.
|
||||
- Keep the implemented IDs in place and make the remaining gaps explicit.
|
||||
- Prefer conservative, repo-shaped implementations over speculative full feature work for heavy system effects.
|
||||
- Good candidates to finish in partial slices are:
|
||||
- simple priority modifiers,
|
||||
- PP-based power changes,
|
||||
- round-based sub-effects using existing helper bases,
|
||||
- status immunity or status application patterns that already exist nearby.
|
||||
- Leave highly coupled systems partial if they appear to depend on larger mechanics not yet modeled in nearby code, such as custom resource tracks or complex transformation states.
|
||||
|
||||
## Task Doc Deletion
|
||||
|
||||
Delete a task file only when one of these is true:
|
||||
|
||||
- every effect ID in the task range is now implemented in repo code,
|
||||
- the IDs already existed and were verified as not missing,
|
||||
- or the user explicitly accepts documented non-implementation for reserved placeholders.
|
||||
|
||||
Do not delete the task doc when the slice is still mixed between implemented and partial IDs.
|
||||
|
||||
## Common Tasks
|
||||
|
||||
### Random power or conditional power effects
|
||||
Use `SkillHit()` when the effect changes `SkillEntity.XML.Power` before damage is calculated.
|
||||
Examples in repo: `139.go`, `effect_power_doblue.go`, `600_605.go`.
|
||||
|
||||
### Hit-time status or side effects
|
||||
Use `OnSkill()` when the effect should fire after hit/damage calculation setup and before final damage application is settled.
|
||||
For direct status application, initialize the status effect from the source input and add it to the opponent.
|
||||
|
||||
### Round or delayed effects
|
||||
For multi-turn logic, confirm whether the effect should:
|
||||
- modify this turn only,
|
||||
- start next turn,
|
||||
- trigger when attacked,
|
||||
- or replace the next selected skill.
|
||||
|
||||
For next-turn logic, inspect nearby effects such as `62`, `407`, `440`, `499`, `551`, `560`, and any adjacent ID patterns.
|
||||
|
||||
### Two-turn charge effects
|
||||
Preserve the repo's existing battle loop assumptions.
|
||||
A practical pattern is:
|
||||
- cache the release skill on the first turn,
|
||||
- suppress first-turn damage/effect output,
|
||||
- inject the cached skill into the next turn's selected action in `TurnStart`,
|
||||
- avoid double PP consumption in `HookPP`.
|
||||
|
||||
### Reward-on-battle-end effects
|
||||
Check `OnBattleEnd()` execution in `logic/service/fight/loop.go`.
|
||||
If a reward has a daily cap, prefer the shared counter utilities under `common/data/share/` over inventing new state.
|
||||
|
||||
## Validation
|
||||
|
||||
Run, at minimum:
|
||||
- `cd /workspace/logic && go test ./service/fight/effect`
|
||||
- `cd /workspace/logic && go build ./...`
|
||||
|
||||
If the user explicitly says tests are not required for the current pass, downgrade validation to:
|
||||
- `gofmt -w` on every edited Go file,
|
||||
- fix current editor/compiler diagnostics for touched files,
|
||||
- and report that package tests/build were intentionally skipped by user request.
|
||||
|
||||
If the task came from `docs/effect-unimplemented-tasks/`, remove the completed task file when the user asked for it.
|
||||
|
||||
## Output
|
||||
|
||||
When finishing a task, report:
|
||||
- which effect IDs were truly implemented,
|
||||
- which IDs already existed and were left untouched,
|
||||
- validation commands actually run,
|
||||
- any remaining model limitations or behavior assumptions.
|
||||
@@ -109,21 +109,12 @@ func (e *Effect121) Skill_Use() bool {
|
||||
|
||||
// Effect 123: {0}回合内受到任何伤害,自身{1}提高{2}个等级
|
||||
type Effect123 struct {
|
||||
node.EffectNode
|
||||
roundCount int
|
||||
can bool
|
||||
}
|
||||
|
||||
func (e *Effect123) SetArgs(t *input.Input, a ...int) {
|
||||
e.EffectNode.SetArgs(t, a...)
|
||||
e.roundCount = e.EffectNode.SideEffectArgs[0]
|
||||
RoundEffectSideArg0Base
|
||||
can bool
|
||||
}
|
||||
|
||||
func (e *Effect123) TurnStart(at, de *action.SelectSkillAction) {
|
||||
if e.roundCount > 0 {
|
||||
e.can = true
|
||||
e.roundCount--
|
||||
}
|
||||
e.can = true
|
||||
}
|
||||
|
||||
func (e *Effect123) Be_Damage(at, _ alpacadecimal.Decimal) {
|
||||
|
||||
@@ -30,8 +30,13 @@ type propOpContext struct {
|
||||
opType propOpType
|
||||
}
|
||||
|
||||
type propOpConfig struct {
|
||||
newContext func() propOpContext
|
||||
initDuration bool
|
||||
}
|
||||
|
||||
// 全局映射:关联效果ID与对应的操作配置
|
||||
var propOpMap = make(map[int]func() propOpContext)
|
||||
var propOpMap = make(map[int]propOpConfig)
|
||||
|
||||
// EffectPropSyncReverse:属性同步/反转效果核心结构体
|
||||
type EffectPropSyncReverse struct {
|
||||
@@ -57,27 +62,41 @@ func init() {
|
||||
// 批量注册:绑定效果ID与对应的操作配置
|
||||
func registerPropSyncReverseEffects() {
|
||||
// 效果ID与操作配置的映射
|
||||
effectMap := map[int]func() propOpContext{
|
||||
38: func() propOpContext { // 减少最大生命值
|
||||
return propOpContext{opType: opTypeMaxHP}
|
||||
effectMap := map[int]propOpConfig{
|
||||
38: {
|
||||
newContext: func() propOpContext { // 减少最大生命值
|
||||
return propOpContext{opType: opTypeMaxHP}
|
||||
},
|
||||
},
|
||||
45: func() propOpContext { // n回合防御力和对手相同
|
||||
return propOpContext{opType: opDefenseSync, propIndex: 1}
|
||||
45: {
|
||||
newContext: func() propOpContext { // n回合防御力和对手相同
|
||||
return propOpContext{opType: opDefenseSync, propIndex: 1}
|
||||
},
|
||||
initDuration: true,
|
||||
},
|
||||
51: func() propOpContext { // n回合攻击力和对手相同
|
||||
return propOpContext{opType: opAttackSync, propIndex: 0}
|
||||
51: {
|
||||
newContext: func() propOpContext { // n回合攻击力和对手相同
|
||||
return propOpContext{opType: opAttackSync, propIndex: 0}
|
||||
},
|
||||
initDuration: true,
|
||||
},
|
||||
55: func() propOpContext { // n回合反转属性类型
|
||||
return propOpContext{opType: opTypeReverse}
|
||||
55: {
|
||||
newContext: func() propOpContext { // n回合反转属性类型
|
||||
return propOpContext{opType: opTypeReverse}
|
||||
},
|
||||
initDuration: true,
|
||||
},
|
||||
56: func() propOpContext { // n回合同步属性类型
|
||||
return propOpContext{opType: opTypeSync}
|
||||
56: {
|
||||
newContext: func() propOpContext { // n回合同步属性类型
|
||||
return propOpContext{opType: opTypeSync}
|
||||
},
|
||||
initDuration: true,
|
||||
},
|
||||
}
|
||||
|
||||
// 注册到全局映射,并初始化效果
|
||||
for effectID, ctxFunc := range effectMap {
|
||||
propOpMap[effectID] = ctxFunc
|
||||
for effectID, config := range effectMap {
|
||||
propOpMap[effectID] = config
|
||||
input.InitEffect(input.EffectType.Skill, effectID, newEffectPropSyncReverse())
|
||||
}
|
||||
}
|
||||
@@ -85,10 +104,15 @@ func registerPropSyncReverseEffects() {
|
||||
// SetArgs:设置效果参数(回合数)
|
||||
func (e *EffectPropSyncReverse) SetArgs(t *input.Input, a ...int) {
|
||||
e.EffectNode.SetArgs(t, a...)
|
||||
// 从SideEffectArgs[0]获取持续回合数
|
||||
e.EffectNode.Duration(e.EffectNode.SideEffectArgs[0])
|
||||
config, ok := propOpMap[int(e.ID().Suffix())]
|
||||
if !ok {
|
||||
return
|
||||
}
|
||||
if config.initDuration && len(e.EffectNode.SideEffectArgs) > 0 {
|
||||
e.EffectNode.Duration(e.EffectNode.SideEffectArgs[0])
|
||||
}
|
||||
// 初始化操作上下文
|
||||
e.ctx = propOpMap[int(e.ID().Suffix())]()
|
||||
e.ctx = config.newContext()
|
||||
}
|
||||
func (e *EffectPropSyncReverse) OnSkill() bool {
|
||||
|
||||
|
||||
Reference in New Issue
Block a user