档案编号 ACT-R · 子页 01 / 01

活动参与规则说明

这一页只处理三件事:一个活动条目的参与条件按什么判定、节奏以什么为单位往前推、 当页面上的状态和实际情况对不上时该走哪条路去核。2278游戏库把活动形态、赛季轮换与礼包码投放 放在活动专区里总览,本页不再重复那部分内容, 只把规则本身拆开讲清楚。

分层编号与刻度线组成的规则层级结构示意图
规则层级示意:01 至 06 编号章节沿同一条刻度线向下推进,每一级只负责一类判定说明。

01-01

本页在活动专区里的位置

活动专区解决的是“有哪些活动形态、节奏多久轮换一次、礼包码和开服节点怎么跟活动对齐”; 本页解决的是“具体到一条活动,参与这件事本身怎么判定”。两者的边界很清楚: 专区回答选项,这里回答判定。

因此本页不会列出活动清单,也不会给出具体档期。所有涉及时间的位置一律使用相对说法—— 最近一轮维护、本周三期、上一赛季阶段——因为节奏本身是轮换的, 写死某一天反而会让规则在下一轮失效。

02-01

参与条件的六项判定

每一项都按同一套字段读:先看条件项本身,再看判定依据来自哪个字段,最后列出需要提前确认的部分。 六项全部通过,才说明这条活动在当前阶段处于可参与状态;任意一项缺字段,都先按未确认处理。

  1. C-01

    开服节点是否进入有效阶段

    判定依据
    条目登记的开服时间是否已经落在当前赛季的有效区间内
    提前确认
    该服本轮维护是否已完成,开服时间与赛季阶段标签是否属于同一轮
  2. C-02

    条目是否处于最近一轮维护窗口内

    判定依据
    条目的更新日期字段是否为本轮日期,而非上一轮遗留未刷新的记录
    提前确认
    同一批条目是否在同一天完成刷新,避免半批次状态错位
  3. C-03

    包体档位与可用空间是否匹配

    判定依据
    条目登记的包体大小落在四档区间中的哪一档,是否在设备可用空间之内
    提前确认
    实际可用空间是否留出余量,1GB 以内条目是否比登记档位更小
  4. C-04

    礼包码是否处于可用标记

    判定依据
    礼包码字段当前是“可用”“暂缓”还是“本轮待核对”三种标记中的哪一种
    提前确认
    该礼包码的登记轮次是否与当前轮次对齐,是否需要等下一轮核对
  5. C-05

    赛季节奏阶段是否吻合

    判定依据
    活动当前处于开启段、推进段、收官段还是结算段,该阶段是否仍接受参与
    提前确认
    阶段标签与条目更新日期是否同一轮次,结算段的活动是否只做回填
  6. C-06

    三要素字段是否齐全

    判定依据
    更新日期、包体大小、礼包码三项是否同时可读,有无缺项或空白
    提前确认
    缺项条目是否已在补录队列中,补录完成后会重新进入最近一轮维护
判断分支与节点组成的条件判定流程抽象图
六项判定依次通过,任意一项未确认则回到对应字段重新读取,不跳步。

03-01

节奏以轮次和赛季阶段为单位

站内的节奏不按自然日计算,也不按活动自报的档期计算。它有两个刻度: 一个是条目维护轮次,一个是赛季阶段。轮次决定条目字段什么时候被刷新, 赛季阶段决定活动当下处于哪种状态。

  1. 阶段 Ⅰ

    开启段

    条目批量登记,新条目进入待核验队列;礼包码统一标记为本轮待核对,参与判定以开服节点为准。

  2. 阶段 Ⅱ

    推进段

    条件判定进入高峰,礼包码由待核对转为可用或暂缓;包体大小字段做二次复核,错位记录被改回。

  3. 阶段 Ⅲ

    收官段

    不再新增参与条目,只做字段回填;活动状态由进行中转为待结算,未确认字段集中进入补录队列。

  4. 阶段 Ⅳ

    结算段

    礼包码整体轮换核对,条目更新日期推进到新一轮,赛季阶段标签重置,判定重新从开启段开始。

轮次口径

条目维护按周推进,每轮新增与修订 300 至 500 条。活动状态的切换不早于该轮维护完成, 所以同一个阶段标签在不同轮次里会重复出现,判断时以条目更新日期所在的轮次为准,而不是以标签本身为准。

阶段刻度条与状态切换标记的示意图
四个阶段沿同一条刻度推进,轮次完成后状态才切换,刻度之间不留空档。

04-01

状态对不上时的核实顺序

如果页面显示的礼包码标记、包体档位或阶段标签与实际看到的情况不一致,先不要按页面直接下结论。 按下面的顺序走一遍,多数错位在第二步就能定位到原因。

  1. 1

    核对三要素字段

    先看更新日期、包体大小、礼包码是否都读得到。缺一项,说明该条目还在补录队列里,不代表规则本身有变化。

  2. 2

    对齐所处轮次

    把条目更新日期与当前轮次对齐。若条目停在上一轮,它显示的是上一轮的阶段与礼包码标记,等本轮维护落地后再读一次即可。

  3. 3

    走邮件通道确认

    前两步仍无法解释时,把条目名称、看到的三要素字段与页面对应位置一并写清,发到客服邮箱。收录与查询类问题以邮件沟通为主,首次回复在 1 个工作日内。

客服邮箱
support@game-2278-install.com.cn
客服电话
400-9353-4911(工作时段接听)
来信地址
甘肃省兰州市城关区雁滩路4226号

以上渠道用于条目收录与查询口径的沟通。地址与电话仅作为联系信息登记,不代表总部、办公室、 直营网点或注册地址。更完整的受理范围与响应说明见 联系我们

05-01

哪些请求不在处理范围内

规则边界写清楚,比多列几条参与方式更有用。下面四类请求即使发到客服邮箱也不会被受理, 不是处理优先级的问题,而是它们超出了本站的能力范围。

  • 索取安装文件或下载入口

    档案只登记条目字段,不存放文件,也不提供任何指向外部资源的入口。

  • 要求承诺安装或运行结果

    包体、阶段与礼包码标记都是登记信息,能否顺利安装取决于设备条件,站方不做任何结果性保证。

  • 提前索取下一轮条目名单

    条目在维护轮次落地前处于待核验状态,未定稿的内容一律不对外提供。

  • 代填账号信息或代为注册

    活动参与过程中不收集任何账号、口令或个人身份信息,也不会代办登记类操作。

另外,规则只解释判定与节奏本身。活动的开启时间、礼包码投放节点与阶段标签怎么互相配合, 属于活动专区的范围;本页不写具体档期,也不排出活动清单。