ReversalDef (SCTRLs)

[Ricepigeon]

Defines a reversal. If one of P2's Clns1 boxes comes in contact with one of P1's Clsn1 boxes and a ReversalDef is active, then P1 will reverse P2's attack. Use with p1stateno (and optionally p2stateno) for creating reversal attacks.

ReversalDefs take the HitDef parameters pausetime, sparkno, hitsound, p1stateno, and p2stateno, plus:

Required parameters:
    reversal.attr = attr_string
        attr_string specifies the list of attack attributes that can be reversed by this ReversalDef. It is a standard hit attribute string. For instance, reversal.attr = SA,NA,SA means stand+air, normal attack, special attack.

Optional parameters:
    sparkno = S1500, Overrides P2 hitspark

    sparkxy = 0,0 The sparkxy parameter is treated as an offset to P2's hitdef's sparkxy. The MoveHit trigger can be used to detect if P1 successfully reversed P2

    hitsound = S1,0 Sound upon hit

    p1stateno = The stateno P1 changes to on hit

    p2stateno = The stateno P2 changes to on hit

Example:

Code Select Expand


[State 0, ReversalDef]
type = ReversalDef
trigger1 = 1
reversal.attr = S,NA           ;SCA,NA,SA,HA,NP,SP,HP,NT,ST,HT
pausetime = 0 ,0
sparkno = S3000
sparkxy = 0,0
hitsound = S1,0
p1sprpriority = 2
p2sprpriority = 1
p1stateno = 0
p2stateno = 5000
numhits = 1
Id = 0
hitflag = MAF        ;HLAFD+-
ignorehitpause = 1
;persistent =


Additonal Notes:
There is an undocumented "attr" parameter for the ReversalDef SCTRL, which should not be confused with the required "reversal.attr" parameter. This works similar to the attr parameter for the HitDef controller in that it will define attributes of the Reversal occuring from the ReversalDef, allowing the Reversal to be affected by an opponent's HitOverride controller if the Reversal's attributes match that of Player2's HitOverride. If omitted, the Reversal will have no attributes assigned to it, and thus will ignore the effects of Player2's HitOverrides.

You can also use the "ID" parameter for reversaldefs.  Useful with gethitvar(chainid).

Additionally, there is a glitch in the Reversaldef controller which causes Player1 to retain Player2's target information even after Player2 returns to an Idle state. This allows Player1 to use target-based state controllers such as TargetState and TargetLifeAdd, as well as the Target redirection trigger, when they would normally not be allowed to. Through specific coding, it is possible to utilize this glitch to replicate a "damage-over-time" effect such as Poison. Please see these threads for more info.

Another good note about applying this SCTRL to helpers

Yes, a helper's reversaldef supersede the root's vulnerbale hitboxes. As long as the eenemy projectiles come in contact with the helper reversal clsn, it will apply the reversal effects before the enemy projectile's hitdef is registered.

No need for nothitbys, just duplicate your character's clsn into the helper, change the portion that should destroy projectiles to red clsn, and then bind the helper to your character for the desired duration.

There's no way to account for multi hitting projectiles with reversaldefs, the character shooting the projectile would have to do that, and I'm not even sure how this explanation applies to actual projectiles from the projectile state controller.

[DarkWolf13]

I've coded WereGarurumon with a ReversalDef that has him attack with Wolf Claw if he's struck during his ready stance... you can tell by him flashing. His reversal derives from Mouser's Cammy who has 3 different moves depending on the version of the state but WereGarurumon has one. I don't see many characters with Reversals in MUGEN unless it's in a certain series I don't usually play.

Sorry if I wasn't informative enough earlier. Here's an example of the state I used for WereGarurumon with the ReversalDef.

Spoiler (click to show)

Code Select Expand


;Garuru Reversal
[Statedef 1120]
type = S
movetype= A
physics = S
ctrl = 0
anim = 1120
sprpriority = 2
velset = 0,0
poweradd = 90

[State 1120, PlaySnd]
type = PlaySnd
trigger1 = time = 0
value = 10,0
channel = 0

[State 1120, Explod]
type = Explod
trigger1 = time = 0
anim = 8300
id = 8300
supermove = 1
sprpriority = 4
ownpal = 1

[State -2, PalFx] ;His body flashes as he readies himself
type = PalFX
trigger1 = time % 2
trigger1 = animelem = 2,>= 0 && animelem = 3,< 0
add = 16,96,96
color = 8
time = 1
ignorehitpause = 1



[State 1120, ReversalDef]
type = ReversalDef
trigger1 = animelem = 2
reversal.attr = SCA,NA,SA     ;He only counters if he's struck by a normal or special attack that isn't a throw or projectile
pausetime = 11,12               ;Time he's still for before going into his counter attack & time his attacker is paused upon hitting him
sparkno = S8708
hitsound = S0,13
p1stateno = 1121                ;WereGarurumon goes into this state when he's hit by required type of move, which is Wolf Claw

[State 1120, ChangeState]
type = ChangeState
trigger1 = animtime = 0
value = 0
ctrl = 1


[PlasmoidThunder]

So what's the advantage of using this over HitOverride for Counters, other than the ability to send P2 into a custom state instantly? I mean, you can have the HitOverride send P1 into a state with a HitDef, so...

[Cyanide]

It works on the red clsn boxes rather than the blue. You can have targetted overrides and define exactly which spark is to show up. Otherwise you'd have to do a weird helper/player mish mash, and it wouldn't work as clsn2's would both be hit at once, so logically you should still take the damage. The reversal takes effect before the "hit" bit and even if the red overlaps the blue you won't take a hit regardless of anything.

[PlasmoidThunder]

So basically it'd be better to use HitOverride if you were doing a counter move where the character still takes damage (basically Dudley's Cross Counter). I also take it that even if they don't have collision hitboxes, ReversalDef will still allow you to put the opponent into a custom state?

[Niitris]

Weirdly enough the way CvS2 and other games handle reversal detection, hit override would be the more accurate of the two.

But yeah HitOverride is too limited, mainly because what Cyanide said. You won't be able to get P2 in a custom state if they have complete invincibility Better to use ReversalDef. Yes, ReversalDef forces P2 into the custom state, boxes or not.

About Cross Counter: Yeah. It doesn't force P2 a different state, so it's basically a parry with an auto attack.

[PlasmoidThunder]

So HitOverride would be better for what I'm achieving. Thanks!

[JustNoPoint]

When using FF3 I see all these options are available. These should probably be added to the 1st post with descriptions

type = ReversalDef
trigger1 =
reversal.attr = S,NA           ;SCA,NA,SA,HA,NP,SP,HP,NT,ST,HT

pausetime = 0,0 Sets the pause for the Root or Helper hitting and the root or helper getting hit


sparkno = S1500, Overrides P2 hitspark?

;sparkxy = 0,0 ;offset The sparkxy parameter is treated as an offset to P2's hitdef's sparkxy. The MoveHit trigger can be used to detect if P1 successfully reversed P2

hitsound = S1,0 Sound upon hit

p1stateno = The stateno P1 changes to on hit

p2stateno = The stateno P2 changes to on hit

Are all of these descriptions correct?

[DarkWolf13]

Yes, they're all correct.

[Rajaa Retired]

You can also use the "ID" parameter for reversaldefs. Might want to add that. Useful with gethitvar(chainid).

[JustNoPoint]

Thanks! Added!

[JustNoPoint]

I saw Jesuszilla use numhits as a parameter. What other values work for reversaldef? I'll have to test some more parameters it seems

[Cyanide]

Hitflag oddly enough. Need it for projectile interactions to actually make the projectile go away iirc.

[2OS]

Additionally, there is a glitch in the Reversaldef controller which causes Player1 to retain Player2's target information even after Player2 returns to an Idle state. This allows Player1 to use target-based state controllers such as TargetState and TargetLifeAdd, as well as the Target redirection trigger, when they would normally not be allowed to. Through specific coding, it is possible to utilize this glitch to replicate a "damage-over-time" effect such as Poison. Please see these threads for more info.

there is another glitch where if this is done with helpers and the helpers destroyself, any helper that spawns from that point onwards is automatically a target. this plus ""rootchangestate"" through projectile is how the character F1 is killed.

[Odb718]

Added the Example ReversalDef at the top with the few things we've discovered.
I used Fighter factory 3 and tacked on the standard hitdef under it.
p1sprpriority =
and
p2sprpriority =
Both lit up like they worked.
ID and HitFlag show like they dont. FF3 will show these as issues but they seem to work in Mugen 1.0. I dont get any debug flood when using them.

[2OS]

for the record regarding the glitch that disallows targetdropping; you don't actually need to reverse anything. reversaldef simply needs to exist (even in the most undefined way possible). if you have a hitdef in the same state and it hits your target will still remain indefinitely.

Code Select Expand


[State ]
type=reversaldef
trigger1=1
reversal.attr=acs,aa,ap,at
ignorehitpause=1
persistent=1

[State ]
type=hitdef
trigger1=
attr=
ignorehitpause=1
persistent=1


[jaede_]

Apparently there's a glitch with this controller specifically for Player 2 (i haven't tested with Simul because lol Simul), I tested this in MUGEN 1.0

What apparently happens is that those extra parameters like ID seem to work on the Player 1 side but apparently DO NOT in the player 2 side. As in, MUGEN completely seems to ignore these in the player two side.

For example:

Code Select Expand


[State 0, ReversalDef]
type = ReversalDef
trigger1 = animelemtime(4)>=0 && animelemtime(5)<0
reversal.attr = SCA,NA,SA,HA           ;SCA,NA,SA,HA,NP,SP,HP,NT,ST,HT
pausetime = 0,0
sparkno = -1
;sparkxy = 0,0 ;offset
hitsound = S1000,11
;p1stateno = 4001
;p2stateno = 4050
id = 4000
;ignorehitpause =
;persistent =

[State 1000, CS]
type = changestate
trigger1 = movecontact
trigger1 = numtarget(4000)
trigger1 = target(4000),ishelper=0
value = 4001


This will NOT trigger for P2 side, it will simple do the reversaldef and act as a Super Armor of some sorts. (basically how a reversaldef acts if it doesn't have a changestate or p1stateno.)

However if you change the following controller to THIS:

Code Select Expand


[State 1000, CS]
type = changestate
trigger1 = movecontact
trigger1 = numtarget
trigger1 = target,ishelper=0
value = 4001


IT WORKS (for P2 and P1 now)!! But, there's a little problem coming up as well...

Now let's say this attack has multiple states and multiple targetstates, targetlifeadds, all that. Now let's assume state 4001 has the following targetstate:

Code Select Expand


[State 4001, TS]
type = targetstate
trigger1 = animelemtime(1)=0
value = 4050


This will work, but there's a catch apparently, if you change to ANY OTHER STATE via this way, for player 2 side, the effects of TargetState,TargetLifeAdd,TargetPowerAdd,etc. will only be affecting your target for the first tick of that state and then is completely dropped.



Now you might be asking why not just use p1stateno, this is because we cannot separate a helper from the main character otherwise, and then we would end up with clones.

How to fix this?

I assumed that the only way that a target would drop was if there was no reason to keep said target, and I think MUGEN dropped the target because the reversaldef was not being asserted anymore after that first tick. Since a reversaldef has more or less similar properties as a hitdef, then I thought that you could keep the target in if the reversaldef stayed in one way, and apparently the way to do this is by using hitdefpersist = 1 on each of the statedefs of the move you're coding.

I really wonder why this actually happens only for P2. But I assume that the coding for ReversalDef is significantly incomplete for P2 and can be unstable compared to what you'd expect from P1's side.

PS: I checked all of youmu's negative states and nothing that could screw this up via extra target states would trigger at a point like this.

[Archimonde]

Additionally, there is a glitch in the Reversaldef controller which causes Player1 to retain Player2's target information even after Player2 returns to an Idle state. This allows Player1 to use target-based state controllers such as TargetState and TargetLifeAdd, as well as the Target redirection trigger, when they would normally not be allowed to. Through specific coding, it is possible to utilize this glitch to replicate a "damage-over-time" effect such as Poison. Please see these threads for more info.

there is another glitch where if this is done with helpers and the helpers destroyself, any helper that spawns from that point onwards is automatically a target. this plus ""rootchangestate"" through projectile is how the character F1 is killed.

It's called Konsen which many of Japanese author called that glitch you mentioned above

[Archimonde]

for the record regarding the glitch that disallows targetdropping; you don't actually need to reverse anything. reversaldef simply needs to exist (even in the most undefined way possible). if you have a hitdef in the same state and it hits your target will still remain indefinitely.

Code Select Expand


[State ]
type=reversaldef
trigger1=1
reversal.attr=acs,aa,ap,at
ignorehitpause=1
persistent=1

[State ]
type=hitdef
trigger1=
attr=
ignorehitpause=1
persistent=1


The simple reason is Reversaldef using the same address with Hitdef in character memory. So whenever there is a hitdef are activating behind the reversaldef. That reversaldef effect will be overwritten by the hitdef after it.

[JustNoPoint]

If you wish to have a helper be immune to reversaldefs be sure that theu have a hitoverride set for everything that you want them to be immune for.

Even if you have them without CLSN or nothitby