防抽

懒得重新打字，直接引用…
---------------------------------
没想到这个话题居然持续了这么久
之前我的推测没有加上“我推测”三个字而被一些朋友理解为实际原因，实在是遗憾
我的推测依靠的是我魔力的体会以及多年来编写游戏的经验
虽然以我的体会，刷屏确有提高遇敌率，且有自己的猜测
但在获得决定性的证据(原代码，通讯协议)以前，我也不能下任何定论
这点，我想大家也是一样的。
我会抽点时间用wpe分析一下魔力的封包，找到一些实质的答案
另外也会请教我所认识的魔力宝贝的开发人员，看看能得到什么情报
希望能终结这场气氛已经不太好的讨论把
ps。本人不偏袒任何人也不针对任何人
-------------------------------------
这次可能是我最快的一次开发了，呵呵
首先是找到了位置移动的封包
然后做了一些简单分析，很轻易就实现了原地遇敌，高速行走，无间隔喊话等功能
基本上与我之前的猜想是一致的
魔力宝贝的程序架构比较古老，将大部分判定放到了客户端上
不过，这也是情有可原
10多年前，网络游戏还是雏形阶段，许多理论并未完善。
发送
AF EF 10 00 12 5E 7A 55 0B 23 57 04 22 0C 5B 79 54 14 06 1E EF AF
接受
AF EF 20 00 44 5E 67 55 43 2F 15 44 74 09 7E 79 65 14 5D 1E 08 30 6D 6F 07 54 09 5C 5D 17 10 40 3A 0D 63 20 EF AF
这是魔力宝贝在行走时候触发的两个协议
拦包后可以知道，其格式是固定的，不同的是中间的一小部分
通过坐标换算16进制，发现找不到坐标数据，再从头与包的长度来看，推测使用了DES加密
但这并不是重点，我们只需要知道这个是与行走相关的封包就对了。
一发一收，很好理解。
发的是当前位置，而收的包是校验当前位置，并没有在图形上表现出来。
我略作修改
简单粗暴的发送了数个同坐标行走封包以后，居然遇敌了
可见魔力宝贝的通讯架构相当脆弱，允许原地行走这样不合常理的事情。
也证明一点，只要有任何形式的行走封包发送到服务端，并且加速这个过程
就可以提高遇敌的速度。
注意，这里说的并不是遇敌率，因为那个恒定值。
好了，我现在准备写一个简单的程式来分析说话以及其他形式的操作会不会加速这个包的产生。


首先，我总结下现在的结论：
1.现在我100%确定，只要发送行走封包到服务端，就有可能触发战斗(战斗区域)
2.只要能在同一时间，发送更多的行走封包，就可以更快的触发战斗。
3.行走封包格式固定，与地图无关，所以在安全区测试即可。为了秉承严谨的态度，我在安全区组队刷屏测试。结论是与看到的现象与野外一致（队长带队迅速乱走）。
ps。再解释一下“为什么队长自己没看到自己乱走，而其他人都看到乱走”这个问题
网络游戏是基于同步实现的（废话…），我们自己的角色属于本地操作，而其他角色依赖被动同步。比如A走到x，y这个点，这里我们分为两个视角
A的视角: 自己的角色行走，没有任何延迟感。这个过程是，A在行走的过程里，不断通知服务端，自己角色的当前坐标是什么。而服务端收到后处理相关逻辑，而遇敌就是其中一个。
之后服务端会将这个信息以另外一个封包广播给周围的人，以同步游戏内容。
B的视角：A行走到x，y，中间可能有所停顿或者加快，总之与A看到的基本不会一样。
B所看到的内容就是接续上面的故事，由服务端发送了A的行为后，程序解析这个行为，将A这个“其他玩家”由程序控制，行走到目标点，通俗点可以理解为遥控车。而网络通讯往往不是那么顺利的，可能发生延迟或拥挤。延迟的时候，A由于没有收到下一个移动指令，会暂停行走。而拥挤的时候会有许多包一齐接受过来，客户端会根据时间戳来产生一个拉扯，令A行走得更快一些，以强制同步。
可以看到，我们自己的角色在一般情况下，是不受服务端控制的。理由很简单：玩家不希望有延迟的感觉。 假设我们点下鼠标，由服务端处理后，再回发给你，让你移动，你会发现你的角色总是在执行你若干毫秒前的操作。
只有当角色的信息严重偏差的时候，会发送一个飞行指令，强制纠正角色的位置。
这样的情况有时候发生在队伍解散的那刻。因为那是容易产生位置不同步的地方。
还是回到正题，要验证刷屏遇敌增加，过程就很清晰明了了。
1. 在安全区行走一段时间，拦截移动封包。并统计数量
2. 在安全区行走同样一段时间，拦截移动封包，并统计数量
3. 两者之比，即是影响遇敌速度的值。
好了，我写好统计程序即可测试。


可能很多同学认为这个过程需要许多数据和庞大的测试
其实不需要，我的测试方法是这样的
1. A与B都到一个无人的地方，此时除了会每20秒有个心跳包以外，没有其他通讯包干扰
2. 第一组测试，A带队，行走6格。存储拦截的封包记录。
3. 第二组测试，A带队，刷屏（以我个人不觉得累的手速），行走6格。存储拦截的封包记录。
4. 过滤掉两组数据中的无关封包。
5. 对比行走封包的数量，这个比值，即是影响遇敌速度的关键数据。
再次确认一次会遇到的几个封包
AF EF 10 00 33 7B 0C 移动 发送
AF EF 20 00 3C 7B 11 移动 返回
AF EF 58 00 53 1B 05 说话 发送
AF EF 60 00 32 1B 30 说话 返回
AF EF 08 00 53 1B 5C 心跳 发送
AF EF 08 00 53 1B 5B 心跳 返回


那个数据包与通讯封包意义不同
数据封包仅摘出socket连接的2进制数据

很好很强大，度爷不让发16进制文本，那就贴图了
第一组记录（by WPE）
第二组数据 （by WPE）


最后统计
第一组: 很干净的12个包，6来6回，说明在正常行走的情况下，移动包是
正确的
。
第二组： 看上去很奇特，发送与接受都不平均且不正确
我将继续测试

我还是要申明，这个测试与探析，不针对任何人的言论，也不会参与任何人的立场
这个问题也是本人想要弄明白的事情
诉求仅仅是得到真相。
我现在还没对“刷屏是否可以增加遇敌速度”这个结论作任何判定

经过分析，AF EF 为固定格式开头和结尾，可以看到魔力宝贝是有粘包设计的
所以刚刚头分析也需要改动，其数据指令可能就只是前2个字节。
按无符号读，至少能支持65535个协议，很符合实际使用。

强大的技术贴……

还是先做个统计工具吧…
手工真累人
为了等凌晨火车票网站刷新…
继续试验打发时间

票刷到了，今天到此为止…
发现简单看前几位是不行的，需要解开des算法才行
明天抽空继续
不过今天已经有不少意外的收获了

现在的结论是：待续
请大家保持纯净友好的讨论气氛，thx。

阿伍能否先说明一下魔力宝贝的遇敌原理呢？

表示看不懂，呵呵呵呵，但我还是看完了

要说严谨,还是这样的测试被称为严谨吧

这个绝对是技术流，期待结论

技术帝。。。。。。。。威武~~~~~~~~~~~~~~~~··

加精。
望大家仅就遇敌问题讨论，涉及外挂的一律删除。