模板讨论:召唤物信息

来自PRTS
跳转到导航 跳转到搜索

新版描述在同时有多个单位撤退的时候可能存在歧义，有下面几种方案：

1. 回退回调零的版本：
具有与持有上限等额的可部署数量与0的撤回数量，每次部署消耗1可部署数量，场上的召唤物离场/回收后增加1撤回数量；存在已撤回数量的情况下，待部署区的召唤物将进入再部署状态（再部署时间结束时重置再部署时间并消耗1撤回数量获得1可部署数量），可部署数量为0的情况下召唤物为不可部署（否则为可部署）

2. 使用Enko的修正版：
至少1个堆叠单位冷却结束后，即可允许部署（且优先显示为可部署）
撤回堆叠单位时，该单位进入再部署冷却队列，队列中最先撤回的进入再部署冷却，其后的堆叠单位再部署冷却暂停
不可部署时，显示最先撤回单位的再部署冷却

3. 使用笔者基于Enko修正版进行的修正版：
至少1个堆叠单位冷却结束后，即可允许部署（且优先显示为可部署）
撤回堆叠单位时，该单位进入再部署冷却队列，队列中存在再部署冷却进行中的单位时，其他堆叠单位的再部署时间暂停在上限时间
不可部署时，显示最先撤回单位的再部署冷却

4. 使用群友Anthony基于修正修正版进行的修正：
至少1个堆叠单位冷却结束后，即可允许部署（且优先显示为可部署）
撤回堆叠单位时，该单位进入再部署冷却队列，队列中最先撤回的一个进入再部署冷却，其他的堆叠单位不开始再部署计时
不可部署时，显示最先撤回单位的再部署冷却

修正版修正了依次撤回多个装置时会不会同时转CD的问题，笔者提供的版本期待进一步修正同时撤退多个单位会不会导致理解为同时转CD的歧义的问题。
笔者同时担心由于机制本身不区别各个装置独立性会不会造成理解歧义
期待各位针对上述描述是否会造成错误理解或者可读性较差的情况进行讨论

笔者建议当前修正先回退，等待该讨论结束(3天无后续讨论)再实施修正，期待各位的意见！

--RushFTK（留言） 2026年7月17日 (五) 13:46 (CST)

改进 群友讨论后改进的描述：

单位初始均为可部署状态，单位撤回后进入再部署状态。
当存在再部署状态单位时，每经过一个再部署冷却周期，使一个再部署状态单位变为可部署状态。

--Xkzl（留言） 2026年7月17日 (五) 15:43 (CST)

让fable分析了一下：

分析
;关于“队列”再部署策略的机制描述(基于 2.7.51 客户端反编译)

针对“中继器”新再部署策略“队列”的几个描述版本,笔者对照 2.7.51 版本 GameAssembly.dll 反编译结果做了逐函数验证,以下为结论,供讨论参考。

代码层事实

“队列”在代码中是卡片策略枚举的第三个取值:Deck.Card.CardPolicy { DEFAULT=0, UNIQUE=1, QUEUED=2 },并配套在卡片状态机中新增了 QUEUING=4(原有 NONE/READY/USING/RESPAWNING)。该策略并不写在 gamedata 数值表里,而是序列化在召唤物 prefab 上(Token._cardPolicy 字段),因此 token_10070_aphris_pc(中继器,再部署时间 30 秒)在表格数据中看不到此字段。

核心实现只有两个计数器加一个计时器(均位于 Deck.Card):

  • m_remainingCnt:待部署区当前持有的堆叠单位总数(含冷却中),上限为 maxDeckStackCnt;
  • m_queuedRespawnCnt:处于冷却队列中的单位数;可用数 = remaining − queued;
  • 唯一一个 PeriodicTimer,仅在 RESPAWNING/QUEUING 状态下走表。
事件 函数 行为
部署 Card.Draw remaining−1;完全不触碰计时器;若可用数归零则转 RESPAWNING(计时器继续走),否则状态不变
单位离场 TokenCard.Recharge(ON_FINISH)+ Card.OnRecycle remaining+1、queued+1;若此前没有单位在冷却,计时器重置为完整再部署时间,状态转 QUEUING(仍有可用)或 RESPAWNING(无可用);若已有单位在冷却,则不做任何事(纯排队)
冷却走完 Card.OnTick queued−1(队首单位变为可用);若队列中仍有单位,计时器重置为完整时间、状态 QUEUING;否则 READY
可部署判定 Card.get_isAvailable READY 或 QUEUING 均判定为可部署

由此可直接裁决争议的推论:

  1. 严格串行:同一时刻只有队首(最早离场)一个单位在冷却;后面的单位根本没有开始计时,轮到它时从零开始计完整的再部署时间。n 个排队的总恢复时间为 n × 再部署时间。
  2. 部署与撤回都不干扰进行中的冷却:部署不重置计时器;离场时若计时器已在走亦不重置。
  3. 可部署显示:只要有至少 1 个冷却完成的单位(且未达场上同时存在上限 maxDeployCnt)即显示可部署(QUEUING 状态既可部署、计时器又在后台继续走);无可用单位时(RESPAWNING)界面显示的就是那个唯一计时器,即队首单位的剩余冷却。
  4. 非离场途径的充能不进队列:RechargeTiming.NORMAL 只增加 remaining 不增加 queued,立即可用——谬因三技能的 token_recharge_cnt=2 属于此类;只有离场触发的 ON_FINISH 充能才排队。
对各版本描述的裁决
  • 版本 1(回退回调零):数学上与实现完全等价——它几乎是双计数器加单计时器循环的字面翻译(“再部署时间结束时重置再部署时间并消耗 1 撤回数量获得 1 可部署数量”即 OnTick 原文)。缺点是读者难以从中直观读出“串行、后面的不计时”这一最易误解之处;另“初始可部署数量与持有上限等额”并非策略本身的性质(初始值来自 tokenInitialCnt,上限可被技能中途扩充)。
  • 版本 2(Enko 修正版):“其后的堆叠单位再部署冷却暂停”不准确——“暂停”暗示存在被冻结的进度,实际是从未开始。
  • 版本 3(基于 Enko 的再修正版):“暂停在上限时间”功能上等价于“未开始”,但表述较绕;且“队列中存在冷却进行中的单位时”的条件句易使人误以为存在“多个单位同时持有冷却进度”的状态,实际不存在。
  • 版本 4(Anthony 修正版):“队列中最先撤回的一个进入再部署冷却,其他的堆叠单位不开始再部署计时”与实现逐字吻合,是四版中最准确的。
推荐描述

以版本 4 为骨架,补上其缺少的两点(串行完整冷却、操作不干扰计时):

队列:决定召唤物的再部署冷却起算时刻与堆叠时的可再部署状态。
撤回或离场的堆叠单位按先后顺序进入再部署队列:任意时刻仅队列中最早离场的一个单位进行再部署冷却,其余单位不开始计时;前一个冷却结束后,下一个才开始计算完整的再部署时间。
冷却结束的单位即刻恢复为可部署;只要存在至少一个冷却完成的堆叠单位(且未达场上数量上限),待部署区卡片即显示为可部署,否则显示最早离场单位的剩余冷却。
部署与撤回均不会重置或暂停正在进行中的冷却。

若用于机制考据,建议双层表述:表现层用上段,实现层附版本 1 的计数器模型(注明“可部署数量 = 持有数 − 队列数,每个冷却周期结束消耗 1 队列数返还 1 可部署数量”),两者互为印证——这也正是代码的真实结构。

附:谬因相关背景数据——中继器常态持有 1 个(天赋 cnt=1)、持续 15/20/25 秒后自动离场入队,一技能使持续时间无限,三技能期间额外 +2 个(即时可用、不入队,技能结束自动撤退)。

看起来最终修改版已经比较贴合实际的代码逻辑了

StarHeartHunt（留言） 2026年7月18日 (六) 11:35 (CST)

赞成

-RushFTK（留言） 2026年7月18日 (六) 11:41 (CST)

反对虽然我觉得一开始我就已经把我在研究队列上遇到的问题、代码的逻辑、难以简化的问题等描述得很清楚了，但我还是想说一次：“队列备注不说人话”问题的本质是“撤回时单位立刻回手”与“持有上限可变”导致的难以简化，整体逻辑其实相当于模拟了一个“手卡与部署中陷阱共用上限”的陷阱师——周期计时器完成时“陷阱+1”，场上陷阱和手卡陷阱加起来数量等于上限时就停着不动。

再者，AI分得清明日方舟的底层逻辑吗？部署在场上的才是“单位（Unit）”，待部署区的是“卡片（Card）”，第一个部署的中继器和第二个部署的中继器是同一个中继器吗？如果认为不是，那又如何定义撤回的中继器和再部署中的中继器是同一个？如果认为是，那又如何去定义“单位撤退的先后”？谬因开技能瞬间，部署两个中继器后，为何不能直接部署第三个中继器？

AI给出的建议可以参考一部分，但没办法直接作为最终版本（AI显然没看明白再部署的意思）。现在这个情况，既然有人认为我的写法“完全不说人话”并多次拒绝讨论并直接撤回我的编辑，我唯一的建议是等更权威的@Hjhk258来处理。

——调零修罗（留言） 2026年7月18日 (六) 17:05 (CST)

> 谬因开技能瞬间，部署两个中继器后，为何不能直接部署第三个中继器？

能够让你花两天才提供如此重要的情报真是累坏你了。

——Enko（留言） 2026年7月18日 (六) 20:03 (CST)

fable 的分析：

回复
;“队列”机制描述的更正与补充:三种等价框架的对照(修订版:三技能部分已依据技能资产解包更正)

回应上方调零修罗的意见,对此前基于 2.7.51 客户端反编译的分析做一次更正与补充。先说结论:机制层事实维持不变;但此前“版本 4 与实现逐字吻合”的说法过头了,予以收回——实现中不存在“单位队列”这一数据结构,“队列描述虚构了单位实体”的批评在实现层成立。另,本版依据 buff_template_data 与技能 prefab 解包结果,更正了旧版关于三技能“第三个中继器需等 30 秒”的错误推断(见第三节)。

一、代码层已验证事实(各方均不冲突)
  • 待部署区侧只有两个计数器与一个循环计时器:m_remainingCnt(持有数,离场瞬间即 +1,即“撤回立刻回手”)与 m_queuedRespawnCnt(待恢复数);可部署数 = 持有数 − 待恢复数。
  • 计时器仅在待恢复数 > 0 时运行;每走完一轮完整再部署时间,待恢复数 −1(可部署数 +1),仍有剩余则重置重走。任意时刻至多一轮计时在进行。
  • 部署与离场均不会重置或暂停进行中的计时(部署不改动计时器;离场时若计时器已在走亦不重置,仅在“此前无计时”时起一轮新计时)。
  • 充能分两类:NORMAL 直接加持有数(立即可用、不产生待恢复);ON_FINISH(离场路径)同时加持有数与待恢复数。
  • 场上是 Token : Character 实例(对象池生成、回收、可能复用);待部署区是 Deck.TokenCard,其上只有计数。“第 n 个部署的中继器与第 m 个是否同一个”在代码层不是有意义的问题;“撤退先后”作为事件顺序是良定义的,但没有任何代码实体与“队列中的某个单位”对应。
二、三种行为等价的描述框架

经逐事件对照(部署 / 离场 / 计时完成 / 充能),以下三个框架在中继器的实际配置下外在行为完全等价,区别仅在叙述视角:

框架 代表 与实现的关系 优势 局限
计数器模型
(可部署数 / 撤回数双计数 + 单计时循环)		 版本 1 与实现结构同构(几乎是代码的字面翻译) 无虚构实体;边界情况(上限变动)下仍然精确 读者难以直观读出“串行、后面的不计时”;文字密度高
产出模型
(手卡与场上共用上限;缺额存在时周期计时器循环产出,每轮 +1,补满即停)		 调零修罗后续提出的“陷阱师”类比 等价映射:缺额 ≡ m_queuedRespawnCnt 最直觉;天然解释“为何部署不扰动计时”(部署不改变缺额) 依赖“场上数 + 持有数 = 上限”不变量,该不变量由“充能均走同步扩上限的 ForceRecharge”保证,属于当前配置的性质而非策略本身的性质
匿名单位 FIFO 队列
(离场单位排队,仅队首计冷却,后续不开始计时)		 版本 2 / 3 / 4(以 4 的措辞最准确) 行为等价的叙述层约定;实现中无对应结构 最接近玩家语感;“显示队首冷却”表述自然 为同质计数虚构了单位身份;版本 2 的“暂停”、版本 3 的“暂停在上限时间”均需替换为“不开始计时”方与行为一致

由于中继器完全同质,三者不可能被任何观测区分;采用哪个框架上正文属于编辑取向问题,而非对错问题。

三、几个具体争点的技术说明
  • “开三技能后部署两个、第三个需要等待”(此条替代旧版错误表述):解包 skchr_aphris_3 技能 prefab 与模板 aphris_sk3[token-withdraw],技能开启时同帧顺序执行:① ForceRechargeToken(+2,NORMAL)——上限 +2、即时获得 2 个可部署数、不入队;② WithdrawTokens 强制撤回在场中继器——经 aphris_pc[recharge](+1,ON_FINISH)入队并新起整轮计时;③ ResetTokenRespawnTime(waitFirstPeriod=false)——即“重置再部署”,反编译确认为剩余计时置 0。归零的“完成”须待下一个战斗逻辑帧的 OnTick 结算,故开技能当帧(含暂停中,暂停不走 OnTick)恰可部署 2 个,第三个于下一逻辑帧即可部署,无需等待 30 秒——与实测“连放两个后暂时放不出第三个”严丝合缝,差的是一帧而非一轮冷却。
  • 上限可变的瞬态:RefreshTokenDeployAndDeckStackCnt 仅增减上限、不裁剪持有数/待恢复数;技能结束时由模板 aphris_sk3[on_finish] 显式执行 ForceRechargeToken(−2,ON_FINISH,上限与计数同步钳减)→ 撤回场上全部中继器 → 再次归零再部署时间,故技能结束后剩余 1 个中继器同样下一逻辑帧可用。“上限可变导致难以简化”的判断属实,但其收敛路径已可从数据完整读出。
  • 证据性质的说明(替代旧版“联合推定”一条):三技能节点序列及参数(_cntKey / _rechargeTiming / _waitFirstPeriod 等)已从解包的 gamedata/battle/buff_template_data.json 直接读出,不再依赖实测推定;计时器语义见 PeriodicTimer.Reset / Update 反编译。本节结论均可按 templateKey 复核。
四、小结
  • 维持:机制层全部结论(串行单计时、完整冷却、部署/离场不扰动计时、两类充能、可部署判定)。
  • 收回:“版本 4 逐字吻合实现”——应为“行为吻合;结构上与实现同构的是版本 1”;另收回旧版“三技能被撤回者需等 30 秒”的说法,以第三节修订为准。
  • 最终采用何种表述,建议以“行为等价、各有边界”为前提交由编辑共识(或如上方所议由更权威编辑)裁定;如采用队列表述,建议吸收“其他单位不开始再部署计时”的措辞;如采用计数/产出表述,建议补一句“同一时刻至多一个冷却在进行,总恢复时长 = 缺额 × 再部署时间”以规避最常见的误读;涉及三技能处按“+2 即时充能 → 强制撤回入队 → 再部署时间归零(下一逻辑帧生效)”表述。

StarHeartHunt（留言） 2026年7月18日 (六) 20:31 (CST)

我测队列那天就说了，当时也有测试录像，你非得说我两天后才说“这么重要的情报”。

AI这次聪明不少也喂了谬因机制，但我的意见依旧是等@Hjhk258来处理。

——调零修罗（留言） 2026年7月19日 (日) 04:22 (CST)

检索自“https://prts.wiki/index.php?title=模板讨论:召唤物信息&oldid=409374”