冒险岛NPC脚本实战：sendYesNo与warp的20种用法及排坑指南

我最早写冒险岛脚本的时候，就死磕两个函数——cm.sendYesNo和cm.warp。为什么？因为一个负责跟玩家对话，一个负责把玩家送走，80%的NPC交互都绕不开这两兄弟。光一个传送员NPC，可能同时要接任务、扣钱、验等级、送副本、拉队伍，全都靠这两个函数撑起来。很多刚接触服务端脚本的朋友，一上来就看函数列表，结果发现各种cm.xxx看得眼花缭乱，但真正动手写第一个NPC对话时，卡得最狠的往往就是这两个：弹窗怎么弹、选择之后怎么判断、人怎么传、传过去落在哪、传送之后脚本还跑不跑。

这篇文章我就拿这两个函数的实战用法开刀，结合这些年改脚本、写任务、调传送点的经验，整理20个可以直接抄作业的写法，再加上我实际踩过的坑和排查思路。不管你是跑079单机端、怀旧服自定义端，还是想自己做一套任务系统，这篇文章都适合。内容不涉及客户端辅助和外挂，纯服务端脚本开发，可以放心看。

1. 动手之前，先弄清cm这个对象到底从哪来

很多新人写脚本失败，不是因为函数用错了，而是根本不知道这段代码运行在什么环境里。cm说白了一句话：它是当前NPC脚本的上下文操作对象。服务端把说话的这个NPC、跟NPC对话的玩家、当前地图、玩家身上的数据全部打包成一个cm交给你，脚本里所有操作都通过它来做。

1.1 一条脚本从加载到执行的生命周期

在常见的各类移植端里，NPC脚本文件命名一般是脚本ID.js，放在scripts/npc目录下。玩家点击NPC时，服务端加载对应脚本，然后调用脚本里的start()函数。你的代码从start()开始执行，执行完并不代表结束——如果有回调用法，比如cm.sendYesNo里传了一个匿名函数，那这个回调会等玩家点击“是”或“否”之后再触发。这是理解所有对话脚本的关键：脚本不是从上到下一次性跑完，而是被回调切成了一段一段的状态机。

拿一个最典型的接任务NPC举例：

function start() { cm.sendYesNo("你想接受这个任务吗？", function(sel) { if (sel == 1) { // 玩家点了“是”，这里才真正执行任务分配逻辑 } }); }

这段代码执行顺序是：先弹窗，玩家点按钮，然后回调才执行。如果你在sendYesNo之后立刻写cm.gainItem之类的发奖代码，那结果一定是玩家还没点确认，奖励已经发出去了。

1.2 sendYesNo和warp的参数签名差异

不同版本的服务端，这两个函数的签名略有差异，但主流写法通常是：

cm.sendYesNo(text, callback); // text：显示在对话框里的内容 // callback：玩家选择后触发的函数，接收一个参数，1代表“是”，0代表“否” cm.warp(mapId); cm.warp(mapId, portalName); cm.warp(mapId, x, y); // 部分端支持直接传坐标

warp的返回值没什么用，关键是它执行后玩家会立刻切换地图。大部分端在切换地图时会中止当前NPC对话，所以不要指望warp之后还能用cm给玩家发消息。这一点后面会展开讲。

2. cm.sendYesNo的10个实战写法：从确认弹窗到多分支任务

sendYesNo就是一个带“是/否”两个按钮的弹窗。很多新手觉得它简单，但这种按钮在不同场景下代表了完全不同的业务逻辑。我把它最常见的10种用法拆开讲。

2.1 任务接取确认，附带前置条件校验

这是最基础的用法。接任务前先检查等级和职业，不满足条件就别弹窗。好处是省得玩家白点一次确认。

function start() { var player = cm.getPlayer(); if (player.getLevel() < 20) { cm.sendOk("等级不够，20级再来吧。"); return; } cm.sendYesNo("我有个差事想交给你，报酬丰厚，愿意接吗？", function(sel) { if (sel == 1) { cm.gainItem(4001001, 1); // 给任务道具，示例 cm.sendOk("道具已经给你了，出发吧。"); } }); }

2.2 金币扣费二次确认，防止误触传送

做传送员NPC时，最怕玩家手滑点错，传进一个高费地图。先弹窗确认金额，再扣钱传送，体验会好很多。

function start() { cm.sendYesNo("前往#b废弃都市#k，需要支付#r500金币#k。是否继续？", function(sel) { if (sel == 1) { if (cm.getPlayer().getMeso() >= 500) { cm.gainMeso(-500); cm.warp(103000000, 0); } else { cm.sendOk("金币不够啊，先去赚点钱吧。"); } } }); }

注意顺序：先扣钱，再warp。反过来容易出现扣款失败但人已经传走的问题。如果你用的端gainMeso带返回值，最好校验一下扣款是否成功。

2.3 限时活动进入确认，判断时间段

活动NPC通常只在特定时间段开放，用sendYesNo做一道门，可以避免玩家在非活动时间传进去面对一个空地图。

function start() { var hour = new Date().getHours(); if (hour >= 10 && hour <= 12) { cm.sendYesNo("活动副本现在开放，进入后会限时30分钟，确定进入吗？", function(sel) { if (sel == 1) cm.warp(910000000, 0); }); } else { cm.sendOk("活动还没开始，开放时间是每天10:00-12:00。"); } }

2.4 商店购买前置判断，背包满时不弹窗

卖消耗品的商人如果只管弹窗，玩家背包满了就会出现“道具发放失败”的尴尬。前置判断背包空格数量是很有必要的。

function start() { var emptySlots = cm.getPlayer().getInventory(1).getNumFreeSlot(); // 背包1是消耗栏，各端可能不同 if (emptySlots < 5) { cm.sendOk("背包快满了，先清一清再来买吧。"); return; } cm.sendYesNo("购买10个蓝色药水，花费2000金币，确定吗？", function(sel) { if (sel == 1) { cm.gainItem(2000001, 10); cm.gainMeso(-2000); } }); }

2.5 职业选择型NPC：嵌套回调做分支

有些一键转职NPC会让你先确认，再选职业。嵌套回调用起来并不复杂，但要注意每一层回调里都要正确判断参数。

function start() { cm.sendYesNo("你想进行职业转换吗？", function(sel) { if (sel == 1) { cm.sendSimple("请选择职业：#b\r\n#L0#战士#l\r\n#L1#法师#l", function(choice) { if (choice == 0) { cm.giveJobId(100); // 示例职业ID } else if (choice == 1) { cm.giveJobId(200); } }); } }); }

2.6 物品消耗型传送：用道具当门票

这种玩法在活动地图里很常见。玩家消耗指定道具才能进入，防止刷图。

function start() { if (!cm.haveItem(4031000, 1)) { cm.sendOk("需要一张#b入场券#k才能进入。"); return; } cm.sendYesNo("消耗入场券进入怪物公园，确定吗？", function(sel) { if (sel == 1) { cm.gainItem(4031000, -1); cm.warp(951000000, 0); } }); }

2.7 重置技能/属性点前的强确认

重置操作不可逆，玩家的后悔成本很高。这种地方弹窗文案必须写清楚，而且最好在回调里再给一次提示。

function start() { cm.sendYesNo("重置所有技能点需要花费100万金币，且不可撤销。确定要继续吗？", function(sel) { if (sel == 1) { if (cm.getPlayer().getMeso() >= 1000000) { cm.gainMeso(-1000000); // 调用各自的技能重置接口 cm.sendOk("技能点已重置。"); } else { cm.sendOk("金币不足。"); } } }); }

2.8 任务完成提交确认，校验任务进度

很多任务NPC在玩家未达到条件时弹"是/否"没有任何意义。更合理的做法是先行校验再弹确认。

function start() { if (cm.getQuestStatus(10001) != 2) { // 2通常表示任务进行中 cm.sendOk("你还没有接到这个任务。"); return; } if (!cm.haveItem(4031500, 1)) { cm.sendOk("你还没有拿到任务道具呢。"); return; } cm.sendYesNo("确定提交任务材料吗？", function(sel) { if (sel == 1) { cm.gainItem(4031500, -1); cm.gainExp(5000); cm.gainMeso(30000); // 给任务道具后的完成状态切换，不同端接口不一样 cm.sendOk("任务完成！"); } }); }

2.9 组队副本的离场确认

玩家在副本里点NPC出去，如果不确认，手滑就要重跑整张图。这种场景的确认文案要带地图名称。

function start() { cm.sendYesNo("确定离开当前副本吗？退出后需要重新进入。", function(sel) { if (sel == 1) cm.warp(100000000, 0); }); }

2.10 危险区域进入警告

高级地图、PK地图、死亡掉落地图，进入之前给个警告弹窗，能避免很多误传投诉。

function start() { cm.sendYesNo("#r警告#k：前方是高等级危险区域，死亡后经验损失惨重。仍然进入吗？", function(sel) { if (sel == 1) cm.warp(105040300, 0); }); }

3. cm.warp的10种实战写法：传送点、随机落点和队伍拉人

cm.warp的核心参数是地图ID和落点。地图ID是Map.wz里定义好的，落点可以用两种方式：传portal名字，或者传x/y坐标。下面是10个我实际用过、并且觉得值得记录的写法。

3.1 固定坐标传送：warp(mapId, portalName)的正确用法

服务端地图里每个传送点都有自己的门名，比如sp、out00、in00。如果你确定落点，直接传portal名是最稳妥的。

function start() { cm.sendYesNo("去自由市场吗？", function(sel) { if (sel == 1) cm.warp(910000000, "out00"); }); }

3.2 返程落点：传回上一个地图

部分端支持通过变量记录玩家上一张地图。如果接口支持，可以参考这种写法，做一个“回城卷”NPC。

function start() { var prevMap = cm.getPlayer().getPreviousMapId(); if (prevMap > 0) { cm.warp(prevMap, 0); } else { cm.sendOk("找不到上一个地图记录。"); } }

3.3 随机落点传送：Math.random配合地图边界

打boss、捉迷藏活动、随机闯关玩法里，玩家每次传送都应该落在不同位置。只要知道地图的x/y边界，随机落点就很容易实现。

function start() { var minX = -500, maxX = 500; var minY = 50, maxY = 200; var randX = Math.floor(Math.random() * (maxX - minX + 1)) + minX; var randY = Math.floor(Math.random() * (maxY - minY + 1)) + minY; cm.warp(910000000, randX, randY); // 是否支持坐标重载，取决于你的端 }

3.4 队伍全员传送：一个NPC把整队拖进副本

组队任务里，队长进图，全队应该一起进。有些端提供warpParty，有些端没有，那就只能遍历队伍成员逐个传。

function start() { var party = cm.getPlayer().getParty(); if (party == null) { cm.sendOk("请先组队再来。"); return; } var members = party.getMembers(); for (var i = 0; i < members.size(); i++) { var chr = members.get(i).getPlayer(); if (chr != null && chr.getMap() != null) { chr.changeMap(910000000, 0); // 某些端需要这样强制拉人 } } }

3.5 按等级分流：低级和高级玩家传到不同地图

适合做练级指引NPC，不同等级区间推荐不同练级地图。

function start() { var level = cm.getPlayer().getLevel(); var mapId = 100000000; if (level < 30) { mapId = 101000000; } else if (level < 60) { mapId = 105040300; } else { mapId = 230000000; } cm.sendYesNo("根据你的等级，建议去#b" + mapId + "#k对应的练级地图，出发吗？", function(sel) { if (sel == 1) cm.warp(mapId, 0); }); }

3.6 多目的地菜单传送：sendSimple和warp的黄金搭档

这是最常用的一种传送NPC写法，所有目的地都放在一个列表里，玩家选择后直接传。

function start() { cm.sendSimple("你想去哪里？#b\r\n#L0#弓箭手村#l\r\n#L1#魔法密林#l\r\n#L2#废弃都市#l", function(choice) { var maps = [100000000, 101000000, 103000000]; if (choice >= 0 && choice < maps.length) { cm.warp(maps[choice], 0); } }); }

3.7 跨频道传送

某些端里地图是分频道的，warp默认在当前频道，想切频道要看端提供的changeChannel接口。这里给一种通用的思路。

function start() { cm.getPlayer().changeChannel(1); // 示例，切到1频 setTimeout(function() { cm.warp(910000000, 0); }, 500); }

3.8 副本出口传送：进入和退出成对维护

这个没什么高明的地方，但很能体现脚本的规范性。入口和出口的落点要反复测试，尤其是入口传错坐标导致卡墙，非常影响体验。

function start() { cm.warp(922000000, "enterToZeno"); // 入口脚本里写清楚portal名 } // 在出口NPC脚本里 function leave() { cm.warp(100000000, "out00"); }

3.9 通过指令触发传送

很多端支持把玩家的指令转发到脚本层。比如@npc指令调用某个脚本ID，然后执行warp，适合做管理员快速移动。

function start() { var mapId = parseInt(cm.getPlayer().getCommandArg()); if (!isNaN(mapId)) { cm.warp(mapId, 0); } else { cm.sendOk("请输入正确的地图ID，如 @go 910000000"); } }

3.10 任务链传送：完成一步传下一步

任务NPC不仅负责接任务，还要在玩家完成任务后把他导向下一张地图。

function start() { if (cm.getQuestStatus(10010) == 2) { // 进行中 cm.sendYesNo("你已经拿到了核心情报，现在回去报告吧。", function(sel) { if (sel == 1) cm.warp(104000000, 0); }); } }

4. 踩坑实录：这两个函数上最常见的5个问题

实用用法列了20个，但真正让脚本“看起来没问题却不好用”的，反而是几个坑。我把排查链路写出来，你以后再遇到不会慌。

4.1 坑点一：回调里分支判断用了字符串

sendYesNo回调里的sel，在绝大多数端里是整型。有人写习惯了字符串，判断写成sel == "1"，JavaScript宽松模式偶尔也能过，但一旦端换成了严格模式，或者服务端用Java的Nashorn解析，类型不匹配就直接不执行。

我的排查习惯：一看到回调没反应，第一件事就在回调入口打印一下typeof sel和sel的值。

function start() { cm.sendYesNo("测试弹窗", function(sel) { console.log("sel类型：" + typeof sel); console.log("sel值：" + sel); if (sel === 1) { // 推荐使用全等 } }); }

4.2 坑点二：sendYesNo之后立刻执行逻辑

这个坑我前面提到过，但必须单独再强调一次。很多人写：

cm.sendYesNo("确认传送？", function(sel) {}); cm.warp(910000000, 0);

然后发现玩家还没点确认就被传走了。原因就是sendYesNo只负责弹窗，它不会阻塞后续代码。正确的逻辑必须把所有后续操作放进回调里。

4.3 坑点三：warp之后原地图的cm失效

warp执行后，玩家已经离开当前地图。如果你后面还想用cm.sendOk给玩家发提示，很多端会直接报空指针或者静默失败。这是因为cm绑定的是执行脚本时的玩家和地图快照，切换后上下文已失效。

我的建议是：warp之前把该弹的消息、该扣的东西全做完。如果一定要在传完之后说话，就用发送系统消息之类的广播接口，不要依赖当前NPC的cm。

4.4 坑点四：坐标超出地图边界，人物卡墙

warp(mapId, x, y)虽然好用，但地图边界不是你想当然的。尤其是一些改图后的自定义地图，坐标范围跟原版MapleStory编辑器的格子不完全一致，硬传超界坐标，玩家就卡在墙壁里。

排查手段：先在服务端日志里把地图的出生点、边界坐标打出来。或者更简单，先用portal名测试，确认没问题再改成坐标。

4.5 坑点五：NPC脚本加载失败却没报错

很多端的脚本引擎默认静默吞异常。你写的文件有语法错误，它不会闪红字，只是NPC点了没反应。这种情况下我一般按以下顺序排查：

1. 检查文件名和路径，必须和NPC的脚本ID匹配。
2. 检查脚本是否以function start() {}开头，有些端还要求有function action()。
3. 在start()第一行加console.log("script loaded")，看服务端控制台有没有输出。
4. 如果没有输出，说明脚本根本没被加载，问题在文件路径或ID。
5. 如果没有报语法错误但有输出，说明代码在运行时抛了异常，这时候把回调里的逻辑拆开，逐步打印定位。

这个排查链路我反复用了很多次，基本能解决90%的“NPC点了没反应”问题。

5. 20个用法之外，这组配套函数才让你的脚本真正好用

光会sendYesNo和warp，脚本能跑，但不好维护。我自己的脚本里，经常拿它们和另外几个cm方法组合，日常写任务和传送员非常顺手。

5.1 sendSimple多选菜单和warp联动：一个传送员管20张图

sendSimple本质上是带滚动列表的弹窗，配合一个配置数组，能把传送NPC做成一张可维护的菜单表。这里的关键是把映射关系写清楚，避免后期加地图时改乱。

var destinations = [ { name: "弓箭手村", map: 100000000, fee: 100 }, { name: "魔法密林", map: 101000000, fee: 100 }, { name: "废弃都市", map: 103000000, fee: 100 }, ]; function start() { var text = "请选择目的地：#b"; for (var i = 0; i < destinations.length; i++) { text += "\r\n#L" + i + "#" + destinations[i].name + "#l"; } cm.sendSimple(text, function(choice) { if (choice >= 0 && choice < destinations.length) { var dest = destinations[choice]; if (cm.getPlayer().getMeso() < dest.fee) { cm.sendOk("金币不足。"); return; } cm.gainMeso(-dest.fee); cm.warp(dest.map, 0); } }); }

5.2 状态判断函数：等级、职业、物品校验

我习惯把校验逻辑封装成独立函数，这样不管是sendYesNo还是sendSimple里都能复用。脚本文件里可以定义额外函数，只要脚本引擎允许在文件顶层写函数就行。

function checkPlayer(player, minLevel, maxLevel, itemId) { if (player.getLevel() < minLevel) return "等级不足"; if (maxLevel > 0 && player.getLevel() > maxLevel) return "等级超出"; if (itemId > 0 && !cm.haveItem(itemId, 1)) return "缺少道具"; return null; }

5.3 giveItem奖励发放与任务闭环

任务闭环是sendYesNo最常打交道的场景。我记得的一个实用细节是：发放奖励前先判断背包空格，然后用cm.gainItem发放，再更新任务状态。顺序不能反，否则可能出现道具没空间但任务状态已完成的尴尬局面。

function start() { var player = cm.getPlayer(); if (player.getInventory(1).getNumFreeSlot() < 1) { cm.sendOk("背包至少留一个空格。"); return; } cm.gainItem(2000002, 50); cm.gainExp(10000); // 最后推进任务 }

5.4 脚本组织：配置化写法提升维护性

我以前写任务脚本喜欢把所有数据和逻辑都塞在start()里，后来改到怀疑人生。现在我的做法是：每个NPC脚本头部放配置，中部放校验辅助函数，最后才放start。传送员脚本尤其适合配表化。

var CONFIG = { fee: 100, allowedMaps: [100000000, 101000000, 103000000], defaultMap: 100000000 };

这样做的好处是明显：后期加地图、改费用，只动上面那几行，不需要往下翻逻辑。

5.5 本地联调的测试速查

最后给一套我每次写完NPC脚本都要走的测试流程，保证放上生产环境之前问题最少：

1. 在本地开一个测试号，用GM指令或数据库工具设好等级、金币、职业。
2. 把目标NPC的脚本文件改好，刷新服务端脚本缓存。
3. 点击NPC，测试所有入口分支：等级不够、金币不够、道具缺失、背包满、正常通过。
4. 每个分支确认后，再测试一次取消按钮返回的上一步行为。
5. 确认warp落点没有卡墙，尤其是坐标传送和随机落点。

这套流程前前后后花不了10分钟，但能挡住大部分线上问题。我自己吃过亏之后，已经养成了条件反射：改完脚本不测完不敢往外放。

说实话，cm.sendYesNo和cm.warp这两个函数单独看都很简单，但它们组合起来能覆盖任务、传送、商店、活动、组队等绝大多数NPC玩法。你把这20个用法吃透，再配合我提到的排查链路，日常改脚本、写新NPC基本不会再被卡住。剩下的，就是多在你的端里试，不同服务端对函数的签名和支持度有差异，最终以你那个端的源码定义为准。