|
一、整体架构：从 "发消息" 到 "交互" 的四层设计
二十五个接口看起来多，但按功能可以分成四层，每层管一件事：
第一层是通信层：handlerequest（监听消息）、sendluamsg（发送消息）、sendrefluamsg（视野内广播）。这一层管的是前后端之间的自定义消息通信—— 不是引擎预设的消息，而是你自己定义消息 ID 和消息体，前端和后端通过这套通道传递任意数据。这是最底层的通信能力。
第二层是消息显示层：sendmsg（聊天框消息）、sendmapmsg（地图消息）、guildnoticemsg（自定义颜色消息）、setchatprefix（聊天前缀）、release_print（控制台打印）。这一层管的是文字消息怎么显示给玩家—— 在聊天框、在地图频道、用什么颜色、带什么前缀。
第三层是公告展示层：sendcentermsg（屏幕中间大字体）、sendtopchatboardmsg（聊天框固顶）、sendmovemsg（屏幕滚动）、sendcustommsg（任意坐标公告）、sendmsgnew（主屏幕弹出公告）、senddelaymsg（倒计时提示）。这一层管的是在屏幕的不同位置以不同方式展示公告—— 中间、顶部、滚动、任意坐标、弹窗、倒计时，覆盖了所有公告展示需求。
第四层是交互与辅助层：messagebox（确认 / 取消弹窗）、filterglobalmsg（过滤全服消息）、gotolabel（批量触发）、navigation（新手引导）、viewplayer（查看他人面板）、openwindows（打开自己面板）、healthspellchanged（刷新血蓝）、callscript（调用 TXT 脚本）、callact（调用 #act 命令）、callcheck（调用 #if 命令）、getvisibleactor（获取视野内对象）。这一层管的是和玩家交互以及脚本之间互操作—— 弹窗确认、界面引导、面板打开、TXT 和 Lua 互相调用。
四层架构的设计思路是：通信层传数据、消息层显示文字、公告层展示重要信息、交互层处理玩家反馈和脚本互操作。从底层数据传输到上层用户交互，层层递进，覆盖了游戏和玩家之间所有的沟通方式。
这种分层设计的好处是：每一层职责清晰，接口不会混在一起。需要传自定义数据用通信层，需要发文字提示用消息层，需要发重要公告用公告层，需要弹窗交互或脚本互调用交互层。开发者根据需求选对应的层和接口，不会在二十五个接口里迷路。
二、Lua 消息通信：前后端自定义协议的通道
handlerequest、sendluamsg、sendrefluamsg 这三个接口是整个消息公告模块最底层的通信能力，也是最灵活的部分。
handlerequest 是消息监听函数，需要在 QFunction-0.lua 文件中注册。当前端发送 Lua 消息时，引擎会调用这个函数，传入玩家对象、消息 ID、三个整数参数和一个字符串消息体。你在函数里根据消息 ID 做分发处理 —— 消息 ID=10 做什么、ID=20 做什么，自己定义。
sendluamsg 是发送消息，传给指定玩家，参数和 handlerequest 对应 —— 消息 ID、三个整数参数、字符串消息体。文档里特别注明 sMsg 消息体最大长度 16000 字节，这个限制要注意，大数据要分片或者用其他方式传输。
sendrefluamsg 是视野内广播，和 sendluamsg 参数一样，但不是发给单个玩家，而是发给玩家视野内的所有玩家。做附近玩家同步的时候用 —— 比如玩家做了一个动作，需要让周围的人都看到，就用视野内广播，不需要遍历周围玩家逐个发。
这三个接口的设计思路是：给开发者一条自定义的前后端通信通道。引擎预设的消息（比如移动、攻击、聊天）有固定的格式和处理逻辑，但有时候你需要传自定义数据 —— 比如自定义 UI 的交互、自定义活动的状态同步、自定义系统的前后端通信。这时候预设消息不够用，就需要这条自定义通道。
消息 ID + 三个整数参数 + 字符串消息体的格式设计很实用。三个整数参数可以传简单的数值（比如类型、数量、状态），字符串消息体可以传复杂的 JSON 数据（比如结构化的配置、列表、对象）。简单数据用整数参数省带宽，复杂数据用 JSON 字符串传，两种方式互补。
实际使用中的心得是：消息 ID 要规划好，不要随便用。消息 ID 是自定义协议的标识，不同的系统用不同的 ID 段 —— 比如 1000-1999 给自定义 UI 用、2000-2999 给活动系统用、3000-3999 给战斗系统用。提前规划好，避免不同系统的消息 ID 冲突。还有，handlerequest 里的分发逻辑建议用 table 映射（local handlers = {[10]=func1, [20]=func2}），不要写一长串 if-elseif，ID 多了之后维护困难。
还有一个细节：sendluamsg 的三个整数参数是可选的（文档里标了 "空"），字符串消息体也是可选的。如果只需要传消息 ID 做一个简单通知，可以只传 ID，其他参数省略。但要注意 handlerequest 那边接收时要做好 nil 判断，不要假设参数一定存在。
三、聊天框消息体系：七种类型与十三种显示频道
sendmsg 和 sendmapmsg 是最常用的文字消息接口，它们的设计体现了 "显示位置和样式分离" 的思路。
sendmsg 是聊天框消息，支持七种类型：普通红色广播、带 NPC 名的红色广播、带人物 NPC 名的红色广播、NPC 头顶说话、红色私聊、绿色私聊、蓝色私聊。消息内容是 JSON 格式，包含 Msg（文本）、FColor（前景色）、BColor（背景色）。
七种类型的区别在于显示位置和前缀：前三种是全服广播（在聊天框的广播频道滚动显示），区别是带不带名称前缀；第四种是 NPC 头顶冒泡（不是聊天框，而是 NPC 头上的对话气泡）；后三种是私聊（只有目标玩家能看到，在聊天框里以不同颜色显示）。
sendmapmsg 是地图消息，比 sendmsg 更强大。它的 JSON 格式除了 Msg、FColor、BColor 之外，还有 Type（显示类型）、Time（倒计时）、SendName（发送人）、SendId（发送 ID）。Type 支持十三种显示类型：系统频道、行会频道、组队频道、顶部跑马灯公告、屏幕跑马灯公告（可控制 Y 轴）、聊天上方公告、固定聊天、systemtips、可控制 xy 坐标广播、屏幕跑马灯公告（系统公告）、系统频道（带超链）、系统公告缩放。
十三种 Type 的设计非常细致，覆盖了各种公告展示需求：
- 频道类（1-3）：在不同聊天频道显示，类似玩家聊天
- 跑马灯类（4-5、11）：在屏幕顶部或指定 Y 轴位置滚动播放，适合重要公告
- 公告类（6、8、9、13）：在聊天框上方或固定位置显示，适合持续提示
- 坐标类（7、10）：在屏幕任意坐标显示，适合自定义 UI 位置的提示
- 超链类（12）：带超链接的系统消息，玩家可以点击链接
sendmapmsg 虽然叫 "地图消息"，但通过 Type 参数可以实现各种显示效果，不局限于地图频道。它的设计思路是：一个接口 + Type 参数，覆盖所有文字公告的显示需求。不需要为每种显示方式写一个接口，用 Type 区分，接口简洁但功能强大。
实际使用中的心得是：sendmsg 适合简单的私聊和基础广播，sendmapmsg 适合复杂的公告展示。如果只是给玩家发一个 "获得物品" 的提示，用 sendmsg 的类型 5/6/7 就行，简单直接。如果要发活动公告、跑马灯、倒计时提示，用 sendmapmsg 的 Type 参数，可以控制显示位置、持续时间、发送人信息，更灵活。
还有一个心得：FColor 和 BColor 的颜色值要测试确认。文档里示例用的是 255、0、180、251 这些数值，但具体数值对应什么颜色需要测试。可能是颜色索引（0-255 对应调色板颜色），也可能是 RGB 的某种编码。建议先写个测试脚本，发不同颜色值的消息看实际效果，建立一个颜色值对照表，以后直接用。
四、屏幕公告矩阵：六个接口覆盖屏幕每个位置
sendcentermsg、sendtopchatboardmsg、sendmovemsg、sendcustommsg、sendmsgnew、senddelaymsg，这六个接口构成了屏幕公告的完整矩阵 —— 每个接口负责屏幕上的一个位置或一种展示方式。
sendcentermsg 是屏幕中间大字体公告，在屏幕正中央以大字体显示，非常醒目。支持八种发送对象（自己、所有人、行会、国家、当前地图、替换模式、组队等），可以设置显示时间，还支持倒计时跳转 —— 消息文字里包含 % d 显示倒计时，倒计时结束后自动跳转到指定脚本函数。这个倒计时跳转功能很实用，做 "活动即将开始" 的倒计时公告时，倒计时结束自动执行活动开始逻辑，不需要自己写定时器。
sendtopchatboardmsg 是聊天框固顶信息，固定在聊天框顶部显示，不会被新消息刷走。支持显示 / 不显示发送人名称，支持倒计时（文字中的 % d 自动替换）。做持续提示的时候用 —— 比如 "活动进行中，剩余时间 XX 秒"，固定在聊天框顶部，玩家随时能看到，不会被聊天消息淹没。
sendmovemsg 是屏幕滚动信息，在屏幕上从下往上或从右往左滚动显示（具体方向要看引擎实现）。可以设置 Y 坐标、滚动次数。做弹幕式公告或者重要通知滚动播放时用，比静态公告更吸引注意力。
sendcustommsg 是屏幕任意坐标公告，可以指定 X 和 Y 坐标，在屏幕的任意位置显示公告。支持五种发送对象（全服、自己、组队、行会、当前地图）。这个接口的灵活性最高 —— 你想在屏幕哪个位置显示就在哪个位置显示，适合配合自定义 UI 做提示，比如在某个按钮旁边显示 "点击这里" 的引导文字。
sendmsgnew 是主屏幕弹出公告，在主屏幕弹出一个公告面板（可能是居中的弹窗或者横幅），支持显示时间。这个和 sendcentermsg 的区别可能是展示样式不同 ——sendcentermsg 是大字体文字，sendmsgnew 是公告面板（可能带边框、背景、图标）。具体区别需要实测确认。
senddelaymsg 是倒计时信息提示，在指定位置显示倒计时，支持换地图是否删除、倒计时结束跳转函数、X 坐标。这个和 sendcentermsg 的倒计时功能类似，但更轻量 —— 可能只是一个小的倒计时提示，不是大字体公告。做技能冷却提示、buff 倒计时、活动倒计时的时候用。
六个接口的设计思路是：按展示位置和方式拆分，每个接口专精一种场景。中间大字体用 sendcentermsg，聊天框顶部用 sendtopchatboardmsg，滚动用 sendmovemsg，任意坐标用 sendcustommsg，弹出公告用 sendmsgnew，轻量倒计时用 senddelaymsg。虽然接口多了，但每个接口的用途明确，不会混淆。
实际使用中的心得是：公告不要滥用，重要信息才用公告。屏幕中间大字体、跑马灯、弹出公告这些都很醒目，如果频繁使用会严重干扰玩家游戏。建议：普通提示用聊天框消息（sendmsg），持续提示用聊天框固顶（sendtopchatboardmsg），重要事件才用屏幕中间大字体（sendcentermsg）或弹出公告（sendmsgnew）。层级分明，玩家才不会被消息淹没。
还有一个心得：倒计时功能（% d 替换和结束跳转）要注意文字格式。sendcentermsg 和 sendtopchatboardmsg 都支持在文字中用 % d 显示倒计时，这个 % d 会被自动替换成剩余秒数。但要注意文字里只能有一个 % d，而且跳转函数要放在 QFunction 脚本中。如果文字里没有 % d，倒计时可能不显示或者跳转不生效。
五、交互消息：弹窗确认与消息过滤
messagebox 和 filterglobalmsg 这两个接口虽然少，但代表了消息系统从 "单向通知" 到 "双向交互" 的升级。
messagebox 是弹出窗口消息，在玩家客户端弹出一个确认对话框，显示内容，有确定和取消两个按钮。确定后跳转到 flag1 指定的脚本函数，取消后跳转到 flag2 指定的函数。跳转时可以带参数（文档示例里 flag1 是 "@func_ok,1,2,3"，参数会传给回调函数）。
这个接口的意义在于：让消息从 "单向通知" 变成了 "双向交互"。普通消息是游戏告诉玩家一件事，玩家只能看不能回应。messagebox 是游戏问玩家一个问题，玩家可以选择确定或取消，游戏根据玩家的选择执行不同的逻辑。做确认类操作的时候必须用这个 —— 比如 "确定要删除这件装备吗？"" 确定要花费 100 元宝传送吗？"，玩家确认后才执行，避免误操作。
messagebox 的跳转参数设计很实用 —— 确定和取消分别跳转到不同的函数，还能带参数。这样你可以在回调函数里根据参数做不同处理，不需要用全局变量传递上下文。比如删除装备的确认框，确定后跳转到删除函数并传入装备 ID，取消后跳转到取消函数并传入装备 ID，两个函数都能拿到装备 ID 做后续处理。
filterglobalmsg 是过滤全服提示信息，开启后玩家不再接收 SENDMSG、GuildNoticeMsg 等脚本命令发送的全服提示信息。这个接口是给玩家用的 —— 如果玩家觉得全服公告太吵，可以开启过滤，眼不见为净。做系统设置的时候提供这个选项，让玩家自己决定要不要接收全服公告。
这个接口的存在说明引擎考虑到了 "消息过载" 的问题 —— 全服公告太多会影响体验，给玩家一个过滤开关是合理的。但也要注意，开启过滤后玩家可能错过重要公告，所以特别重要的通知（比如服务器维护、紧急事件）可能需要用其他方式（比如登录弹窗）确保玩家能看到，不要完全依赖全服公告。
实际使用中的心得是：messagebox 的回调函数要放在正确的位置。文档里说跳转函数需要放在 QFunction 脚本中，不要放在其他文件里，否则可能找不到。还有，回调函数的参数是通过 flag 字符串传递的（比如 "@func_ok,1,2,3"），函数定义里用... 接收可变参数，不要写死参数个数。
还有一个心得：重要操作一定要用 messagebox 确认。删除物品、消耗元宝、退出行会、放弃任务这些不可逆操作，一定要弹确认框，不要直接执行。玩家误操作的后果很严重，一个确认框能避免很多投诉。
六、批量触发与 TXT/Lua 互调：脚本之间的桥梁
gotolabel、callscript、callact、callcheck、getvisibleactor 这五个接口，解决的是 "脚本之间怎么互相调用" 和 "怎么让一群人同时执行脚本" 的问题。
gotolabel 是批量触发，让一组玩家同时执行指定的脚本函数。支持五种触发模式：小组成员触发、行会成员触发、当前地图人物触发、当前角色范围人物触发（需要指定 range）、当前国家人物触发。跳转时可以带参数。
这个接口的应用场景很广：行会集体传送到指定地图、活动地图所有玩家同时加 buff、范围内所有玩家同时扣血、国家成员同时收到任务。不需要你自己遍历玩家列表逐个调用，gotolabel 一次性搞定，引擎内部处理遍历和触发。
五种触发模式覆盖了不同的 "群体" 定义：小组（组队）、行会、地图、范围、国家。你需要哪个群体就用哪个模式，模式 3（范围）还需要指定范围大小，实现 "以玩家为中心 N 格内的所有人触发"。
callscript 是调用 TXT 脚本命令，可以调用指定文件中的指定标签（@label），执行 TXT 脚本内容。文档里特别注明 "该接口为异步调用，且消耗大，推荐使用 callscriptex"（虽然 callscriptex 不在这个文档里，但说明引擎有更优的替代方案）。
这个接口的意义是Lua 调用 TXT—— 在 Lua 脚本里执行传统的 TXT 脚本逻辑。很多老版本的功能是用 TXT 脚本写的，迁移到 Lua 时不需要全部重写，可以用 callscript 调用原来的 TXT 脚本，逐步迁移。或者某些功能 TXT 脚本写起来更方便（比如复杂的 NPC 对话），可以在 Lua 里调用 TXT 来处理。
callscript 的文件路径默认读取 Mir200\Envir\Market_def\ 文件夹下，如果有子文件夹，在文件名前加子文件夹路径（比如 "盟重 / 测试"）。这个路径规则要注意，不要写错路径导致找不到文件。
callact 是调用普通脚本 #act 命令（VV 独有），直接执行 TXT 脚本里的 #act 命令，比如 sendmsg、give、take 等。传玩家对象、命令名和最多 10 个参数。这个接口比 callscript 更轻量 ——callscript 是执行整个 TXT 标签（可能包含 #IF/#SAY/#ACT 等多段），callact 是只执行一条 #act 命令，开销更小。
callcheck 是调用普通脚本 #if 命令（VV 独有），执行 TXT 脚本里的 #if 条件判断，返回 bool 结果。比如 checklevel、checkitem、checkgold 等，在 Lua 里调用 callcheck 就能用 TXT 的条件判断，不需要自己重写。
callact 和 callcheck 这两个 VV 独有的接口，体现了 VV 引擎在 TXT/Lua 双轨制上的设计思路 ——不是让 Lua 完全替代 TXT，而是让两者可以互相调用，各取所长。TXT 的条件判断（#IF）和动作命令（#ACT）积累了很多年，功能完善，Lua 可以直接调用这些成熟的命令，不需要重新实现。Lua 擅长复杂逻辑和数据处理，TXT 擅长简单的条件和动作，两者配合效率最高。
getvisibleactor 是根据唯一 ID 获取视野内的目标对象，只能获取玩家视野内的目标（玩家 / 英雄 / 怪物 / 宠物 / 人形怪）。文档里注明 "用于解决 TXT 调用 LUA 时获取对象困难的问题"——TXT 脚本里拿到的是 userID 字符串，转到 Lua 里需要把 userID 转换成对象，getvisibleactor 就是做这个转换的。
这个接口的限制是 "只能获取视野内的目标"—— 如果目标不在玩家视野内，获取不到。这是因为引擎的对象管理是基于视野的，不在视野内的对象可能没有加载或者不可访问。做 TXT 转 Lua 的逻辑时要注意这个限制，如果需要获取视野外的对象，可能需要其他方式。
这五个接口的设计思路是：gotolabel 管批量触发，callscript/callact/callcheck 管 TXT/Lua 互调，getvisibleactor 管对象转换。它们共同构成了脚本之间的桥梁 —— 让 Lua 能调用 TXT、让 TXT 能传对象给 Lua、让一个玩家能触发一群人的脚本。
实际使用中的心得是：优先用 callact/callcheck，少用 callscript。文档明确说了 callscript 异步且消耗大，callact/callcheck 更轻量。如果只是执行一条动作命令或做一个条件判断，用 callact/callcheck；只有需要执行复杂的 TXT 标签逻辑（包含多段 #IF/#SAY/#ACT）时才用 callscript。
还有一个心得：gotolabel 的触发模式要选对。模式 2（当前地图）和模式 3（范围）容易混淆 —— 模式 2 是整张地图所有玩家，模式 3 是以玩家为中心指定范围内的玩家。如果只需要附近的玩家触发，用模式 3 指定范围，不要用模式 2 全地图触发，否则离得很远的玩家也会被触发，可能不合理。
七、UI 面板与新手引导：界面操作的三个接口
navigation、viewplayer、openwindows 这三个接口管的是游戏界面的操作 —— 新手引导箭头、查看别人面板、打开自己面板。
navigation 是新手界面引导功能，在指定界面的指定按钮上显示引导提示（通常是一个箭头加文字，告诉玩家 "点这里"）。传玩家对象、界面 ID、按钮索引、引导文字内容。
界面 ID 覆盖了主要的游戏界面：0=NPC 面板、1 = 背包道具、2 = 角色界面、3 = 英雄背包、7 = 背包面板、9-12 = 商城面板、40 = 英雄头像、200=PC 端下方 3 个按钮、201 = 右下角切换按钮、202 = 玩家主面板、203 = 英雄主面板，还有任务主窗口引导用任务的 ID。
按钮索引是每个界面自己定义的 ID，文档里举例说明：NPC 面板的按钮 ID 可以在 TXT 脚本里用<Text|id=221|...>定义，id=221 就是按钮 ID。背包道具界面的按钮索引是物品唯一 ID（MakeIndex），可以引导玩家点击某个特定物品。背包面板的按钮索引是按钮 ID，商城面板的是商城序号 ID，玩家 / 英雄主面板的是装备界面页签（1-6）。
navigation 的设计思路是：通过界面 ID + 按钮 ID 定位到具体的 UI 元素，在上面显示引导箭头和文字。做新手教程的时候，一步步引导玩家点击各个按钮 —— 第一步点 NPC 面板、第二步点背包里的某件物品、第三步点角色界面、第四步点技能按钮。每一步用 navigation 显示引导，玩家点击后进入下一步，形成完整的新手引导流程。
这个接口的参数设计很细致，不同界面的按钮索引含义不同（有的是按钮 ID、有的是物品 MakeIndex、有的是页签号），说明引擎对各个界面的引导都做了支持。新手引导是提升新玩家留存的关键功能，navigation 让这个功能的实现变得简单 —— 不需要自己做箭头 UI 和定位，引擎帮你搞定，你只需要告诉它在哪个界面的哪个按钮显示引导。
viewplayer 是查看别人面板信息，传玩家对象、目标玩家的 UserID、面板 ID（101 = 装备、106 = 称号、1011 = 时装）。这个接口实现的是 "查看其他玩家" 的功能 —— 玩家选中另一个玩家，选择 "查看装备"，就调用 viewplayer 打开对方的装备面板。支持查看装备、称号、时装三种面板，覆盖了玩家最常查看的内容。
openwindows 是查看自己面板，传玩家对象和面板 ID（101 = 装备、102 = 状态、103 = 属性、104 = 技能、105 = 生肖、106 = 称号、1011 = 时装）。这个接口是用脚本打开玩家自己的某个面板 —— 比如任务引导玩家 "打开角色界面查看属性"，就调用 openwindows (actor, 103) 自动打开属性面板，不需要玩家手动点按钮。
openwindows 支持的面板比 viewplayer 多 —— 自己的面板可以看状态、属性、技能、生肖，而查看别人只能看装备、称号、时装。这是合理的，因为别人的状态、属性、技能属于隐私，不应该随便查看。
这三个接口的设计思路是：navigation 管引导（告诉玩家点哪）、viewplayer 管查看他人（看别人有什么）、openwindows 管打开自己面板（自动打开界面）。三个接口覆盖了 UI 操作的主要场景，配合起来可以做完整的新手引导和界面交互。
实际使用中的心得是：navigation 的引导要配合玩家操作进度来控制显示和隐藏。文档里只说了怎么显示引导，没有说怎么隐藏 —— 可能引导在玩家点击对应按钮后自动消失，也可能需要再次调用 navigation 来隐藏。实际使用时要测试确认引导的消失机制，如果需要手动隐藏，要在玩家完成操作后调用对应的隐藏逻辑。
还有一个心得：viewplayer 需要目标玩家在附近或可访问。如果目标玩家离线或者不在视野内，可能查看失败。做查看他人功能时要加错误处理，查看失败时给玩家提示 "对方不在线或无法查看"。
八、辅助接口：setchatprefix、release_print、healthspellchanged
setchatprefix 是设置聊天前缀，给玩家的聊天消息加一个前缀（比如 "[VIP]"、"[GM]"、"[沙巴克]"），可以设置前缀的背景色。传空字符串则清除前缀。
这个接口的应用场景很多：VIP 玩家聊天带 VIP 前缀、GM 带 GM 前缀、沙巴克成员带 [沙] 前缀、活动第一名带 [冠军] 前缀。前缀是玩家身份和荣誉的展示，能激发玩家的攀比和竞争心理。前缀还可以动态变化 —— 比如玩家加入行会后加行会前缀、获得称号后加称号前缀、活动期间加活动前缀。
setchatprefix 的设计很简单 —— 一个前缀字符串加一个颜色，设置和清除都用同一个接口（空字符串清除）。这种 "设置即覆盖、空即清除" 的设计很简洁，不需要单独的删除接口。
release_print 是打印消息到控制台，传任意数量的参数，都会打印到控制台或日志文件。文档里说明：引擎开发模式输出到控制台，线上模式记录到 ScriptXX 文件里，可用于排查错误。
这个是脚本开发最基础的调试工具 —— 写脚本的时候到处加 release_print 打印变量值、执行流程、错误信息，调试完再删掉或注释掉。虽然简单，但离了它脚本调试会很痛苦。
release_print 支持任意数量的参数（文档里写的是数组内容，示例是 release_print ('aa','bb')），多个参数会拼接在一起打印。这比 Lua 原生的 print 更灵活，可以同时打印多个变量，不需要手动用.. 拼接。
实际使用中的心得是：线上模式的 release_print 会写日志文件，不要在高频逻辑里大量打印。比如每秒执行的定时器里如果有 release_print，日志文件会快速膨胀，占用磁盘空间还影响性能。调试时加的 release_print，上线前要清理掉，或者加开关控制（比如只有 GM 调用时才打印）。
healthspellchanged 是刷新血量 / 蓝量，传玩家或怪物对象，强制刷新客户端显示的血量和蓝量。当你通过脚本直接修改了对象的 HP/MP（比如用 setbaseinfo 改了血量），客户端可能不会自动刷新显示，这时候调用 healthspellchanged 强制同步一下，客户端就会显示最新的血蓝值。
这个接口虽然小，但很重要 —— 脚本改了血量如果不刷新，玩家看到的还是旧血量，会造成困惑（比如 "我明明加血了怎么血条没变"）。做血量相关的脚本逻辑（加血技能、扣血陷阱、血量变化 buff）时，改完血量记得调 healthspellchanged 刷新显示。
| 
