YesNoOk
avatar

ground.velocity = -1 does nothing? (Read 1318 times)

Started by SaltAddict, October 03, 2021, 10:57:44 PM
Share this topic:
ground.velocity = -1 does nothing?
#1  October 03, 2021, 10:57:44 PM
  • avatar
  • ***
    • Portugal
For some reason, setting the ground.velocity x parameter on my hitdef to -1 causes the opponent to not move at all when hit? I've found that the enemy only starts moving when the ground velocity is at least -1.18.

For what is worth, I'm using inktrebuchet's code to cancel the opponent's friction, but I've tried removing it and it doesn't change anything.

Spoiler, click to toggle visibilty

No other targevelsets are involved, and all my other hitdefs with speeds faster than -1 work fine.

The hitdef in question:

Spoiler, click to toggle visibilty

Is this a MUGEN glitch?
Re: ground.velocity = -1 does nothing?
#2  October 04, 2021, 01:26:01 AM
  • ****
  • it's me
  • Maybe something different
    • Chile
    • koakoa@jabber.org
    • Skype - koakumadevil69
    • cowabungamugenteam.weebly.com
I'm using MUGEN 1.0.
I copypasted your hitdef code onto a fresh KFM and replaced the hitdef and the opponent still moves, even with the friction cancel code. It's just really hard to notice the total movement since it's about approximately slightly less than 6-7 pixels at a ground.velocity of -1 in 16 frames.
Re: ground.velocity = -1 does nothing?
#3  October 04, 2021, 01:45:17 PM
  • avatar
  • ***
    • Portugal
I'm using MUGEN 1.0.
I copypasted your hitdef code onto a fresh KFM and replaced the hitdef and the opponent still moves, even with the friction cancel code. It's just really hard to notice the total movement since it's about approximately slightly less than 6-7 pixels at a ground.velocity of -1 in 16 frames.

But if there is no friction, shouldn't he be moving 16 pixels?
Re: ground.velocity = -1 does nothing?
#4  October 04, 2021, 03:03:04 PM
  • ****
  • it's me
  • Maybe something different
    • Chile
    • koakoa@jabber.org
    • Skype - koakumadevil69
    • cowabungamugenteam.weebly.com
So I decided to take a more thorough look at the velocities via displaytoclipboard and I think I came across a nasty engine quirk with hit velocities. I was hitting Training by Stupa and KFM to test this.

If by any chance the absolute value of the velocity of an imparted hitdef becomes less than 1 (haven't tested this with positive values) it will just set it to zero regardless of what happens. Notice i said less than 1, however I assume there is a bit of a frame delay in the code capturing the value of enemynear,vel x (A thing that happens with negative states), since by that point the friction multiplier will be applied to the velocity and 0.85 is less than 1, the value of the targetveladd gets set to 0.

Why -1.18 works is because 1.18*0.85 = 1.003, barely enough to pass 1, and that's the value that's being read by the targetvelset, effectively working, but with the wrong value (1.003 instead of 1.18) because of the 1 frame delay (with the code in -2).

This doesn't happen if the opponent is hit with a crouching attack, they perfectly slide backwards as you'd expect, the full distance.

My bad if this explanation isn't clear, hope somebody can explain this more clearly if needed. The characters were only moving a single pixel as a result of this with the -1 value.
Re: ground.velocity = -1 does nothing?
#5  October 04, 2021, 05:55:07 PM
  • avatar
  • ***
    • Portugal
My bad if this explanation isn't clear, hope somebody can explain this more clearly if needed. The characters were only moving a single pixel as a result of this with the -1 value.

No, I think I understand. Is this delay affecting other values too (I.e I put in -2 and the actual velocity is -1.7)? I'm away from my computer right now so I can't run any tests.

Re: ground.velocity = -1 does nothing?
#6  October 04, 2021, 07:15:25 PM
  • ****
  • it's me
  • Maybe something different
    • Chile
    • koakoa@jabber.org
    • Skype - koakumadevil69
    • cowabungamugenteam.weebly.com
Is this delay affecting other values too (I.e I put in -2 and the actual velocity is -1.7)?

Yeah, It does delay the other values from what I tested, so it should at least mantain the velocity of -1.7.
Re: ground.velocity = -1 does nothing?
#7  October 04, 2021, 08:44:22 PM
  • avatar
  • ***
    • Portugal
Is this delay affecting other values too (I.e I put in -2 and the actual velocity is -1.7)?

Yeah, It does delay the other values from what I tested, so it should at least mantain the velocity of -1.7.

Okay, so I've just tested this and it doesn't seem to be true. I had the opponent display his x velocity to the clipboard and it says -2 throughout 16 frames of the hit state. To make sure, I also had him record his x position at the beginning of the hit and after the hit; he's moved 32 pixels.

Meanwhile, with a hit velocity of -1, his x velocity never goes above 0, and he moves exactly 1 pixel.
Last Edit: October 04, 2021, 08:50:56 PM by SaltAddict
Re: ground.velocity = -1 does nothing?
#8  October 04, 2021, 09:33:36 PM
  • ****
  • it's me
  • Maybe something different
    • Chile
    • koakoa@jabber.org
    • Skype - koakumadevil69
    • cowabungamugenteam.weebly.com
Oops, I think I realized why that was happenning, I was testing these behaviors with the friction removal code disabled at that point, that piece of code actually compensates for the friction applied in the 1 frame delay between the negative states, however since that 1 frame delay still stands, with a velocity of -1, by the end of the first frame they will indeed move 1 pixel back, then the engine will multiply the value by 0.85 because of the standing friction, by the way it's hardcoded realize it's less than 1 and then stop the movement, and yeah by practice it seems any value above around 1.179 will not cause this to happen.
Re: ground.velocity = -1 does nothing?
#9  October 04, 2021, 11:53:50 PM
  • avatar
  • ***
    • Portugal
Oops, I think I realized why that was happenning, I was testing these behaviors with the friction removal code disabled at that point, that piece of code actually compensates for the friction applied in the 1 frame delay between the negative states, however since that 1 frame delay still stands, with a velocity of -1, by the end of the first frame they will indeed move 1 pixel back, then the engine will multiply the value by 0.85 because of the standing friction, by the way it's hardcoded realize it's less than 1 and then stop the movement, and yeah by practice it seems any value above around 1.179 will not cause this to happen.

Thanks for your help with this! I ended up using a hitdef id to disable the friction cancel for that move and just applied a regular targetvelset instead:

Code:
[state -2 hit velocity for neutral jump kick] 
type = targetveladd
trigger1 = numtarget(1)
trigger1 = target,movetype = H
trigger1 = fvar(37)>0 ; slide timer
trigger1 = target,statetype = S || target,statetype = C
x = -1
ignorehitpause = 1