远程传奇NPC脚本控制器RemoteNPC部署与RemoteScript插件配置详解

远程NPC脚本控制器在传奇服务端架设中主要解决两个问题：脚本防泄露和跨机管理。把脚本从M2服务器上剥离出来，放在另一台机器上，即使服务端文件流出，没有脚本源文件，版本也无法正常运行。目前主流实现方式有两种：独立的RemoteNPC.exe控制器方案，以及依赖引擎插件RemoteScript.dll的方案。两者的配置逻辑不同，适用场景也有差异。下面把两套方案的完整部署流程、参数含义和常见故障逐一拆解。

RemoteNPC.exe独立控制器方案的核心概念是两台机器分工。放置RemoteNPC.exe的机器称为A机，也就是脚本托管服务器；运行M2Server的机器称为B机，也就是游戏服务端所在机器。B机上的脚本文件被清空或删除，只保留一个指向远程的标记，M2启动时通过TCP连接从A机拉取脚本内容。A机不运行任何传奇服务端程序，只运行RemoteNPC.exe这一个轻量级程序，资源占用很低。

配置从B机的!Setup.txt文件开始。这个文件位于MirServer\Mir200目录下，记录了服务端的全局参数。在文件中找到[RemoteNPC]段，如果不存在就手动在文件末尾添加。这个段下面需要写两项内容：Port和IP。Port填A机开放的端口，默认值是6500；IP填A机的实际网络地址。有一个验证配置是否被M2正确读取的方法：先在Port和IP里随便填一个明显无效的值，比如端口写成59999，IP写成10.0.0.99，然后启动M2。如果M2控制台输出“无法连接到远程NPC服务器。你可能正在使用非法版本”这类提示，说明M2已经识别到了[RemoteNPC]配置并尝试发起连接，配置的读取环节没有问题。反过来如果启动M2完全没有这个提示，说明[RemoteNPC]段没有生效，检查段名拼写和文件编码，!Setup.txt必须保存为ANSI格式。

确认M2能读取配置之后，把!Setup.txt中的IP和端口改回A机的真实值，但先不要启动M2。接下来处理A机。在A机上创建一个文件夹用于存放远程脚本，文件夹名称可以自定义，比如叫“远程脚本”。把RemoteNPC.exe程序放进这个文件夹里。然后在同一目录下新建一个文本文件，文件名必须是UserIPList.txt，这是A机的白名单文件。打开UserIPList.txt，把B机的IP地址写进去，每行一个IP。如果B机有多个IP或者存在多个B机同时连接同一个A机的情况，逐行列出即可。A机的RemoteNPC.exe在启动时会读取UserIPList.txt，只有列表中的IP发来的连接请求才会被接受，不在列表中的连接直接被拒绝。这个机制防止了其他机器随意连上A机的脚本服务。

完成UserIPList.txt的填写后，双击运行RemoteNPC.exe。程序界面通常很简洁，只有一个“开启远程服务”的按钮。点击按钮，如果端口6500没有被其他程序占用，状态栏会显示“已启动”。如果显示端口冲突，说明6500端口被占用，需要关闭占用该端口的程序，或者在RemoteNPC.exe中修改监听端口，同时把B机!Setup.txt中的Port值改成相同的数字。端口冲突的排查可以用命令行工具，在命令提示符中执行netstat -ano，查看6500端口对应的进程PID，再到任务管理器中结束那个进程。

A机的服务正常启动后，回到B机启动M2Server。这次启动时不应该再出现“无法连接到远程NPC服务器”的提示，因为连接已经成功建立。此时可以在RemoteNPC.exe的界面上看到B机的连接状态。接下来处理脚本文件本身。

以QFunction-0.txt这个使用频率最高的功能脚本为例。先在B机上备份原始的QFunction-0.txt，然后把原始文件复制到A机上RemoteNPC.exe所在的目录中。复制完成后，回到B机，把Mir200目录下的QFunction-0.txt内容全部清空，只写入一行文字：#Remote。这一行标记告诉M2，这个脚本文件的内容不在本地，需要从远程控制器读取。保存文件后重新加载NPC或重启M2，M2会向A机发起请求，A机的RemoteNPC.exe把A机目录下同名的QFunction-0.txt内容发送给B机。发送成功后RemoteNPC.exe界面上会显示发送记录。

这里有一条必须遵守的规则：A机和B机上的脚本文件名必须完全一致。B机本地文件叫QFunction-0.txt，A机上的文件也必须叫QFunction-0.txt，大小写和扩展名都不能有差异。如果A机上的文件名写成了QFunction-0.TXT或者QFunction0.txt，M2请求时匹配不到对应文件，脚本加载会失败，但M2可能不会报出明确的错误提示，表现为NPC功能失效或部分脚本不执行。

其他NPC脚本的远程化处理方式与QFunction-0.txt相同。Market_Def目录下的各个NPC脚本文件，把源文件复制到A机，B机本地文件清空后写入#Remote即可。可以只把核心的、需要加密的脚本放到远程，辅助性的、公开的脚本保留在B机本地，两种方式混用不会冲突。

RemoteScript插件方案适用于GOM、BLUE和GEE引擎。这个方案不依赖独立的RemoteNPC.exe，而是通过引擎插件在M2层面实现远程脚本加载。部署方式与独立控制器方案有本质区别。

在M2服务器上，把RemoteScript.dll放入MirServer\Mir200目录，与M2Server.exe放在一起。然后在Mir200\PlugList.txt文件中加入RemoteScript.dll这一行，告诉引擎启动时加载这个插件。同目录下创建RemoteScript.ini配置文件，文件内容包含几个关键参数：Host填远程脚本服务器的IP地址，Port填远程脚本服务器的监听端口，默认8800；UserName和Password是连接远程服务器的凭据，默认用户名是default，默认密码是bluem2，部署时应当修改为复杂密码；ServerVersion填远程读取的版本名称，比如热血传奇_V1.0。配置完成后启动M2，在引擎主菜单的管理菜单中找到“使用远程脚本”选项并勾选。勾选后重新加载所有NPC或重启引擎，M2会从RemoteScript.ini中配置的远程地址拉取脚本数据。

远程脚本服务器端需要单独部署一个RemoteScriptServer程序。这个程序可以运行在另一台机器上，也可以和M2运行在同一台机器但使用不同端口。服务端的config.conf文件中配置监听端口、连接密码和允许上传/下载的用户列表。启动.bat运行服务端程序后，M2端的RemoteScript插件就可以与之通信。

RemoteScript方案有一个独立控制器方案不具备的功能：脚本上传。在M2端修改完脚本后，可以通过引擎主菜单的管理菜单中的“上传脚本数据”功能，把本地修改后的脚本推送到远程服务器。上传操作需要验证UploadAuthCode，这个授权码需要向引擎提供方获取，填写在!Setup.txt的[server]段下，格式为UploadAuthCode后面跟一串十六进制字符串。没有正确的授权码，上传操作会被远程服务器拒绝。上传功能的实际用途是：在测试服上修改和调试脚本，调试完成后一键上传到远程脚本服务器，所有连接同一远程服务器的正式服只需要重新加载NPC即可获取最新脚本，不需要逐个服务器手动更新文件。

RemoteScriptFilters.txt是RemoteScript插件的一个过滤配置文件。通过这个文件可以控制哪些NPC脚本使用远程加载，哪些使用本地加载。RemoteScript.ini中的BlacklistMode参数决定过滤模式：设为true时是黑名单模式，列表中列出的NPC使用本地加载，不在列表中的使用远程加载；设为false时是白名单模式，列表中列出的NPC使用远程加载，不在列表中的使用本地加载。列表条目的格式是“NPC基本目录_NPC名称-地图号”，比如Market_Def_武器店-3。这个机制在多版本共用一个远程脚本服务器时很有用，不同版本可以只远程加载各自需要的脚本子集，不需要把全部脚本都推送到远程。

两种方案的故障排查重点不同。RemoteNPC.exe方案最常见的故障是连接建立后脚本不生效，原因通常是A机和B机的文件名不一致，或者B机本地文件中的#Remote标记被其他内容覆盖。另一个高频问题是A机防火墙拦截了6500端口的入站连接，B机M2始终提示无法连接。排查时先在B机上用telnet命令测试A机的6500端口是否可达，如果telnet不通，检查A机防火墙的入站规则和云服务器安全组设置。RemoteScript插件方案的常见问题是引擎卡顿，原因是远程脚本服务器和M2之间的网络延迟过高，M2每次加载NPC都要等待远程响应。缓解方法是把远程脚本服务器部署在与M2同一内网或延迟较低的节点上，同时利用RemoteScriptFilters.txt把非核心NPC的加载方式改回本地，减少远程请求的数量。

脚本文件中的变量文件不支持远程加载。比如QuestDiary目录下用于存储玩家名称的名单文件和用于保存自定义变量的文本文件，这些文件的内容不是脚本命令，而是运行时产生的数据，远程控制器无法正确处理这类文件的动态读写。这类文件必须保留在B机本地，不能做远程化处理。判断依据很简单：文件内容以#IF、#ACT、#SAY等脚本命令为主的是脚本文件，可以远程；文件内容是玩家名字列表、变量键值对、日志记录的是数据文件，不能远程。