自动全解迷机器人 (上)

[dragonstrike]

如何利用数据库制作全自动解谜机器人
作者：八级风（转自：西游奇旅）


这篇东东献给所有热爱XYJ，热爱Mudfan的朋友。

第一章 制作全自动解谜机器人的途径

在XYJ里，如何快速增长道行，是一个困扰许多玩家的大问题，
PK、NK、打花、解谜……PK要甘冒天下之大不韪；NK到了后期很难找到合适的NPC对象；
打花的确是个好方法，我曾经8小时打了430多年，不过很多站点被cut了，
:(。只有解迷，成了一个最可靠的方法。无论去哪个站点，
只要能熟练掌握解谜方法和技巧，都能较快的成长。
然而，解谜的繁琐和辛苦程度令很多玩家望而却步。解谜手册的熟记，
解谜物品的准备，问谜，解谜，清谜，再问谜，再解谜，精神 高度集中，
键盘敲个不停，就象一只陀螺，疲惫地转个不休。一个全自动的解谜机器人，
无疑是所有痴迷XYJ的玩家的梦想。把解谜变成一件轻松的事情，
留下更多时间享受聊天乐趣，让全自动机器人的梦想成真，就是这篇文章的目的。

据我了解与尝试，在现有的条件下，制作全自动解谜机器人大致
可以走以下几条路：
1、把所有任务列入Trigger中，根据问谜的结果触发，完成解谜任务；
2、利用Zmud本身提供的DDE（Dynamic Data Exchange，动态数据交换）
函数来开发一个外部程序，通过外部程序来控制Zmud的运行，实现自动解谜功能；
3、利用Zmud V5.55及其更高版本提供的Zmudapi.dll来开发一个控制Zmud运行的外部程序。
4、利用Zmud V5.x及其更高版本提供的数据库模块构建解谜数据库，配合Trigger来控制解谜。

下面我们来分析一下各种方法的利弊与可行性。
1、现有的很多所谓自动解谜机器人就是这种类型的。有些是专门做
一种解谜任务的，有些更全一点，最好的好象可以做四种任务。
说到底，这样的机器人不过是简单的触发堆积，Trigger庞大的要命，把机器拖的半死，
完成解谜任务又相当刻板，对于XYJ2000的解谜系统根本不适合的。我认为，
这样的Trigger只能拿来给新手做解谜的辅助与提示，没有更大的实际意义。
2、DDE的支持从Zmud很早的版本就开始了，当然DDE本身也是个老古董了。
对于大家常用的4.62版本来说，是除了方法1之外的唯一途径了。
当年浙大西游记的郭大路(henry)曾经用Delphi开发了一个自动解谜的外部控制程序的雏形。
他之所以选用Delphi开发，理由是：
Zmud是用delphi编写的，所以用Delphi最好，VC太复杂，VB的DDE控件不行，
只有Delphi的DDE控件与它联系起来最方便。
雏形出世的时候我还没有开始玩XYJ，同时这个雏形也没有引起太多人的注意。
所以henry的计划随着他去清华读博夭折了。
用DDE开发自动解谜机器人，无疑比方法1迈进了很大一步，
但是，在开发上的难度是相当大的。
3、从Zmud V5.55开始，ZuggSoft公司提供了一个叫Zmudapi.dll的动态链接库。
这个DLL本来是提供给Zmud用户来开发各种插件(Plugin)的。
我在连到ZuggSoft站点下载Zmud 5.55的时候注意到了它的介绍。
（在Zmud 5.55中还附带了Zmudapi.hlp，这个帮助文件简单介绍了该
DLL的功能与用途。在更高版本里不提供这个帮助文件。）
它提供了对Zmud的命令控制、数据传送（单向）以及其他一些功能的函数。
当时我就决定通过调用这个DLL来替代DDE实现外部控制程序，
可惜，我用VC无论如何也无法正常调用DLL提供的函数。这也促使我转向寻找其他方法。
不过，会用Delphi的朋友可以去试一下，Zuggsoft是推荐用Delphi开发的。
4、我的目光焦点是最后转向这个方法的。从Zmud 5.x开始，提供数据库功能，
而这个数据库对于庞大的解谜系统无疑是十分适合的。
解谜的任务如果不包括玩家送物和玩家拜贤，数目接近2000个，用现成的数
据库来处理要比自己编写专门的数据处理程序要便捷的多，处理速度上也有优势。
虽然Zmud提供的数据库功能并不强大，但对于我们编写自动解谜数据库而言足矣，
控制解谜的其他部分可以用少量的Trigger来实现。

在多次尝试之后，我最终选择了第四种方法。在下一章，我会从开发
解谜机器人的实际过程开始，按我所经历的实践思路跟大家探讨：

第二章 建立解谜数据库

建立解谜数据库的最主要目的是，提供迅速快捷的解谜信息的查询。
另外，还可以利用数据库排序、选择的基本操作，来实现自动选择执行任务的功能，
这点我会在下一章里详细说明。
下面就开始搭建全自动解谜系统的基石――解谜数据库。
在Zmud 5.x和6.x版本中，工具栏里有个DB按钮，通过它进入Zmud的数据库模块。
根据上面列出的两个目的，我建立了两个数据库：一个是静态的数据库Record.db，
一个是动态的数据库Quest.db。
Record.db用来保存所有的解谜任务，里面的内容只能通过数据库的数据管理来做修改，
在自动解谜系统工作的时候，它的内容是不会发生变化的；
Quest.db用来记录当前的解谜任务，总共七条记录，
它的内容随着解谜的进行不断更新，
并且通过建立Quest.db的视图按条件选取下一个该执行的任务。
两个数据库的构造如下：
Record.db
这个数据库的记录有6个字段(Field)：
Type(任务类型，该字段为Single Option类型，字段的值为
食物、送物、拜贤、灭妖、武器、盔甲、募捐之一。)
Name (任务名称， 字段类型Text)
Ename(任务英文名称， 字段类型Text)
Extra(任务附加选项， 字段类型Text)
Place(任务地点， 字段类型Text)
Todo (执行该任务的命令， 字段类型Memo)

Type字段将任务的类型加以区分，对应七种不同的任务种类；
Name和Ename字段在不同任务中分别对应食物、武器、盔甲、募捐的物品和送物、
拜贤的人物的中文名及英文名；Extra字段在送物中对应所送物品名称，
在拜贤中对应所询问事宜；Place字段记录任务中人物或物品所在地点；
最后一个Todo字段是最重要的，记录了执行该任务的命令操作。举例如下：

Type Name Ename Extra Place Todo
拜贤 大和尚 he shang 佛学 车迟/金平府/乌鸡 略

在实际操作中，Place字段是可以省略的，但考虑到对新手具有提示作用，把该字段保留了。
建好了Record.db的框架，我们可以把记录向里面添加进去了。
如果用手动一个个填写添加，不但容易出错、遗漏，而且工作量大的惊人。
幸好Zmud的数据库对记录的输入提供了Import的功能，可以直接从文件中读入。
Import可以从两种文件读入记录，一种是普通的txt文件，这种txt文件每行为一个记录，
不同字段用Tab隔开；另一种是csv文件，用逗号(comma)来间隔字段。
实际上，这两种文件的区别只在于间隔 符号的不同，我们无须刻意选择，
因为在Import的时候，可以向Zmud指定说明间隔符号的类型。
为减少工作量，我以源码中的任务列表(/d/kaifeng/npc/quest_*.c)
为基础，把其中无用及重复的任务剔除掉，进行整理补充，将所有记录保存在QuestDB.txt中。
然后将这个txt文件Import到数据库中。在选择完Import文件之后，Zmud将弹出一个对话框，
把各个字段及其相应记录显示在一个预览表格里，如果正确，将自动把文件里的
每个记录添加到Record.db中去。这一步是相当便捷的，
也使我的热情没被添加记录的繁琐给磨灭。:)
建立完成之后，Record.db里总计有大约1800条记录。

Quest.db
我在这个数据库中新建了四个域(Field)，其名称与类型分别如下：
Type (任务的类型， 字段类型Single Option)
Name (任务的名称， 字段类型Text)
Cloud(是否有云， 字段类型Boolean)
NotDo(多久未完成该项任务， 字段类型number)
Type、Name的作用与Record.db中的Type、Name一样；Cloud字段是个布尔量，非零即一，
记录对应此任务的云是否存在；NotDo字段记录此任务有多久未做。
我们知道，食物、送物、拜贤、灭妖、武器、盔甲、募捐七种任
务对应的云彩分别为红、青、绿、黄、蓝、粉、白。输?quot;Quest"命令
查看当前任务的时候，可以知道身上有哪几朵彩云。我们可以利用函
数%pos(para1，para2)来得到Cloud字段的值。例如：
“慢慢地一小团红白两色祥云在你的身边升起。”
我们就得到一个Colorlist=“红白”，%pos(红，@colorlist)可
以返回“红”这个字在字符串“红白”中的位置，如果不存在则返回值为零。
因为Cloud字段为布尔量，如果需要查找的字存在于字符串中，则返回值非零，
赋给Cloud就为一；反之则为零。利用这个方法
我们可以得知哪些任务有相应的云彩存在，哪些没有，为选择任务打 好基础。

建好了这两个数据库，我们可以开始构建上层建筑了。后面，我们继续讨论：

[wujiayue]

厉害

70还是一句话 继续灌水赚钱 买机器 呵呵rr

[ppgg]

[yujie]

哎 好可怜啊 何时才能有500silver啊

[yujie]

纯粹灌水撒 呵呵 晕倒了

[kkkkk]

只有不停的灌，才能到500
我灌灌灌

[BenHoo]

灌水

灌水

灌水

灌水

灌水

灌水

[hehehehe]

学习 学习。。。。。。。。

[lione]

[xlw]

不灌不行呀！！！！！！！！！！！！