Solved Frames not respecting movea command

[ipkevin]

I'm trying to create a dragon punch-style move. So it's a flying uppercut where I use the move & movea commands to create the look of the punch going up and down in the air in a nice arc. The problem: The frames do not seem to move the y distance specified, especially on the way down. Look at the code sample below -- it should be a smooth arc. The first 3 frames go up 40px, 10px, 5px, and the next 3 frames go down -5px, -10px, -40px. Then there is a final frame landed.png that has movea 0. I expect the last 2 frames should already be on the ground, but instead I see both of them in the air! The last frame even starts in the air then drops straight down.

Can anyone have a look and tell me if there's an error in my code?

Notice the movea values go 40, 10, 5, -5, -10, -40, 0. My understanding is the -40 frame should be displayed back on the ground, but it's not and neither is the next frame which has movea 0. Does this match your understanding of how movea works? Or have I totally misunderstood it?

attack    61 2 29 120 40 6 0 0 35 0
delay    8
move    15
movea    40
frame    data/chars/terry/moves/uppercutjump/finished/upper1.png
movea    10
frame    data/chars/terry/moves/uppercutjump/finished/upper2.png
movea    5
frame    data/chars/terry/moves/uppercutjump/finished/upper3.png
movea    -5
frame    data/chars/terry/moves/uppercutjump/finished/upper4.png
attack    0 0 0 0 0 0 0 0 0 0
movea    -10
frame    data/chars/terry/moves/uppercutjump/finished/upper5.png
movea    -40
frame    data/chars/terry/moves/uppercutjump/finished/upper6.png
movea    0
move    0
frame    data/chars/terry/moves/uppercutjump/finished/landed.png

 

[danno]

I would use jumpframe and landframe if I were you, you'll get a much smoother animation and landing, like this

jumpframe 0 4 2
landframe 6
attack    61 2 29 120 40 6 0 0 35 0
delay    8
frame    data/chars/terry/moves/uppercutjump/finished/upper1.png    # frame 0
frame    data/chars/terry/moves/uppercutjump/finished/upper2.png    # frame 1
frame    data/chars/terry/moves/uppercutjump/finished/upper3.png    # frame 2
frame    data/chars/terry/moves/uppercutjump/finished/upper4.png    # frame 3
attack    0 0 0 0 0 0 0 0 0 0
frame    data/chars/terry/moves/uppercutjump/finished/upper5.png    # frame 4
delay    900
frame    data/chars/terry/moves/uppercutjump/finished/upper6.png    # frame 5
delay    20
frame    data/chars/terry/moves/uppercutjump/finished/landed.png    # frame 6

 

[DCurrent]

...

I will go a bit farther. Don't use offsets or move commands for movement, full stop. That's a huge rookie mistake. Move{} commands are for making minor position adjustments. Offsets are not for creating movement any time, ever. I mean never. Don't do it. No, not even then.

While taking @danno's advice, there's also dropframe {frame}. Your animation skips forward (not backward) to {frame} as soon as the entity reaches peak height and starts to fall. Also (@danno, this is for you too), instead of trying to code long delays before land/dropframes, use an infinite delay. How? Easy, just make your delay negative. I like -1000 as a nice round number.

Observe my Ryu's Shoryuken:

anim freespecial12 # Shoryuken
    
    energycost 10
    mponly 1
    
    jumpframe 3 5 0.4 0 jump_liftoff
    dropframe 4
    landframe 10 jump_land
    
    loop 1 8 10    
    range 10 72
    
    delay    5
    offset    82 147
    
    frame    data/chars/ryu/shoryuken_0.png    
    
    @cmd    dc_fidelity_quick_play DC_FIDELITY_TYPE_SOUND_ATTACK_HEAVY
    @cmd    dc_fidelity_quick_play "Shoryuken"    
    
    frame    data/chars/ryu/shoryuken_1.png
    
    attack.damage.force 19
    attack.position.x 90
    attack.position.y 59
    attack.reaction.fall.force 1
    attack.reaction.fall.velocity.x 1.5
    attack.reaction.fall.velocity.y 5.0
    attack.reaction.fall.velocity.z 0
    attack.reaction.pause.time 12
    attack.size.x 56
    attack.size.y 39
    
    frame    data/chars/ryu/shoryuken_2.png

    delay -1000

    bbox.position.x 75
    bbox.position.y 28
    bbox.size.x 26
    bbox.size.y 50
    
    attack.damage.force 16
    attack.position.x 89
    attack.position.y -3
    attack.reaction.fall.force 1
    attack.reaction.fall.velocity.x 1.5
    attack.reaction.fall.velocity.y 5.0
    attack.reaction.fall.velocity.z 0
    attack.reaction.pause.time 12
    attack.size.x 46
    attack.size.y 85
    
    frame    data/chars/ryu/shoryuken_3.png
    
    delay 5
    
    frame    data/chars/ryu/shoryuken_4.png   
    
    attack.damage.force 0
    attack.position.x 0
    attack.position.y 0
    attack.size.x 0
    attack.size.y 0
    
    bbox.position.x 75
    bbox.position.y 31
    bbox.size.x 32
    bbox.size.y 75
    
    frame    data/chars/ryu/shoryuken_5.png
    frame    data/chars/ryu/shoryuken_6.png    
    frame    data/chars/ryu/shoryuken_7.png
    
    # Loop start
    frame    data/chars/ryu/shoryuken_8.png

    # Loop End    
    frame    data/chars/ryu/shoryuken_9.png
    
    bbox.position.x 69
    bbox.position.y 48
    bbox.size.x 37
    bbox.size.y 101
    
    frame    data/chars/ryu/shoryuken_10.png
    
    bbox.position.x 69
    bbox.position.y 56
    bbox.size.x 35
    bbox.size.y 91
    
    frame    data/chars/ryu/duck_start_0.png
    
    bbox.position.x 66
    bbox.position.y 77
    bbox.size.x 43
    bbox.size.y 73
    
    frame    data/chars/ryu/duck_start_1.png
    
    bbox.position.x 69
    bbox.position.y 56
    bbox.size.x 35
    bbox.size.y 91
    
    frame    data/chars/ryu/duck_start_0.png

DC

 

[Kratus]

@DCurrent
Thanks for the "dropframe" tip, I never used it before.
It's a lot easier than calculate delays before switching to the correct "falling" frame.

 

[ipkevin]

@danno and @DCurrent

Thank you for the info on jumpframe/dropframe/landframe -- I have perfect arcs now! What a great set of features.

Question about jumpframe: How does openbor determine how long to make the jump last for? It does not seem tied to the number of frames in the animation since you can make all the frames play long before the jump has even finished. I'm wondering if it's possible to make a jumpframe attack move faster while keeping the exact same arc (same height and distance moved, just faster).

I will go a bit farther. Don't use offsets or move commands for movement, full stop. That's a huge rookie mistake. Move{} commands are for making minor position adjustments. Offsets are not for creating movement any time, ever. I mean never. Don't do it. No, not even then.

What do you recommend for a ground attack that takes a few steps forward before punching? Jumpframe with speedy=0?

 

[DCurrent]

Question about jumpframe: How does openbor determine how long to make the jump last for?

It doesn't. Jumps, falls and such work just like the real world. There's a global gravity in place that constantly adjusts velocity downward. All entities are affected by it unless set otherwise. To jump or whatever else, the entity is given a one time upward vertical velocity (in OpenBOR, it's called a toss). Gravity eventually overcomes the toss velocity and the entity falls back to base level.

DC

 

[ipkevin]

To jump or whatever else, the entity is given a one time upward vertical velocity (in OpenBOR, it's called a toss).

Ah, I see. Thanks!