- 好友
- 20
- 在线时间
- 315 小时
- 最后登录
- 2024-9-8
子爵[版主]
- UID
- 81513
- 第纳尔
- 5223
- 精华
- 1
- 互助
- 18
- 荣誉
- 5
- 贡献
- 100
- 魅力
- 124
- 注册时间
- 2008-6-26
鲜花( 120) 鸡蛋( 0)
|
问题背景:在制作盾牌格挡反击时,由于触发逻辑都在item的触发器it_on_shield_hit中触发,而骑砍1的引擎貌似没有提供类似于sleep这类的中断语句,导致盾牌格挡,反击动作,还有敌军被击倒的动作同时触发了。
关键字:延迟触发
详述:以上问题,主要是因为利用了set animation来做攻击动作,而animation是没有物理碰撞的,因此敌方被击倒也需要一定的判定后set animation
因此问题来了,在同一个触发器中,攻击方刚挥刀出去,由于没有延迟触发导致敌军还没被砍,就做了被击退的动作。
解决方法听着很容易,加个0.3左右的延迟就行了,但是这个延迟可不太容易加。
解决案1:利用reset_mission_timer_a、store_mission_timer_a
以上是operation手册中提供的三个定时器之一,我把它看做秒表。论坛中有些高手利用了定时器做延迟操作和mt中的自由触发器(0,0,0)来记录时间,满足时间条件后再触发需要延迟的动作。
这的确是一种做法,不过在此我补充一个更简单的方法,我们来看看这个自由触发器的构造:
(1,2,3,[条件块],[处理块])
参数1,代表每隔多少时间触发一次,本例就是每隔1秒触发一次,然后进入条件块进行一次判断
参数2,代表条件块结束后的延迟时间,本例就是如果条件快满足,就将延迟2秒后,进入处理块
参数3,结果块处理结束后的中断时间,本例就是如果结果块处理完毕,就将停止3秒,之后再每隔1秒进行触发
参数4,条件块顾名思义是用来做条件判定的,但是你也可以在这里写一些操作语句,比如set animation之类的。只要条件块中的所有语句最终能走完,就算通过条件判定
参数5,处理块顾名思义用来做真正的逻辑处理的地方,无论处理语句是否全走完,都算处理完毕
通过以上的描述,我想很多人应该明白了,自由触发器本身自带了延迟触发。所以如果你对时间把控没那么严的话,可以好好的利用参数2。
就拿摆pose攻击来举例,attacker的攻击动作可以先在条件块触发,之后利用参数2做延迟,可以写小数,之后再在处理块做defender被击退的动作
问题点:不是所有触发器参数2,3都有作用。比如ti_on_agent_hit, ti_on_agent_kill_or_wounded等,甚至item中的触发器ti_on_missle_hit, ti_on_shield_hit只有处理块没有其他参数,
所以很多必须使用这类触发器又需要延迟触发的case应对不了,而且自由触发器的延迟触发必须写死,不能作为变量,这点也不太方便
解决案2:利用两个甚至多个触发器连携控制
此解决方案针对所有触发器,拿文章最开始提到的格挡反击做例子,利用ti_on_shield_hit和自由触发器(0,0,0)来共同触发完成
ti_on_shield_hit只做条件判定以及反击者的反击动作,只有设置一个全局参数,或者slot,或者其他可全局使用的标志,利用自由触发器(0,0,0)配合mission_timer来控制可变换的延迟触发。
这种做法,相当于其中一个触发器成为了信号发射器,另一个成为了信号接收器,就这样想象吧。
问题点:效率是个大问题,因为大部分时候,我们的需要try for agents等操作,以自由触发器(0,0,0)来触发对于效率影响会比较大。当然也有方法尽量减少try for agents的使用频率和循环数,
这里不做过多的介绍,以后有空再分享。
结束语:这是我想到的延迟触发的两种做法,解决案2有些复杂,对于新手可能有点难度。在此我也想征集一些大家的想法或者做法,对于延迟触发。也许有更简单的方法,也许根本不需要延迟触发,
比如有办法让animation产生物理碰撞等。
最后说一句,感谢大家能看到最后。
|
|