工具
精华
|
战斗力 鹅
|
回帖 0
注册时间 2011-6-13
|
本帖最后由 hyndcon 于 2018-6-3 01:12 编辑
hello大家好,还记得我是谁吗,对了,我就是上一期 大号挖坟禁言中,过几天就能看了 这帖的楼主。
上个版本的脚本运行机制,占用CPU相当高、AOE和单体输出必须手动区分、输出还是离不开按键。
今天这个教程,将一并解决上述三个问题。
要写好基于TMW的WOW输出脚本,必须要熟练掌握TMW和按键精灵。只有清楚地知道TMW能做到什么、按键精灵能做到什么,才能对输出脚本的书写得心应手,驾轻就熟。
首先我们来看CPU占用的优化。之前的运行机制,是按键精灵对键盘按键进行无休止地监听。这样非常耗CPU。
修改方案A:抛弃GetLastKey和WaitKey这两个监听入口,采用点控方案,点一次运行一次脚本,不点不运行,通过修改脚本的运行快捷键实现。
修改方案B:抛弃GetLastKey和WaitKey这两个监听入口,采用自动化方案,脚本内部设loop和延时,激活脚本后,不停循环,直至按下脚本停止运行快捷键。
由于A与B方案大体思路相近,点控改loop无非就是是代码最后加个延时再加一句“goto 循环开始”。因此本教程采用B方案。
其次我们再来思考如何区分AOE和单体。这个可以用TMW的lua判断来实现。原理是遍历姓名板*目标,然后利用开放的API:IsSpellInRange(spellName, unit)**来测定这些目标是否满足该技能的射程,如果满足,那么sweepCount数+1,最后返回sweepCount值给TMW。NGA有相关帖子。
*:必须按V打开怪物血条,不然失效。
**:暴雪开放给你的IsSpellInRange(spellName, unit)函数相当娇贵,用当前角色掌握不了技能去测会返回nil,目标不是合法目标返回nil,不需要目标就能释放的技能同样也返回nil,具体请参考wiki。
运行机制思路有了,我们开始搭框架。框架的好坏直接影响后期增删改,如果之后的需求满足不了,最坏的情况就是整个推倒重来,这是我们最不愿看到的。
首先摆在我们眼前的是获取坐标问题。快速地去录入多个TMW图标的坐标是后期增删改的效率化前提。我们注意到TMW的图标间隔是固定的,这样我们只需要确定下来第一排第一列的图标的坐标,就能推算出所有其余图标的坐标。我们事先构建好3x10的图标分组,把图标大小比例以及间隔固定下来后锁定,然后我们就可以在按键精灵里对其坐标进行录入了。
我们人为地定义第一排第一列的图标叫P00,第一排第二列的图标叫P01,以此类推,最后一个图标自然是P09。于是30个图标就命名为P00~P29。我随便拿一个名称,比如P17,那么你一眼就可以找到它:在第二排的第八个图标就是。
于是它们的横坐标就是P00X,P01X,...,P29X。纵(Y)坐标同理。接下来我们就可以推算了:比如说我们把TMW分组大小比例设置为50%,图标纵横间隔都是2像素,那么P00左上角第一个点,到P01左上角第一个点,距离恰好是16像素。
我们在按键精灵里定义一个“图标间距”,然后让“图标间距 = 16”。
我们不妨把P00中心某一点的X坐标定义为“X坐标”,Y坐标定义为“Y坐标”,于是:
P00X = X坐标 + 图标间距 * 0
P01X = X坐标 + 图标间距 * 1
……
P09X = X坐标 + 图标间距 * 9
P10X = X坐标 + 图标间距 * 0(想一想,为什么)
P11X = X坐标 + 图标间距 * 1
……
P29X = X坐标 + 图标间距 * 9
P00Y~P29Y同理。
这样我们只需要捕获一次P00内某一点的X坐标和Y坐标(教程案例里坐标为490,30),通过修改“X坐标”和“Y坐标”的值,就可以推算出其余所有图标内同一点的坐标值。
有了所有图标的坐标,我们就可以对该坐标进行取色处理了。为了修改方便,我们直接把取色函数封装成一个方便调用的子函数:
- Function 判断(PX,PY)
- IfColor PX,PY, "0000FF", 0 Then
- 判断 = "红色"
- Else
- 判断 = "不是红色"
- End If
- End Function
复制代码 这样我们输入一对坐标,就可以输出红色/不是红色,方便后期修改。
该定义的都定义好了,接下来就到了脚本正文了。其实正文很简单,就是一个优先级嘛。用if去判断坐标(P**X,P**Y)的颜色,红色就call一个按键命令,不是红色就不call,回到循环开始。以下是范例:
- Rem 循环开始
- //此处略过若干代码
- If 判断(P14X, P14Y) = "红色" Then
- Call Plugin.Bkgnd.KeyPress(Hwnd, 101) //灵界打击
- delay 延时
- Goto 循环开始
- End If
- If 判断(P15X, P15Y) = "红色" Then
- Call Plugin.Bkgnd.KeyPress(Hwnd, 103) //心脏打击
- delay 延时
- Goto 循环开始
- End If
- delay 延时 //以上均不满足时
- Goto 循环开始
复制代码
就这么简单?对,就这么简单。不要把按键精灵想的太复杂,时刻牢记:变红就打,不变红就不打。至于怎么变红,如何变红,这不是按键精灵所要考虑的事情。
好了,按键精灵脚本部分已经搭建完成,剩下的该考虑技能循环了。这是重头戏,所有的难点其实在这里。一起享受写TMW的乐趣吧!
WOW与其说是技能循环,不如说是技能优先级。哪个技能都能按的情况下,无非就是哪个技能收益高,哪个技能收益低。以冰DK为例,笔者的冰DK刚刚102级,技能框架已经成熟,可以写TMW了。在你正深思熟虑头一个图标怎么写的时候,有件事你必须先考虑一下:
这个脚本是没有开关的!意味着你见人就艹,不管你有没有目标,不管目标是不是敌方,不管目标是不是一个尸体,你的脚本依然会不断地发送按某个技能按键的指令。所以你需要一个总开关。于是你的头一个图标应该是这样的:
这样你战斗中它就变红,变红就循环开始,不变红就不开始。总开关有两种写法,一种是if嵌套,大if嵌小if;另一种写法就是不变红就回到循环开始。我采用后者,代码如下:
- If 判断(P00X, P00Y) = "不是红色" Then //战斗判断
- Delay 延时
- Goto 循环开始
- End If
- If 判断(P01X, P01Y) = "红色" Then //鲜血天赋判断
- Goto 鲜血天赋
- End If
- //……接下来的代码
复制代码
没错,你注意到了,我第二个图标是天赋判断。这样一个脚本囊括所有天赋,相当省心。你顾不过来可以先放一放,先解决一个天赋的问题,多天赋慢慢来不急。
技能优先级我分成十个图标,分别是:冰柱判断、湮没判断、吹风判断、泄能冰打判断、触发冰镰判断、触发湮灭判断、洗衣机判断、通常冰镰判断、通常湮灭判断、冰打判断。
没错,你又注意到了,同一个技能判断我可以分拆成两个图标。这在逻辑上没有任何问题,利用优先级嘛。很多时候,一个技能要打的时机非常多,你写在一个TMW图标里,很有可能会智商爆炸。要学会如何去分拆技能图标。下面是吹风判断的例子:
用白话来解释一下:什么时候打吹风呢?有白霜的情况下,目标存在且敌对(好像漏了个存活,写完教程后,立马得加上),满足下列条件之一的,就打吹风:
条件1:开湮没爆发的时候,怪突然断疾病啦!没办法,这个要补吹风。(湮没期间资源溢出,要考虑GCD质量,我没点风暴汇聚天赋,湮没期间白霜触发吹风收益显然没有湮灭和冰打高)
条件2:湮没爆发不存在的时候,请尽情地打白霜触发的吹风。
其余图标也是大同小异。总而言之,你只要记住,图标变红按键精灵就打相应技能,图标从左至右存在优先级的概念。
你可能注意到了之前按键精灵代码里出现了句柄。对,没错,这个脚本可以后台运行——但是很遗憾,只能“半后台运行”:后台取色函数无法在DX绘图的游戏里获取正确的图标颜色,这意味着遮挡住TMW分组图标=脚本失效。
欣慰的是,你可以开一个QQ之类的小窗口,这不影响脚本运行。句柄的抓取是一次性的、位于循环外的。换而言之,如果你不小心在QQ位于前台的时候运行了脚本,脚本是失效的。解决办法是停止脚本,确保WOW处于前台的时候,再运行脚本。
最后,我想谈谈这个脚本的合法性。
我向来不想在纸面上谈这个问题。抠字眼摆协议,此BOT非彼BOT……完全就是屁股大战,这毫无意义。
我希望在一个更深的层次去谈这个问题。游戏的本质是什么?我用脚本玩,我还有乐趣吗?平衡性又如何?是否会造成不公平?
我认为,写脚本本身就充满了游戏性,从一个被设计师喂屎的游戏,一跃成了一个更高阶的工控类游戏,乐趣反而升级了。
而且,我一不卖脚本赚钱,二不用脚本PVP。脚本不影响他人,反而还给他人带来更好的游戏体验,我觉得就这一点上来讲,我们应当支持PVE使用脚本。
最后,如果要封,请随意。账号对我来讲已经没什么吸引力了,一只脚踏入中年,游戏也不怎么玩得动了,封就封吧。
当一个人觉得学习和工作的过程本身就是一种乐趣,带来和撸管相媲美的快感,这个社会会变成什么样呢?
用钱不像收钱那样要低头,感觉比较舒服。
「顾客是上帝」什么的,不知不觉间宣扬消费者是最高贵的,不过那本来是卖东西的一方的心情吧。
不过,如果大家都变成用钱的一方的话,到底谁来提供服务呢?
我倒是觉得收钱比付钱开心的社会比较健全。
——泷泽朗
私货完毕,接下来是视频演示:
http://t.cn/R1lxmm4
(附录见下一页)
|
评分
-
查看全部评分
|