Refactor timers to display simultaneously and improve reset logic

[zqzhang1996]

把两个计时器改为可以同时显示
补充部分重置条件的测试
重写计时器重置逻辑

其实做好了有一段时间，但一直没怎么上游戏测试
最近高强度出击用下来没出过问题，所以发一下pr
样式看着有些奇怪，不确定是我的开发环境配置问题还是样式本身问题，主要我对web也不太熟悉，所以没有尝试调整

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[KagamiChan]

多谢，我自己其实之前做了一些改造，不过因为我已经不在玩了，所以没办法自己测
如果方便的话请附带上一些截图，我具体看看需不需要微调一下

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

[zqzhang1996]

主要是整备序列那一页的样式看起来完全混乱了，不过这一页的功能我一般使用入渠概览那个插件来看，所以影响不大
舰队详情部分则是间距可能有一点问题

[zqzhang1996]

其实现在有一个想法是把这两个计时器放到主界面上，类似入渠倒计时
由于计时器的重置规则特点，是可以在出击的间隙通过编成展开获得野崎或者明石效果的，这种用法里对于具体恢复量不太关心，重点是要能方便看到计时器具体走了多少，每次都要切插件页还是比较麻烦
不过我不知道要怎么做_(:з」∠)_

[KagamiChan]

其实现在有一个想法是把这两个计时器放到主界面上，类似入渠倒计时 由于计时器的重置规则特点，是可以在出击的间隙通过编成展开获得野崎或者明石效果的，这种用法里对于具体恢复量不太关心，重点是要能方便看到计时器具体走了多少，每次都要切插件页还是比较麻烦 不过我不知道要怎么做_(:з」∠)_

介入主界面机制上需要改动的东西比较多，不单是插件自己，本体也是有要修改的。可以以后考虑

我们可以先调整一下这边能发一个新版，不过这就可能得等我有时间再调整了……

[zqzhang1996]

计时器相关的逻辑应该没有需要调整的，你看情况修一修样式应该就可以先发一版
后续我大概会做一点测试看看明石修理时间和朝日加速效果，我看也有issue提到相关的问题，有进展的话会另外发pr

[KagamiChan]

我又用代理抓了一遍原始页面，不再只看搜索摘要。抓到的 WIKIWIKI 原文比第三方摘要更关键，所以这里把判断修正一下。

参考资料

• 明石 WIKIWIKI：https://wikiwiki.jp/kancolle/%E6%98%8E%E7%9F%B3
• 野埼 WIKIWIKI：https://wikiwiki.jp/kancolle/%E9%87%8E%E5%9F%BC
• 疲労度 WIKIWIKI：https://wikiwiki.jp/kancolle/%E7%96%B2%E5%8A%B4%E5%BA%A6
• 明石计时器验证资料：https://gist.githubusercontent.com/fujieda/440fa64d310c2b6960f3/raw
• 泊地修理说明页：https://kamigame.jp/艦これ/攻略ガイド/明石の泊地修理.html

其中 WIKIWIKI 明石页比较关键的原文包括：

• 「修理時間は工作艦を旗艦にした瞬間からカウントを開始する」
• 「母港画面に入った際に回復判定が発生（カウントが20分以上）すると、カウントはリセットされ再び0からスタートする」
• 「20分経たずに母港をチェックしてもカウントはそのまま継続される」
• 「工作艦を含む艦隊が遠征や編成の変更を行った場合、カウントはリセットされる」
• 「編成で詳細を見たり、他の艦隊の操作をしたり、装備変更や開発、演習はセーフ」
• 「出撃中はカウントが継続されている」
• 「第1艦隊に明石がいるとき、第2艦隊の編成に第1艦隊の随伴艦を移動してきた場合もリセットされる」
• 「編成展開だと、明石が旗艦の編成を展開してもカウントはリセットされない」

野埼 WIKIWIKI 里比较关键的原文包括：

• 「(野埼or野埼改)を旗艦または2番艦にし、随伴に補給を受けたい艦を配備する。このタイミングで次のカウントダウンタイマーが起動する」
• 「タイマーが起動して15分経過後、母港画面に遷移したタイミングで次の適用条件を満たす場合、随伴艦のcond値上昇が発生する」
• 条件包括「野埼が旗艦または2番艦」「補給完了」「無傷～小破未満」「cond値30以上」「遠征中ではない」「入渠中ではない」等
• 「タイマーは野埼を旗艦または2番艦に置いた状態で編成変更すると、タイマーがリセット」
• 「艦隊編成記録（プリセット）及び随伴艦一括解除ではタイマーリセットが発生しない」
• 「複数の艦隊でそれぞれ野埼を運用する場合でもタイマーは共通」
• 「野埼を戦闘や演習に出撃させてもタイマーには影響は無い」

对照表

场景	原文资料里的说法	PR 当前逻辑	我的判断
明石计时开始	工作舰成为旗舰时开始计数；实际等价于编成作业结束后开始	任意 /api_port/port 且 lastRepairRefresh === 0 就开始	PR 过粗；不应由任意母港事件无条件开始
明石母港判定	20 分以上进入母港并发生回復判定时重新从 0 开始；未满 20 分则继续	任意母港事件超过 20 分就重置	接近但不精确；应以游戏侧回復判定/可生效状态为前提
明石普通编成变更	工作舰所在舰队编成变更会重置；更准确地说，变更舰队的旗舰是工作舰时重置	按变更后舰队是否有工作舰旗舰处理	方向合理
明石跨舰队移动随伴舰	WIKIWIKI 明确写第 1 舰队有明石时，把第 1 舰队随伴移到第 2 舰队也会重置	用 previousFleets 找另一个舰队	PR 这部分是实质修正，应该保留
明石编成展开	明石旗舰编成展开不重置；朝日改/明石之间展开也不重置	/api_req_hensei/preset_select 不处理	PR 这里是对的
明石远征出发	工作舰所在舰队远征会重置	移除了 /api_req_mission/start 处理	PR 缺失；不能用“远征归来不重置”推出“远征出发也不处理”
明石远征归来	资料重点是出发/编成重置；出击中计数继续，归投时可发生判定	/api_req_mission/result 不处理，后续母港事件处理	可以接受，但注释最好限定为“归来本身不是重置点”
明石出击/演习	出击中计数继续；演习安全	默认不处理	PR 可以接受
明石装備変更/开发/其他舰队操作	安全，不重置；20 分后母港判定时按当时修理设施数决定对象	默认不处理	PR 可以接受
明石入渠	第三方说明和验证资料都指向“入渠不是无条件重置”；但明石自己入渠时泊地修理不工作	移除原来的高速入渠重置	移除旧的“高速入渠就重置”方向可以接受，但要注意明石自身入渠/条件不满足时显示和效果不能误判
野埼计时开始	野埼/野埼改在旗舰或 2 号位，并配置随伴后启动	任意 /api_port/port 且 lastNosakiRefresh === 0 就开始	PR 过粗；不应由任意母港事件无条件开始
野埼母港判定	15 分后进入母港，且满足适用条件时随伴 cond 上升	任意母港事件超过 15 分就重置	接近但不精确；应以野埼在位和适用条件为前提
野埼普通编成变更	野埼在旗舰或 2 号位时编成变更会重置	按变更后 1/2 号位是否有野埼处理	方向合理，跨舰队交换修正也有价值
野埼预设/一括解除	WIKIWIKI 明确写预设和随伴舰一括解除不重置	都不处理	PR 这里是对的；我前一版对此过于保守
野埼多个舰队	计时器共通	全局 timerState	PR 方向正确
野埼出击/演习	不影响计时器；触发前回港并补给修理即可	默认不处理	PR 可以接受
野埼远征中/入渠中	这是触发时的适用条件，不满足则不会上升 cond	主要依赖后续展示/状态判断	需要确保不会因为无条件计时导致显示误导

更新后的结论

我现在会把问题收敛成两类：

1. PR 的跨舰队交换修正是有根据的，应该保留。

   明石 WIKIWIKI 明确写了「第 1 舰队有明石时，把第 1 舰队随伴移到第 2 舰队也会重置」。因此只看变更后的 fleets 不够，用 previousFleets 找另一个受影响舰队是合理的。

2. PR 把“计时器启动/母港推进”写得太无条件。

   明石和野埼资料都不是“任意母港事件都可以启动计时器”：

   • 明石是工作舰成为旗舰后开始，母港只是做 20 分钟后的回復判定/更新时间；
   • 野埼是野埼/野埼改在旗舰或 2 号位并配置随伴后启动，母港只是 15 分钟后的适用条件检查。

   所以 lastRepairRefresh === 0 或 lastNosakiRefresh === 0 时，不应该在任意 /api_port/port 上无条件设置时间戳。否则在玩家还没有建立明石/野埼计时条件时，插件也会开始跑一个看起来有效的计时器。

建议的修改方向

• 保留 previousFleets 和跨舰队交换判断。
• 保留 /api_req_hensei/preset_select 不重置；这点 WIKIWIKI 支持。
• 保留野埼随伴舰一括解除不重置；这点 WIKIWIKI 也支持。
• 明石需要恢复或重做 /api_req_mission/start 的处理，因为工作舰所在舰队远征出发是重置点。
• 不要恢复旧的“高速入渠就重置”这种粗逻辑；入渠更像是适用条件问题，不是无条件重置问题。
• 重点修正 /api_port/port：它不应该无条件启动计时器，而应该只在已经存在/已经建立对应计时条件时继续或滚动，并在 UI 展示上避免没有条件时显示有效计时。

一句话总结：

这个 PR 修对了“跨舰队交换需要旧舰队状态”这个点，也修对了“预设展开不重置”这个点；但把母港事件写成无条件启动/推进全局计时器不符合 WIKIWIKI 对明石和野埼计时器的描述，明石远征出发的重置也被漏掉了。

— Copilot

[KagamiChan]

另外补充一点比较细的观察：代码注释里有几处看起来是作者自己实测过的行为，和 WIKIWIKI 的表述相比，可能只是测试场景或观察时点不同。WIKIWIKI 也是玩家整理的资料，不一定绝对正确；这里不是质疑实测结论，而是建议把测试上下文补清楚，方便之后维护。
这些点都属于边界情况，我不认为一定要在这个 PR 里全部做到非常精确；甚至暂时不知道这些细节，也不太影响对主路径的判断。只要主路径行为正确，边界可以先通过注释或后续 issue 记录下来。这里主要是希望避免以后维护时误以为这些行为已经被完整覆盖。

另外，因为插件只能看到 API 响应事件，而且响应处理后本地 store 往往已经是变更后的状态，建议测试说明最好按「触发了哪个 API」「该 API 后 store 里的舰队/舰娘状态是什么」「效果是在这个 API 还是后续 /api_port/port 后观察到的」来描述，而不是只写游戏内页面名称。

1. 远征归来的舰队无法获得野埼效果

   代码里写的是：

   经测试，远征归来不重置
   经测试，远征归来的舰队无法获得效果

   「远征归来不重置」我觉得可以接受。野埼 WIKIWIKI 在适用条件处写的是：

   母港画面に戻った時（出撃や編成画面からはもちろん、遠征リザルトから戻ったときも含む）、以下の条件を満たしていれば、野埼以外のcond値が上昇する。

   同时它又要求：

   野埼が遠征中ではない

   这里可能只是描述粒度不同：WIKIWIKI 说「远征结果后回到母港」这个时机可以发生判定；作者测试的可能是「刚远征归来的那个舰队本身」在该时点不能获得效果。两者不一定矛盾。

   如果方便的话，建议补一下具体测试场景：野埼在归来舰队里，还是在其他待机舰队里？远征结果后是否先补给/修理？观察到的状态是在 /api_req_mission/result 后，还是随后 /api_port/port 后？这样以后看代码时会更容易理解这个 no-op 的边界。

2. 随伴舰一括解除不重置：野埼有明确资料，明石这边可以补一下依据

   野埼 WIKIWIKI 明确写了：

   艦隊編成記録（プリセット）及び随伴艦一括解除ではタイマーリセットが発生しない。

   所以野埼这边把 api_ship_id == -2 当作不重置是有资料依据的。

   明石 WIKIWIKI 的写法更偏一般规则：

   編成変更のあった艦隊の旗艦が工作艦だった場合、カウントがリセットされる

   我没有在明石页看到同样明确的「随伴舰一括解除不重置」例外。也可能游戏里明石同样适用这个例外，只是 WIKIWIKI 没写细。建议如果作者有测过，也补一句说明，这样我们就不用靠类推判断。

3. 改造/改装不重置的范围

   野埼 WIKIWIKI 明确写了：

   タイマー発動後、野埼を野埼改に改造してもタイマーはリセットされない。

   所以野埼 → 野埼改 不重置有资料支持。代码里现在对 /kcsapi/api_req_kaisou/remodeling 两个计时器都统一不处理。这个处理可能也是实测过的；如果是的话，建议简单补一下覆盖范围，例如是否只确认了野埼改造，还是明石/朝日相关场景也确认过。

这些都不一定要求立刻改代码，主要是希望把实测条件写得更完整一点。这样之后维护时，就能区分「WIKIWIKI 没写细」「游戏行为已由作者实测确认」和「代码为了统一处理做了合理近似」这几种情况。

— Copilot