传奇发布站来路调查脚本编写配置与数据记录完整技术解析

玩家来源追踪在传奇运营中属于基础数据采集工作，核心目的是弄清楚每个玩家究竟从哪个发布站点的广告位点击进入游戏。不掌握这个数据，投放广告就只能凭感觉，钱花出去了却不知道哪个站的转化率高、哪个站的流量是刷出来的。来路调查的脚本实现主要分两种技术路线：一种是在游戏内用NPC对话让玩家主动选择来源站点，另一种是通过登录器读取自定义文本实现自动记录，不需要玩家手动操作。两种方案各有适用场景，下面把脚本结构、配置步骤和常见问题逐一拆解。

NPC对话式调查脚本的完整结构

这种方案的本质是在游戏内放置一个调查NPC，玩家首次上线或达到一定等级后与NPC对话，NPC弹出发布站列表供玩家选择，脚本根据玩家的选择把账号名写入对应的文本文件。整个过程不需要玩家输入文字，操作门槛低，参与率高。

脚本文件放在服务端的Market_Def目录下，文件名格式为“NPC名-地图号.txt”。例如调查NPC放在盟重省，地图号是3，文件名就写“发布站调查-3.txt”。文件内容的核心结构分三部分：主菜单、各发布站选项的处理段、以及防重复参与检测。

主菜单段使用[@main]标识，里面用<显示文字/@跳转标签>的格式列出所有发布站名称。比如要列出一组发布站，脚本写法如下：

```
[@main]
您好，欢迎进入本服。为了给大家带来更好的游戏体验，请选择您是通过哪个发布站了解本服的：
<站点A/@A> <站点B/@B> <站点C/@C>
```

每个发布站对应一个独立的处理段，标签名可以自定义。处理段内部用条件判断语句检测玩家是否已经参与过调查，如果已参与则弹出提示并终止，未参与则把玩家账号写入对应的文本文件，同时写入一个“已参与”记录防止重复投票。以站点A为例：

```
[@A]
#IF
checknamelist ..\QuestDiary\已参与调查.txt
#ACT
MESSAGEBOX 您已经参与过本调查，感谢支持。
BREAK
#ELSEACT
addnamelist ..\QuestDiary\站点A来源.txt
addnamelist ..\QuestDiary\已参与调查.txt
SENDMSG 0 感谢玩家〖[%s]〗参与了本服来源调查。
BREAK
```

这里用到三个关键命令。checknamelist用于检测玩家账号是否存在于指定文本文件中，如果存在就说明该玩家已经投过票。addnamelist用于把当前玩家的账号追加写入文本文件。SENDMSG 0是向全服发送公告，可以根据需要加或不加。

QuestDiary目录下需要预先创建两个文本文件。一个是“已参与调查.txt”，内容为空即可，脚本运行后会自动往里面写入参与过的账号。另一个是每个发布站对应的来源文件，比如“站点A来源.txt”“站点B来源.txt”，文件名和脚本中的路径必须完全一致。文件名中不要使用空格或特殊符号，避免脚本读取时出错。

防刷机制除了用“已参与调查.txt”做账号级别的限制，还可以在脚本中加入等级门槛。例如在主菜单之前加一层判断：

```
[@main]
#IF
CHECKLEVELEX < 30
#ACT
MESSAGEBOX 等级达到30级后才能参与来源调查。
BREAK
```

等级门槛的目的是过滤掉批量注册的小号，减少恶意刷票的可能性。门槛值设多少合适，取决于服务器的升级节奏。开区首日升级快的服可以设40级左右，慢节奏的复古服设20到25级就够了。

脚本写完后还需要在MerChant.txt中登记NPC。MerChant.txt位于Mir200\Envir目录下，每行记录一个NPC的配置信息，格式为“脚本名 地图号 坐标X 坐标Y NPC名称 朝向 外观编号”。脚本名要和Market_Def下创建的txt文件名去掉地图号后缀的部分一致。比如脚本文件叫“发布站调查-3.txt”，MerChant.txt中对应的脚本名就填“发布站调查”。登记完成后重新加载NPC配置或重启M2Server，NPC就会出现在指定位置。

登录器自定义文本自动记录方案

NPC对话调查的缺点是玩家可能乱选或者不选，数据准确度取决于玩家的配合程度。登录器自定义文本功能解决的就是这个问题，它不需要玩家做任何操作，登录器在启动时自动读取预先写入的文本内容，把这个内容作为常量传递给服务端脚本，服务端脚本根据这个常量判断玩家来源并写入对应的记录文件。

这个方案的实现依赖两个前提条件：登录器支持读取自定义文本文件，服务端有对应的插件支持读取登录器传递的常量。目前GOM引擎配合WXF插件、GEE引擎配合PG插件都可以实现这个功能。

以WXF插件为例，客户端集成步骤是在登录器的补丁文件夹Data目录下创建wxfzdywb.txt文件，文件内容格式如下：

```
[自定义文本]
自定义文本=9pk
```

等号后面的内容是发布站标识，每个发布站投放的登录器配置中这个值不同。比如投放在9pk发布站的登录器，等号后面写“9pk”；投放在jjj发布站的写“jjj”。玩家从哪个站下载登录器，登录器启动后就读取对应的标识值。

服务端这边需要在QuestDiary目录下创建“玩家来源.txt”文件，内容为各个发布站的初始计数：

```
[玩家来源]
9pk=0
jjj=0
```

然后在QF脚本的登录触发段中添加记录逻辑。WXF插件的触发字段名是[@WXF版本自定义标记文本]，脚本内容如下：

```
[@WXF版本自定义标记文本]
#ACT
WXFReadConfigFileItem ..\QuestDiary\玩家来源.txt 玩家来源 <$WXFCLIENTTEXT> N$数量
WXFDelConfigFileItem ..\QuestDiary\玩家来源.txt 玩家来源 <$WXFCLIENTTEXT> N$数量
inc N$数量 1
WXFWriteConfigFileItem ..\QuestDiary\玩家来源.txt 玩家来源 <$WXFCLIENTTEXT> N$数量
```

这四行命令的执行逻辑是：先从“玩家来源.txt”中读取当前来源标识对应的计数值存入变量N$数量，然后删除该条目，把变量值加1，最后把新值写回文件。整个操作实现了计数的原子递增，不会出现重复写入或数据丢失。

常量<$WXFCLIENTTEXT>的值就是登录器wxfzdywb.txt中等号后面的内容。如果登录器端写的是“9pk”，这个常量就是“9pk”；写的是“jjj”，常量就是“jjj”。服务端脚本不需要针对每个发布站单独写处理段，一套脚本自动匹配所有来源标识。

PG插件的实现方式类似，自定义文本文件名为zdywb.txt，放在登录器data目录下，触发字段为[@PG版本自定义标记文本]，对应常量为<$PGCLIENTTEXT>。脚本命令的名称和参数顺序与WXF插件不同，但核心逻辑一致，具体写法参考PG插件的命令文档。

这个方案的优势在于数据准确性高。玩家从哪个站点的登录器进入，系统就记录哪个站点，不需要玩家主动选择，也不存在乱选的问题。局限在于每个发布站都需要单独配置一份登录器，发布站数量多的时候管理成本会增加。另外登录器自定义文本可以被技术手段修改，如果遇到恶意刷量的情况，需要结合IP记录和登录时间做交叉验证。

网站端来路统计的辅助手段

游戏内的记录只能覆盖到已经进入游戏的玩家，那些点击了发布站链接但没有完成登录的访问者，需要网站端的统计代码来补充。发布站广告通常投放的是网页链接，在目标页面上添加来路统计代码，可以记录访问者的来源页面地址。

网页端获取来路的核心是HTTP_REFERER字段。当用户从发布站的广告位点击进入目标页面时，浏览器会在请求头中携带来源页面的URL。用ASP实现来路获取的代码示例：

```asp
<%
Dim referer
referer = Request.ServerVariables("HTTP_REFERER")
If referer <> "" Then
' 把referer写入数据库或文本文件
' 提取域名部分进行归类
Else
' 直接访问或来源被屏蔽
End If
%>
```

用PHP实现的代码示例：

```php
<?php
$referer = isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : '';
if ($referer) {
$domain = parse_url($referer, PHP_URL_HOST);
// 把$domain写入统计记录
}
?>
```

需要注意的是，HTTP_REFERER并不是100%可靠。用户直接输入网址或使用书签访问时，这个字段为空。浏览器隐私模式、部分安全插件、以及从HTTPS页面跳转到HTTP页面时，来源字段可能被屏蔽。因此网站端的统计结果只能作为参考，不能替代游戏内的登录器记录。

另一种网站端的做法是在发布站的广告链接上附加来源参数。比如广告位链接写成`http://你的域名/index.html?from=9pk`，目标页面的脚本读取from参数并记录。这种方式的准确性取决于发布站是否允许在广告链接中自定义参数，部分发布站会拒绝带参数的链接或者自动剥离参数。

数据记录后的分析要点

不管用哪种方式记录，数据采集只是第一步，关键在后续分析。至少需要关注三个维度。

来源站点的注册转化率。记录每个发布站带来的玩家数量是一方面，更重要的是这些玩家中有多少人完成了注册并进入了游戏。有些发布站的点击量很高，但转化率极低，说明流量质量差或者广告位位置不明显。计算方式是：某站点记录的进入游戏玩家数除以该站点的广告点击量（如果能拿到的话），或者直接对比各站点之间的绝对注册数。

来源站点的留存率。把来源数据和角色数据关联起来，查看不同站点进来的玩家在3天、7天后的在线情况。有些站点的玩家进来后很快就流失了，有些站点的玩家留存情况明显更好。留存数据才是判断一个发布站是否值得继续投放的核心依据。

异常数据排查。如果某个发布站在短时间内记录了远超正常水平的玩家数量，而对应的角色创建数和在线时长都很低，大概率存在刷量行为。排查方法是查看该来源标识下的账号名称规律，批量注册的账号通常有连续的数字编号或相似的命名模式。同时对比这些账号的首次登录IP，如果大量账号来自同一C段IP，基本可以确认是刷量。

脚本编写中的常见错误

来源调查脚本在编写和运行中最常遇到的问题有几类。

路径写错是最低级的错误，但出现频率很高。QuestDiary目录的引用路径在不同引擎中的写法有差异，有的引擎用相对路径`..\QuestDiary\`，有的用绝对路径。写脚本时先确认当前引擎的路径规范，路径写错了脚本不会报错，但文本文件不会被创建，记录功能完全失效。

变量名和文件名的匹配问题。NPC对话方案中，每个发布站的来源文件名必须和脚本中引用的文件名完全一致，包括大小写。Windows系统对文件名大小写不敏感，但在服务端运行时，脚本引擎的字符串比对是区分大小写的，文件名一个字母不一致就会写入失败。

防重复逻辑的遗漏。如果忘记在脚本中加入“已参与调查.txt”的检测，同一个玩家可以反复点击不同的发布站选项，导致数据严重失真。检测命令的写法要注意，checknamelist检测的是文件中是否存在该玩家的账号，而addnamelist写入的是当前玩家的账号。两个命令的参数路径必须指向同一个文件才能实现防重复。

登录器自定义文本的编码问题。wxfzdywb.txt或zdywb.txt文件的编码格式建议保存为ANSI，不要用UTF-8带BOM的格式。部分登录器读取BOM开头的文件时会把BOM字符当作内容的一部分，导致常量值前面多出乱码，服务端脚本匹配失败。

多渠道来源识别的扩展写法

基础方案只记录玩家从哪个发布站进入，但实际运营中可能需要记录更细粒度的来源信息，比如同一个发布站的不同广告位、不同的推广活动渠道。扩展方法是在登录器的自定义文本中写入更长的标识字符串，服务端脚本用字符串截取命令拆解标识的不同部分。

比如标识格式设计为“站点名-广告位编号-推广批次”，登录器文本中写`9pk-A-0425`，服务端脚本先用字符串查找命令定位第一个“-”的位置，截取前面的站点名用于站点级别的记录，再定位第二个“-”的位置，截取中间部分用于广告位级别的记录。GOM脚本中可以用GetStringPos命令获取指定字符在字符串中的位置，用GetStringSub命令截取子串。

这种扩展写法的好处是一份登录器可以覆盖多个投放渠道，只需在生成登录器时修改自定义文本的内容，不需要为每个渠道单独配置脚本。缺点是脚本逻辑变复杂了，调试时需要确保每个截取步骤的边界条件都正确处理，尤其是当标识字符串格式不规范时（比如缺少“-”分隔符），脚本要有容错处理，不能因为格式错误导致记录写入失败。

数据文件的并发写入处理

当服务器在线人数较高时，多个玩家同时触发来源记录写入操作，可能出现文件读写冲突。addnamelist命令在写入文本文件时如果文件被其他进程占用，写入会失败且不产生错误提示，导致部分玩家的来源数据丢失。

缓解这个问题可以从两个层面入手。服务端层面，把来源记录文件的存储位置放在读写性能较好的SSD分区上，减少文件锁定时间。脚本层面，如果引擎支持，使用队列机制把写入操作延迟到服务器负载较低的时段批量执行。具体的实现方式是用一个内存变量暂存待写入的数据，通过定时器脚本每隔一定时间把累积的数据一次性写入文件，而不是每次触发都立即写。

对于使用数据库而非文本文件存储来源数据的服务端，并发问题会小很多。把来源记录写入数据库表，利用数据库的事务机制保证写入的完整性，是更可靠的方案，但需要对服务端脚本和数据库结构进行相应的改造，技术门槛比纯文本方案高一些。

来路调查的数据只有和后续的玩家行为数据关联起来才有实际价值。单独看“某个发布站来了多少人”意义有限，把来源标识和账号、角色名、首次登录时间、累计在线时长、充值金额这些字段关联在一张表中，才能做出有效的渠道质量评估。技术实现上，可以在玩家创建角色时把登录器传递的来源标识写入角色数据表的扩展字段，后续的所有行为记录都带上这个来源标识，分析时按标识分组统计即可。