YesNoOk
avatar

Hitdef ground.type: Trip versus Non-trip with 0 yvelocity (Read 2986 times)

Started by Ricepigeon, June 10, 2013, 08:37:41 pm
Share this topic:
Hitdef ground.type: Trip versus Non-trip with 0 yvelocity
#1  June 10, 2013, 08:37:41 pm
  • *****
  • Mega Klinklang confirmed
    • USA
    • ricepigeon.webs.com

  • Online
Alright, well looking through my characters, I'm noticing that the attacks with a Trip type cause the value of fall.defenceup in p2's cnd file to become active. Someone recommended that I avoid using the Trip type for these attacks, and looking at the ground.type paramter for Hitdefs in the docs:

Quote
ground.type = attack_type (string)
This is the kind of attack if P2 is on the ground. Choose from: - "High": for attacks that make P2's head snap backwards. - "Low": for attacks that hit P2 in the stomach. - "Trip": for low sweep attacks. If you use "Trip" type, the ground.velocity parameter should have a non-zero y-velocity, and the fall parameter should be set to 1. A tripped opponent does not bounce upon falling on the ground. - "None": for attacks that do nothing besides pause P1 and P2 for the duration in the pausetime parameter.

If P2 is hit from behind, "High" will be displayed as "Low" and vice-versa. P2's animation for "High" and "Low" types will be superseded if the AnimType parameter is "Back". Defaults to "High" if omitted.

I'm wondering if setting the type to Low and simply setting the value of fall.yvelocity will replicate this behavior without any quirks that I may not be aware of and if doing so is recommended. If I'm not mistaken, going ahead with this will end up forcing p2 not to use the specific trip animation in their AIR file, but I want to know if there's a way to circumvent this or if theres an alternate method of circumventing the fall.defenceup thats hardcoded into the engine, since most people leave that value at 50 and never touch it.

<<-- Updated 09/14/14

You limit yourself so badly when you try to avoid variables. When you get over your fear of the "complexity" of variables, you will find yourself in a better place: A beautiful world where coding is actually fun.
Re: Hitdef ground.type: Trip versus Non-trip with 0 yvelocity
#2  June 13, 2013, 01:01:33 am
  • ****
  • [MUFFLED ROCK MUSIC PLAYING IN THE DISTANCE]
    • Chile
    • koakoa@jabber.org
I'd often use modified states having the code from common1.cns but altered slightly for the occassion:

Code:
;---------------------------------------------------------------------------
; HIT_TRIP (shaking) (Modified)
[Statedef 470]
type    = A
movetype= H
physics = N
velset = 0,0

[State 5070, 1]
type = ChangeAnim
trigger1 = 1
value = 5070

[State 5070, 2]
type = ChangeState
trigger1 = HitShakeOver
value = 471

;---------------------------------------------------------------------------
; HIT_TRIP2 (fall through air) (Modded)
[Statedef 471]
type    = A
movetype= H
physics = N

[State 5071, 1]
type = HitVelSet
trigger1 = Time = 0
x = 1
y = 1

[State 5071, 2] ;Acceleration
type = VelAdd
trigger1 = 1
y = GetHitVar(yaccel)

[State 5071, 3] ;Hit ground
trigger1 = Vel Y > 0
trigger1 = Pos Y >= 15
type = SelfState
value = 5110

Then afterwards in the state that has the hit that needs that state, I add the following controller:

Code:
[State TState]
type = TargetState
triggerall = numtarget(<hit_ID>)
trigger1 = movehit=1 && !movereversed
trigger1 = !target(<hit_ID>),ishelper
trigger1 = target(<hit_ID>),time=0 && target(<hit_ID>),movetype=H
value = 470
ID = <hit_ID>
ignorehitpause = 1

Not sure if this will circumvent the common behaviors, but if they are hardcoded I'm sure they only specifically work for state 5070/5071, but it's worth a shot.

Update:
Forgot to mention not to use Trip type, as well as fall =1 ground.type=Low, and you should be fine ^^'
Last Edit: June 13, 2013, 01:11:09 am by Koa-Devil
Re: Hitdef ground.type: Trip versus Non-trip with 0 yvelocity
#3  June 13, 2013, 11:54:35 am
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
Quote
Then afterwards in the state that has the hit that needs that state, I add the following controller:

Code:

    [State TState]
    type = TargetState
    triggerall = numtarget(<hit_ID>)
    trigger1 = movehit=1 && !movereversed
    trigger1 = !target(<hit_ID>),ishelper
    trigger1 = target(<hit_ID>),time=0 && target(<hit_ID>),movetype=H
    value = 470
    ID = <hit_ID>
    ignorehitpause = 1


Not sure if this will circumvent the common behaviors, but if they are hardcoded I'm sure they only specifically work for state 5070/5071, but it's worth a shot.
You also need to add a
trigger1=target,stateno!=[120,155]
line in there, otherwise hitting a helper (which won't be your target thanks to hitoverride) and then making contact with the guarding player (who will be a target instead) will force the guarding player to the custom state. In other words it makes the attack unblockable when guarding near one of your hittable strikers if the attack is capable of hitting both. Also, the moveguarded trigger will not work for this, if I remember well, it doesn't work when movehit is already set.
Re: Hitdef ground.type: Trip versus Non-trip with 0 yvelocity
#4  June 13, 2013, 07:15:01 pm
  • ****
  • [MUFFLED ROCK MUSIC PLAYING IN THE DISTANCE]
    • Chile
    • koakoa@jabber.org

You also need to add a
trigger1=target,stateno!=[120,155]
line in there, otherwise hitting a helper (which won't be your target thanks to hitoverride) and then making contact with the guarding player (who will be a target instead) will force the guarding player to the custom state. In other words it makes the attack unblockable when guarding near one of your hittable strikers if the attack is capable of hitting both. Also, the moveguarded trigger will not work for this, if I remember well, it doesn't work when movehit is already set.


Yikes, didn't notice that. Oughta change that for a few characters right now.
Re: Hitdef ground.type: Trip versus Non-trip with 0 yvelocity
#5  June 13, 2013, 10:30:31 pm
  • *****
  • Mega Klinklang confirmed
    • USA
    • ricepigeon.webs.com

  • Online
Quote
Then afterwards in the state that has the hit that needs that state, I add the following controller:

Code:

    [State TState]
    type = TargetState
    triggerall = numtarget(<hit_ID>)
    trigger1 = movehit=1 && !movereversed
    trigger1 = !target(<hit_ID>),ishelper
    trigger1 = target(<hit_ID>),time=0 && target(<hit_ID>),movetype=H
    value = 470
    ID = <hit_ID>
    ignorehitpause = 1


Not sure if this will circumvent the common behaviors, but if they are hardcoded I'm sure they only specifically work for state 5070/5071, but it's worth a shot.
You also need to add a
trigger1=target,stateno!=[120,155]
line in there, otherwise hitting a helper (which won't be your target thanks to hitoverride) and then making contact with the guarding player (who will be a target instead) will force the guarding player to the custom state. In other words it makes the attack unblockable when guarding near one of your hittable strikers if the attack is capable of hitting both. Also, the moveguarded trigger will not work for this, if I remember well, it doesn't work when movehit is already set.

The same can be said of a guarding opponent's partner who also gets hit, but doesnt block, because fuck simul

<<-- Updated 09/14/14

You limit yourself so badly when you try to avoid variables. When you get over your fear of the "complexity" of variables, you will find yourself in a better place: A beautiful world where coding is actually fun.
Re: Hitdef ground.type: Trip versus Non-trip with 0 yvelocity
#6  June 13, 2013, 10:33:28 pm
  • ****
  • [MUFFLED ROCK MUSIC PLAYING IN THE DISTANCE]
    • Chile
    • koakoa@jabber.org
Re: Hitdef ground.type: Trip versus Non-trip with 0 yvelocity
#7  June 13, 2013, 10:57:55 pm
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
Quote
The same can be said of a guarding opponent's partner who also gets hit, but doesnt block, because fuck simul
True but in that case, even target,stateno!=[120,155] won't save you from custom stating the guarding player, because the target redirection will, or at least might redirect to the non-guarding one as they are also a target. It only works on strikers because the hitoverride on those prevent them from becoming a target. So yeah, fuck simul. There is no way to make even something as simple as targetstate work properly in it.
Re: Hitdef ground.type: Trip versus Non-trip with 0 yvelocity
#8  June 14, 2013, 08:14:35 pm
  • *****
  • Mega Klinklang confirmed
    • USA
    • ricepigeon.webs.com

  • Online
Best solution would be to have it drop a target and keep one, which isnt going to make a difference in single, but at least it solves the guarding problem in simul. Except now you have a new issue with hitting both opponents, one trips and the other doesnt, because fuck simul

<<-- Updated 09/14/14

You limit yourself so badly when you try to avoid variables. When you get over your fear of the "complexity" of variables, you will find yourself in a better place: A beautiful world where coding is actually fun.
Re: Hitdef ground.type: Trip versus Non-trip with 0 yvelocity
#9  June 14, 2013, 08:28:24 pm
  • ****
    • Hungary
    • seravy.x10.mx/Wordpress
Quote
Best solution would be to have it drop a target and keep one, which isnt going to make a difference in single, but at least it solves the guarding problem in simul.
If only it was possible to specifically drop the guarding target. Otherwise it might drop the one that actually needs to be targetstated and targetstate the guarding one instead. Oh yeah.
+The issue you mentioned, too.
Re: Hitdef ground.type: Trip versus Non-trip with 0 yvelocity
#10  June 14, 2013, 08:37:36 pm
  • ****
  • [MUFFLED ROCK MUSIC PLAYING IN THE DISTANCE]
    • Chile
    • koakoa@jabber.org
Simul itself already is game breaking enough, you got two characters that can indefinitely do things that wouldn't be possible if it were one on one such as trapping a character between two characters with light jabs. Not to mention enemynear redirection gets all screwed, targets that shouldn't be targeted, p2 related triggers being relative to p2 or p4... This is the reason I don't design characters for simul no more, it really takes the infinity out of MUGEN.