Register
I just tried fiddling around with a counterattack that chained to another attack with a long delay, and found that the enemy will continue to use regular attacks during the delay. None of the attacks have the "delay doesn't block further actions" bitset on... and yet the enemy keeps using regular attacks between their chained counterattacks anyway.
So does the delay of counterattacks just not block regular attacks by default, or is something screwy going on here?
FYS:AHS -- Swapping out some step-on NPCs for zones + each step script
Puckamon -- Not until the reserve party is expanded.[/size]
Counterattacks and delay
Wed Feb 22, 2012 6:07 am 
Wed Feb 22, 2012 6:33 am
Yes, I'm pretty sure it's that way by design. Sounds like a potential bitset that could be added?
My website, the home of Motrya:
http://www.jshgaming.com
My website, the home of Motrya:
http://www.jshgaming.com
Wed Feb 22, 2012 8:18 am
I didn't know about this, and didn't expect that it would be intentional, but it seems it is:
If we added a bitset, I think it should be "Delay doesn't block further actions when used as a counter attack" and default to ON, but that's way more than the width of the screen :(
Code:
'counterattacks are forced non-blocking
autotarget who, bslot(who).elem_counter_attack(i) - 1, bslot(), t(), YES, NO
autotarget who, bslot(who).elem_counter_attack(i) - 1, bslot(), t(), YES, NO
If we added a bitset, I think it should be "Delay doesn't block further actions when used as a counter attack" and default to ON, but that's way more than the width of the screen :(
Wed Feb 22, 2012 3:35 pm
Hmmm.... I actually remember my thought process regarding this. It went something like this
* James wants to implement counter-attacks
* Counter-attacks would be utterly unthinkable unless there was a way they could always be non-blocking
* James works long and hard on getting non-blocking attack support working
* James implements counter attacks
That is right. I would not have even bothered with non-blocking attacks if I didn't think that counter attacks strictly required it...
but what I can't remember is WHY I had that thought process :)
Counter attacks that block/interrupt an enemy's normal actions is a totally reasonable request, and I have no idea why I didn't think so when I first implemented them.
Maybe the option to control this this belongs in the enemy counter-attack menu, not in the attack bitsets.
* James wants to implement counter-attacks
* Counter-attacks would be utterly unthinkable unless there was a way they could always be non-blocking
* James works long and hard on getting non-blocking attack support working
* James implements counter attacks
That is right. I would not have even bothered with non-blocking attacks if I didn't think that counter attacks strictly required it...
but what I can't remember is WHY I had that thought process :)
Counter attacks that block/interrupt an enemy's normal actions is a totally reasonable request, and I have no idea why I didn't think so when I first implemented them.
Maybe the option to control this this belongs in the enemy counter-attack menu, not in the attack bitsets.
Thu Feb 23, 2012 3:39 am
If they were blocking, would they cancel any chain that the enemy is the middle of? I assume not, but I have still yet to look at the attack queuing code.
I'm a little anxious about attack chaining behaviour depending on enemy bitsets.
I'm a little anxious about attack chaining behaviour depending on enemy bitsets.
Thu Feb 23, 2012 3:04 pm
TMC wrote:
If they were blocking, would they cancel any chain that the enemy is the middle of? I assume not, but I have still yet to look at the attack queuing code.
I'm a little anxious about attack chaining behaviour depending on enemy bitsets.
I'm a little anxious about attack chaining behaviour depending on enemy bitsets.
Ah! That explains it! Before queueing was implemented, yes, a counter-attack would definitely cancel/overwrite any pending chained attack.
That must have been why I felt at the time that queuing was an essential feature for counter-attack support.