The F+SP advancing hook punch looks odd at close range. Byakko, did I do the method you suggested correctly?
Okay, yeah, the f+HP looks extremely weird. I think that when you split a sprite in two frames and moving one, you didn't move the correct frame, and then you skipped a posadd.
Let's take the transition from the first to second sprite, for example.
If I look at the current alignment of the sprites, if I wanted to make the posadd look good, I would need to move the second sprite -see X axis- 32 pixels forward. But that's too big, bigger than the width, and if the enemy is in contact with your width and is too small themself, a posadd of 32 pixels would slip past them - your axis would be sent behind their axis. so we split that sprite in two elements.
I'm adding an extra frame, where the one in the middle is moved forward a certain amount of pixels (here, 17). So if I still want the animation to look good, I want to move that sprite forward to reach the total of 32 I noted earlier. So on that second element, I use a posadd of 32-17=15. With both the offset and the posadd, the sprite will look like the left foot is still on the same spot it was on the first element.
Then, the third element is the same second sprite, but back to an X axis of 0 (as opposed to the axis offset of 17 above). My objective here is to have this left foot be in the same position it was in the first element (and the second). From the first element, I noted that I wanted a total posadd of 32 ; then on the second element, I used a posadd of 15 with an offset on the sprite of 17. This should have resulted in the left foot moving 32 pixels forward - so at the same spot it was in the first element.
Now, the third element needs to catch up, and it only needs a posadd of 17 pixels - the amount of the offset from the previous element.
... Looking at your constants, you use a width of 16, so I'll change all the above values to 16 (since 16+16=32 just the same as 15+17=32), but I'm keeping the description above so that it's more obvious where I use which value.
Likewise, on element 5 to 7, I wanted a total posadd of about 38, so element 6 has an X axis of 18 and a posadd of 20 (total 38, element 6 looks like it moves 38 pixels forward as I want it to), and element 7 has an X axis of 0 and a posadd of 18, so between elements 5 and 7, the total posadd is 38, which is what I want.
.... Yeah, 20 is still too big for the width of 16. To make it perfect, you can split it once more adding one more element.
Here's a quick fix for those two bits :
Spoiler: The AIR (click to see content)
[Begin Action 226]
Clsn2: 3
Clsn2[0] = -4, -104, 14, -84
Clsn1[1] = -21, -93, 19, -35
Clsn2[2] = -28, -35, 22, 0
226,0, 0,0, 1
Clsn2: 3
Clsn2[0] = 13, -104, 31, -84
Clsn2[1] = -4, -93, 36, -35
Clsn2[2] = -11, -35, 39, 0
226,1, 16,0, 1
Clsn2: 3
Clsn2[0] = -4, -104, 14, -84
Clsn1[1] = -21, -93, 19, -35
Clsn2[2] = -28, -35, 22, 0
226,1, 0,0, 1
Clsn2: 3
Clsn2[0] = -6, -104, 12, -84
Clsn2[1] = -21, -93, 19, -35
Clsn2[2] = -28, -35, 22, 0
226,2, 0,0, 2
Clsn2: 3
Clsn2[0] = 0, -104, 18, -84
Clsn2[1] = -22, -94, 18, -36
Clsn2[2] = -25, -36, 25, -1
226,3, 0,0, 4
Clsn2: 3
Clsn2[0] = 17, -107, 35, -87
Clsn2[1] = -5, -95, 35, -37
Clsn2[2] = -25, -37, 25, -2
226,4, 18,0, 1
Clsn2: 3
Clsn2[0] = -1, -105, 17, -85
Clsn2[1] = -27, -92, 13, -34
Clsn2[2] = -37, -35, 13, 0
226,4, 0,0, 4
Clsn2: 3
Clsn2[0] = -4, -104, 14, -84
Clsn1[1] = -21, -93, 19, -35
Clsn2[2] = -28, -35, 22, 0
226,5, 0,0, 1
Clsn2: 3
Clsn2[0] = 10, -104, 28, -84
Clsn2[1] = -7, -93, 33, -35
Clsn2[2] = -14, -35, 36, 0
226,5, 14,0, 3
Clsn1: 1
Clsn1[0] = 9, -91, 75, -76
Clsn2: 3
Clsn2[0] = -4, -104, 63, -76
Clsn1[1] = -21, -93, 19, -35
Clsn2[2] = -28, -35, 22, 0
226,6, 0,0, 6
Clsn2: 3
Clsn2[0] = -4, -104, 63, -76
Clsn1[1] = -21, -93, 19, -35
Clsn2[2] = -28, -35, 22, 0
226,7, 0,0, 6
Clsn2: 3
Clsn2[0] = -4, -104, 14, -84
Clsn1[1] = -21, -93, 19, -35
Clsn2[2] = -28, -35, 22, 0
226,8, 0,0, 2
Clsn2: 3
Clsn2[0] = -4, -104, 14, -84
Clsn1[1] = -21, -93, 19, -35
Clsn2[2] = -28, -35, 22, 0
226,9, 0,0, 3
Clsn2: 3
Clsn2[0] = -4, -104, 14, -84
Clsn1[1] = -21, -93, 19, -35
Clsn2[2] = -28, -35, 22, 0
226,10, 0,0, 1
Clsn2: 3
Clsn2[0] = -4, -104, 14, -84
Clsn1[1] = -21, -93, 19, -35
Clsn2[2] = -28, -35, 22, 0
226,11, 0,0, 1
(watch out, I moved the clsn2 boxes around a bit quickly when I moved the alignment of the elements I fixed, so you may want to take a second look at them)
Spoiler: the CNS (click to see content)
[State 626, PosAdd]
type = PosAdd
trigger1 = AnimElem = 2
x = 16
[State 626, PosAdd]
type = PosAdd
trigger1 = AnimElem = 3
x = 16
[State 626, PosAdd]
type = PosAdd
trigger1 = AnimElem = 4
x = 14
[State 626, PosAdd]
type = PosAdd
trigger1 = AnimElem = 5
x = 18
[State 626, PosAdd]
type = PosAdd
trigger1 = AnimElem = 6
x = 20
[State 626, PosAdd]
type = PosAdd
trigger1 = AnimElem = 7
x = 18
There's the same weirdness from elements 7 to 9, try to fix it the same way. Use the onion skin on the first frame (element 7) to move the next one (element 8 ) so that the foot that's planted on the ground stays keeps its position, that gives you the total posadd, then split that in the same way I did.
Don't hesitate to use the pause key and then the scroll lock key to see the elements and at which point they move forward. You want to see the foot that's on the ground stay in the same spot all the time. Do that all the time for this stuff.
By the way, you've got alignment issues. In most animations, the left foot (viewer's right) is above the ground by a few pixels. You should align the sprites so that both feet touch the ground - in the stance, for example, the left heel needs to touch the ground.
