|
|
|
一、设计理念：从 "机器人脚本" 到动态定时任务
传统传奇引擎里有一个 "机器人" 的概念 —— 你可以在配置文件里定义一个机器人，指定它的执行方式（每隔多久执行一次、每天几点执行、每周几执行）和要执行的脚本标签。引擎启动后会自动加载这些机器人配置，按时间调度执行。这种方式的好处是稳定可靠，引擎底层调度；坏处是不灵活 —— 要加一个定时任务就得改配置文件重启服务器，不能动态添加和删除。
VV 引擎的机器人事件接口，就是把这个能力从 "配置文件静态定义" 变成了 "脚本动态管理"。 addscheduled 动态添加一个定时任务， delscheduled 动态删除， hasscheduled 判断是否存在。三个接口，让定时任务的管理完全脚本化了。
第一，动态灵活。 不需要改配置文件重启，脚本里随时添加和删除定时任务。活动开始时加一个定时任务，活动结束时删掉，完全自动化。
第二，参数化。 任务名称、执行方式、时间参数、跳转标签全部通过参数传入，同一个接口可以创建完全不同的定时任务。
第三，引擎级调度。 虽然是脚本动态添加的，但底层调度还是引擎的机器人系统，稳定可靠，不依赖脚本的定时器循环，不会因为脚本异常而停止。
这种 "把引擎的静态配置能力封装成动态接口" 的设计思路，在 VV 引擎里很常见。机器人事件是其中的典型代表 —— 引擎有成熟的定时调度能力，封装成接口让脚本能动态使用，既保留了引擎调度的稳定性，又获得了脚本的灵活性。
二、六种执行方式：从秒级到星期级的完整时间维度
机器人事件支持六种执行方式，覆盖了从高频到低频的完整时间维度。这六种方式不是随便分的，而是对应了不同的使用场景。
按秒运行（SEC） 是最高频的执行方式，每隔 N 秒执行一次。适合需要高频检测的场景 —— 比如每秒检测一次活动状态、每秒给全服玩家加一次 buff、每秒更新一次排行榜数据。秒级执行的性能消耗较大，要谨慎使用，不要什么任务都用秒级。
按分运行（MIN） 每隔 N 分钟执行一次，是比较常用的频率。适合中等频率的检测 —— 比如每 5 分钟检查一次服务器状态、每 10 分钟刷新一次活动 NPC、每 30 分钟发一次全服公告。分钟级是性能和实时性的平衡点，大部分定时任务用分钟级就够了。
按小时运行（HOUR） 每隔 N 小时执行一次，适合低频任务 —— 比如每小时重置一次副本次数、每 2 小时刷新一次世界 BOSS、每 6 小时结算一次活动排名。小时级任务通常是周期性的系统维护或重置。
按天运行（DAY） 每隔 N 天执行一次，适合跨天的长周期任务 —— 比如每天重置一次日常任务、每 3 天刷新一次商店、每周结算一次赛季排名。天级任务通常和玩家的日常 / 周常系统绑定。
按每天什么时候运行（RunOnDay） 不是 "每隔多久"，而是 "每天的指定时间点" 执行。比如每天中午 12 点、每天晚上 8 点。适合固定时间的活动 —— 比如每天 12 点开启双倍经验、每天 20 点开启沙巴克、每天 0 点重置日常。这种方式和 DAY 的区别是：DAY 是 "每隔 N 天"，RunOnDay 是 "每天固定时间点"。如果需要每天固定时间执行，用 RunOnDay 而不是 DAY。
按星期几及时间运行（RUNONWEEK） 是最精细的调度方式，指定每周几的几点执行。比如每周六晚上 8 点、每周一中午 12 点。适合周期性的周常活动 —— 比如每周六晚 8 点攻城战、每周日下午 3 点世界 BOSS、每周一 0 点重置周常任务。这种方式是前五种都做不到的 —— 前五种只能按间隔，不能指定星期几。
六种执行方式的设计思路是：间隔型（SEC/MIN/HOUR/DAY）覆盖周期性重复任务，时间点型（RunOnDay/RUNONWEEK）覆盖固定时间触发的任务。 两种类型互补，基本上能覆盖所有定时调度的需求。
这里有个心得：选执行方式的时候，先想清楚是 "每隔多久" 还是 "固定时间点"。 如果是周期性重复（比如每 5 分钟检测一次），用间隔型；如果是固定时间触发（比如每天 12 点活动开始），用时间点型。不要用间隔型去模拟固定时间点 —— 比如用 "每 24 小时执行一次" 来模拟 "每天 0 点执行"，因为服务器启动时间不一定是 0 点，第一次执行的时间会偏移，而且服务器重启后计时会重置。固定时间点就用 RunOnDay 或 RUNONWEEK，不要偷懒用间隔型。
三、和其他定时器的对比：四种定时机制各有定位
VV 引擎里不止一种定时机制，之前讲过全局定时器（OpenGlobalTimer）、地图定时器（setenvirontimer）、延时跳转（delaygoto），现在又有机器人事件（addscheduled）。四种定时机制，各有各的定位，不要混用。
全局定时器（OpenGlobalTimer） 是脚本级的循环定时器，按秒间隔触发 OnGlobalTimer 回调。特点是：脚本管理、间隔固定、回调统一、需要脚本自己按 ID 分发。适合脚本内部的周期性逻辑，比如技能 CD 检测、buff 计时。全局定时器依赖脚本环境，如果脚本热重载可能会受影响。
地图定时器（setenvirontimer） 是绑定地图的循环定时器，到时间触发指定函数。特点是：绑定地图、地图销毁定时器消失、适合地图内的周期性逻辑。做副本、活动地图里的定时刷怪、阶段切换时用。
延时跳转（delaygoto） 是一次性延时执行，延迟指定毫秒后调用函数，可取消。特点是：一次性、毫秒级精度、可取消。适合 "几秒后执行" 的场景，比如技能延迟生效、回城读条、死亡延迟复活。
机器人事件（addscheduled） 是引擎级的定时任务，支持六种执行方式，从秒级到星期级。特点是：引擎调度、稳定可靠、支持固定时间点、支持星期级调度、异步操作。适合全服级的、长周期的、固定时间点的定时任务，比如全服活动、日常重置、定时公告。
- 脚本内短周期循环 → 全局定时器
- 地图内周期逻辑 → 地图定时器
- 一次性延时执行 → 延时跳转
- 全服级长周期 / 固定时间点 → 机器人事件
很多人容易把全局定时器和机器人事件搞混，觉得都是 "定时执行"。但两者的定位完全不同：全局定时器是脚本级的，适合短周期、脚本内部的逻辑；机器人事件是引擎级的，适合长周期、全服级、固定时间点的任务。比如 "每秒检测一次玩家 buff" 用全局定时器，"每天 0 点重置日常" 用机器人事件，不要搞反。
四、异步操作：一个容易被忽略的重要细节
文档里有一句话很容易被忽略："增删机器人事件接口为异步操作"。这句话非常重要，它意味着 addscheduled 和 delscheduled 不是立即生效的，而是异步的 —— 调用后引擎会在某个时刻处理，不是调用完就一定生效了。
这个细节会影响实际使用。比如你调用了 addscheduled 添加一个任务，紧接着调用 hasscheduled 判断是否存在，可能会返回 false，因为异步操作还没处理完。或者你调用了 delscheduled 删除一个任务，但任务可能还会再执行一次，因为删除操作还没生效。
异步操作的设计是有原因的。机器人事件的增删涉及到引擎的调度器，可能需要加锁、更新调度队列，这些操作如果同步执行，可能会阻塞脚本线程。做成异步的，脚本调用后立即返回，引擎在后台处理，性能更好。
第一，添加后不要立即判断是否存在。 如果需要确认添加成功，等一会儿（比如下一个脚本周期）再判断，或者通过任务是否实际执行来确认。
第二，删除后可能还会执行一次。 如果任务的执行时间点刚好在删除操作生效之前，可能会再执行一次。做关键任务删除时，要考虑到这种可能性，或者在任务函数里加判断（比如活动是否结束）。
第三，不要在短时间内频繁增删同一个任务。 异步操作如果频繁调用，可能会导致操作顺序混乱（比如先删后加变成先加后删）。如果需要修改任务，建议先确认删除生效后再添加，或者用其他方式（比如在任务函数里判断是否执行）。
异步操作这个细节，文档里只用一句话带过，但实际使用中如果不注意，可能会遇到 "明明删了怎么还在执行"" 明明加了怎么说不存在 " 之类的诡异问题。理解了异步的特性，这些问题就有了解释。
五、应用场景：机器人事件能做什么
机器人事件的应用场景非常广泛，核心是 "全服级的、周期性的或固定时间点的定时任务"。
全服活动调度是最经典的场景。每天固定时间开启活动 —— 比如每天 12 点双倍经验、每天 20 点攻城战、每周六晚 8 点世界 BOSS。用 RunOnDay 或 RUNONWEEK 添加定时任务，到时间自动执行活动开启逻辑。活动结束时间也可以用定时任务控制 —— 比如活动持续 2 小时，添加一个 2 小时后执行的任务来关闭活动（不过这种短周期的用全局定时器或 delaygoto 可能更合适）。
日常 / 周常重置是另一个高频场景。每天 0 点重置日常任务次数、每周一 0 点重置周常任务、每月 1 号重置月度奖励。用 RunOnDay（每天 0 点）或 RUNONWEEK（每周一 0 点）添加定时任务，到时间自动执行重置逻辑。这种重置任务是典型的固定时间点触发，用机器人事件最合适。
定时公告 / 提醒是简单但实用的场景。每隔一段时间发一次全服公告 —— 比如每 30 分钟提醒一次 "攻城战即将开始"、每小时播报一次 "当前双倍经验活动进行中"。用 MIN 或 HOUR 执行方式，到时间自动发公告。活动期间添加，活动结束删除。
数据统计 / 存档是运维类场景。定时统计服务器数据并存档 —— 比如每小时统计一次在线人数峰值、每天统计一次经济数据（金币产出、物品消耗）、每周生成一次运营报表。用 HOUR 或 RunOnDay 执行方式，到时间自动统计并存档。这些数据可以存在文本文件或数据库里，供运营分析使用。
定时刷新 / 重置是游戏系统类场景。定时刷新商店物品、定时刷新世界 BOSS、定时重置副本次数、定时重置 PK 值。这些都是周期性的系统维护任务，用对应的执行方式添加定时任务即可。
活动倒计时 / 阶段切换是活动类场景。活动分多个阶段，每个阶段持续一段时间，到时间自动切换到下一阶段。比如活动第一阶段 10 分钟、第二阶段 15 分钟、第三阶段 20 分钟，用机器人事件（或全局定时器，看周期长短）控制阶段切换。
这些应用场景的共同特点是：全服级、不绑定特定玩家或地图、需要稳定可靠的调度、可能是固定时间点触发。这些特点正好匹配机器人事件的定位 —— 引擎级调度、稳定可靠、支持固定时间点和星期级。
|
|
