经过多次长时间的透视之后，我得出的结论是，史莱姆刷出速度太慢了
其实按照刷怪算法来说的，的确是刷出几率太低了
每tick，就是0.1s，就会尝试刷怪一次
会从主角为中心的17x17个chunk中随便选择一个位置，随便选择一种怪物类型
然后进行生成条件判断，如果成功则生成
而史莱姆除了生成条件判断之外，还有系统默认的90%的失败率
因此几率实在太低了，刷史莱姆速度实在太慢了
而且当周围怪物总数到达顶峰的时候，就不会再进行刷怪了

总结性的来说，设计没问题，但是刷怪速度太慢
跟刷怪塔一样，一个高效的刷怪塔需要保证全部怪物都生成在有效面积之内
既然都做了，一不做二不休，把这17x17个chunk全部点亮吧
表面的点亮我就不做了，白天的时候用就可以保证表面是光亮的
主要的问题就是地底的天然洞穴
这个时候就得靠之前演示的透视器了

慢慢一个一个chunk来，不用急
就当作是消磨时间吧，探索天然矿洞没有什么不好的，也算是收集矿物
说不定RP好还能发现地牢
说不定RP大爆发可以发现遗迹。。。。。

今天坐灰机回广州，可能要晚上才能更新

回去之后决定改造一下直播器，改用发包的方式。webbrowser主要问题是cookie不会保留，其次是占用内存太多，毕竟是ie的内核，再加上不能直接访问wap贴吧，需要用在线转换器，而在线转换器捆绑有广告，导致页面很慢。。总之劣势一堆，今天回去下定决心改用发包的方式

昨晚先进行了一下抓包。由于ie访问不wap，所以httpwatch抓包无能。于是没办法，只能打算下载个uc的java版然后用模拟器运行。但是刚好发现有人已经封装了个电脑版，于是就拿来用了。然后运行之后还得把uc的优化给关了，这样就是直接收发贴吧的包了，没有经过uc的中转优化服务器

最后用wsexplorer，对uc的进程进行抓包

最后用wsexplorer，对uc的进程进行抓包

最后用wsexplorer，对uc的进程进行抓包

登录页面的包变化不大，除了一个login参数从0和1变成了yes和no，返回的页面没有了反馈信息直接跳转。。总之跟1年前做发帖机的时候变化不大

发图片第一次研究，大概就是在包表头定义了一个分割字符串，应该是随机的，将包里的内容按这个分割，然后各种参数放进入，最后的图片直接把文件内容给搞过去。。ps帖子内容等文字是按照utf8储存，而包里面的其它内容则是按ansi

构造包鸭梨应该不大，只是繁琐，代码无聊。做出来之后直播器就好用多了。。

NB

马克