|
这个问题,是我在做技能的时候深入研究发现的,虽然有一个更简单的办法捕捉到,但是那不是一个准确的事件.
各位还是先看看我的做法:
关于弓箭手,角鹰兽与角鹰骑士三者之间的情感纠葛的研究
好吧,我承认,这个标题是有点过份了,但是还是能被大多数人所接受的,比如我吧,就接受这样的标题,当然进来看了的同志也一定接受,不然你怎么会进来看呢.好了我们言规正传,这三个之间到底有什么样的情感纠葛呢?且听我道来.
这三个单位之所以能被拍在一起,主要是因为三个技能:塔载弓箭手,骑乘角鹰兽和卸载.
玩过对战且喜欢NE的人(本人主族NE,很菜VS4级,常被虐.但是自从玩起WE就没再上VS对战过)都知道这么一个战术:前期暴出AC(弓箭手),二本偷偷地出角鹰兽,研究完相关科技后狂出角鹰骑士.
但是玩的人也许会认为,弓箭手骑上角鹰兽就变成角鹰骑士了,这一切只是表像.
我们玩WE,自然要有我们的玩法.
首先建几个T吧:
1,建一个骑乘加载与卸载T,其中骑乘和加载是同一个命令串"coupleinstant",卸载的命令串是"decouple"
事件
单位发布无目标命令
条件
转换 发布命令 ID 等于 转换 "coupleinstant" 为ID 或 转换 发布命令 ID 等于 转换 "decouple" 为ID
动作
custom script : call BJDebugMsg(GetUnitName(GetTriggerUnit())+"生命值是:"+R2S(GetUnitState(GetTriggerUnit(),UNIT_STATE_LIFE)))
custom script : call BJDebugMsg(GetUnitName(bj_lastCreatedUnit)+"被创建")
custom script : call BJDebugMsg(GetUnitName(bj_lastReplacedUnit)+"替换")
2.骑上角鹰兽之后,弓箭手和角鹰兽去哪了?难道真的骑上去了吗?是不是死亡了?敢猜就要敢做!
事件
任意单位死亡
动作
custom script : call BJDebugMsg(GetUnitName(GetTriggerUnit())+"死亡")
这样就好了,我们在地图上放上一个角鹰兽,一个弓箭手,将相关科技要求去掉吧.开始我们的测试了!
第一次选中弓箭手点骑乘角鹰兽技能,哦也,她骑上去了,Maybe she is very comfortable...^_^.
屏幕上显示这样的信息:
弓箭手的生命值是 315.00
null
null
弓箭手死亡
角鹰兽死亡
第二次解散她们,弓箭手和角鹰兽,爽完了就分开了^_^.但是我们不关心她们是怎么爽的,我们关心的是屏幕上的信息:
角鹰骑士生值是815.00
null
null
角鹰骑士死亡
第三次选中角鹰兽点塔载弓箭手技能,哦也,弓箭手又骑上去了,先不管她爽不爽,看看她脸上写什么吧.
角鹰兽的生命值是0.00
null
null
弓箭手死亡
角鹰兽死亡
居然把角鹰兽给搞死了!
从以上数据我们可以得出以下结论:
1.每一次塔载或者骑乘,或者解散都是以杀死现有单位从而产生新的单位.这就是说 A骑上B 就产生C,而A和B已经死了;当C解散的时候,产生D和E,而C也死了.如此循环下去.为何我们听不到他们死亡的声音?我认为是移除了.
2.产生的新的单位不是创建,不是替换.具体怎么产生的,我还没能研究出来,对此有兴趣的人可以继续研究下去.要捕捉这两个新的单位,只有用单位进入矩形区域.
因此他们三者之前的情感纠葛是以牺牲母体与父体或者仅母体情感为基础来产生新的感情.像很多自然界的昆虫一样,新的生命的诞生会以杀死他的父母做为代价.但是这三个单位之间产生新的单位却不是创建,不是替换,平白无故地冒出来的......
那么问题是:
1.这个合体后的角鹰骑士及解散后的弓箭手和角鹰兽 是怎么样产生的(经过以上的实验大家也看了,他们的产生不是创建,不是替换,更不是召唤)?
2.除了用单位进入区域这种非准确性方法可以捕捉到单位之外,用什么更加准确的事件可以捕捉到?
3.如果解决了1,那么2自然能有办法解决. |
|