原始数据的获取：
首先当然通过颜色判断获取每个字符的点阵。每个字符宽度8点阵，为了增加以后的判断速度，用数值代替。每个点亮与不亮，合计编号数字1-64。
每个字符高度在8-10，这样每个字符用一个list变量保存，比如@list1.1=64。#SHOW %expandlist(@List1,"|")可以特定的分隔符一次显示和保存@list1，字符高度不确定也没有关系，List1=%push("63",@List1)可以直接给@list1添加数值。
这样我们就得到一个{64|63|60...}的变量，人工判断出代表的字符。保存到文本文件中。
循环多次得到全部字符。
对得到的结果进行分析，看看最少需要几行特征数字能标记一个字符。加入字符A的第1行(数字为64)和其他字符都不相同，就标记为A,1,64
通过人工分析能最大程度降低特征库的大小，增加判断速度。由于特征库很小，可以直接在机器人文件中保存为变量，可以用一个rec变量，也可以用2-3个list变量。反正zmud7对rec list变量有很多的操作函数，详见 帮助-参考-Function的lists database项。
不做分析也可以，将特征库保存到文本、数据库，甚至保存几十个list变量--保存几十个变量程序实现更容易，取到一个@list1，直接比对这几十个变量，就能知道是什么字母了。
如果保存的是自己分析的特征码+行号，就拿@list.1去比对行号为1的特征码，也是#FORALL @list {} 循环搞定。
要是duno的思路，最终显示结果为1-4倍。可以增加一个宽度判断指令，工作量*4，也可以找出wiz的算法，最终反向表述为1-64的数字，这样判断程序部分就不用改了。
其实就是抓取分析的工作量大。服务器资源也不允许太过变态的转换计算，否则10来个id在门口ask，就能把服务器累趴下。
1）比例尺输出是可以没有额外消耗的
除了额外流量，运算消耗不是问题
2）关于点阵问题，比例尺不一定是整数
如1.7倍比例尺，然后平滑处理即可
1-4倍，是因为4倍图就已经很大了，再大可能很多窗口不能完整显示
基于点阵的识别会麻烦很多
3）关于算法还原
这是把算法说出来了
如果不说出来，自己摸索的过程就完全不一样了，需要大量猜测和实验
4）反机器人的实际目标不在于让人做不到，而在于成本比例
花两分钟的小改要两个小时的识别就是成功的反机器人策略
在魔高一尺道高一丈的拉锯过程中，wiz一方始终可以占据主动，但是这东西对实际游戏乐趣提升没啥贡献，只是消耗wiz精力而已
囧
还是觉得朱熹抄经的那个antirobot很棒！
牛啊，看不懂，赚钱走