Link Updated (4/2/2014)!

[NapoleonJonamite]

Well, it's been a while, and I found I had a couple of things I needed to fix on Link prior to receiving his new sprites (Still in progress).

What's fixed?
-Boomerang damage bug fixed
-Sword Dive damage adjusted

What's left?
-Alt. snd with Brawl voices

Download here: http://mugencoder.com/authors/view/napoleonjonamite

[CozySquirtle]

Your Link has to be one of the more better ones I've played as since Mike's Link. Thanks for sharing such a great Link! Much appreciated! 

[Krypto 'SAM' saiyaN]

Indeed, this Link was always the best Link in mugen so far, and great you update it!

[RicePigeon]

So is this the Link that's going to replace yours? J/K... Onto the actual feedback:

• You may want to consider flagging the recovery frames of Link's attacks. As they are now, they can create false positives in counterhit detection systems (ie: opponent scoring a hit on Link during the last few moments of his recovery frames and still getting the benefits of counterhit such as increased damage and hitstun when they shouldn't).
• The hitbox on his 5Z (s.HP) could be simplified. Imo, not only would this attack look better as an overhead instead of a regular normal, but the hitbox of the sword should be extended downward to the ground to better approximate the trajectory of the sword (not to mention it would avoid the whiff on crouching opponents).
• 5A (s.LK) has a high/mid hitbox, yet the hitdef classifies its ground.type as low. It looks awkward that the sword is hitting them in the head when the opponent's gethit anim suggests otherwise.
• In addition, the hitdef for 5A allows it to hit OTG, despite the fact that the hitbox will never allow it to do so except against really large characters.
• For a standing Normal, 5B (s.MK) hitting low feels awkward, especially when the move has a 3 frame startup.
• 2A (c.LK) and 2B (c.MK) both have gethit behavior for opponents that are lying down, but the moves can never hit OTG. Additionally, they doesn't cause fall, yet allows the opponent to recover from the fall?
• The blockstun on alot of his normals are significantly longer than the hitstun. His 5X jab, for example, is +1 on hit, but +11 on block. A few exceptions are his 5Z (+5H/+5B), 5A (-3H/-13B), 5B (-4H/-4B), and Launcher (+13 on block, which is way too safe if you ask me).
• 2B and 2C (c.MK and c.HK, respectively) both whiff at point blank range
• I should note that 5A also has little to no knockback outside of the corner.
• Any reason why his forward throw throws the opponent backward and his backward throw throws the opponent forward?
• I should note that Link's launcher still causes fall if hitting an opponent already in a fall state (ie: 5C -> 2Z in corner. True, the opponent can recover out of this situation but...)

[NapoleonJonamite]

So is this the Link that's going to replace yours? J/K... Onto the actual feedback:

• You may want to consider flagging the recovery frames of Link's attacks. As they are now, they can create false positives in counterhit detection systems (ie: opponent scoring a hit on Link during the last few moments of his recovery frames and still getting the benefits of counterhit such as increased damage and hitstun when they shouldn't).
• The hitbox on his 5Z (s.HP) could be simplified. Imo, not only would this attack look better as an overhead instead of a regular normal, but the hitbox of the sword should be extended downward to the ground to better approximate the trajectory of the sword (not to mention it would avoid the whiff on crouching opponents).
• 5A (s.LK) has a high/mid hitbox, yet the hitdef classifies its ground.type as low. It looks awkward that the sword is hitting them in the head when the opponent's gethit anim suggests otherwise.
• In addition, the hitdef for 5A allows it to hit OTG, despite the fact that the hitbox will never allow it to do so except against really large characters.
• For a standing Normal, 5B (s.MK) hitting low feels awkward, especially when the move has a 3 frame startup.
• 2A (c.LK) and 2B (c.MK) both have gethit behavior for opponents that are lying down, but the moves can never hit OTG. Additionally, they doesn't cause fall, yet allows the opponent to recover from the fall?
• The blockstun on alot of his normals are significantly longer than the hitstun. His 5X jab, for example, is +1 on hit, but +11 on block. A few exceptions are his 5Z (+5H/+5B), 5A (-3H/-13B), 5B (-4H/-4B), and Launcher (+13 on block, which is way too safe if you ask me).
• 2B and 2C (c.MK and c.HK, respectively) both whiff at point blank range
• I should note that 5A also has little to no knockback outside of the corner.
• Any reason why his forward throw throws the opponent backward and his backward throw throws the opponent forward?
• I should note that Link's launcher still causes fall if hitting an opponent already in a fall state (ie: 5C -> 2Z in corner. True, the opponent can recover out of this situation but...)

 

-Not quite sure I understand the flagging thing.

-Will look into it.

-Will fix.

-Whoops, will fix.

-Should it be faster or slower? Or are you saying that a low hit is a bad thing?

-Such is the plight of using your own template without checking all the code. Will fix.

-This is referring to the hittime attributes, yes? Will adjust.

-Will extend the hitboxes some more on those.

-Will adjust.

-No reason, that's just how the code was when I copied it out of Sailor Saturn.

-Should probably remove the D in the hitflag.

 

Thanks for the feedback, Rice. I'll get to it soon.

[The Unexpected Visitor]

-Not quite sure I understand the flagging thing.

 

Changing movetype to I by using statetypeset after the active frames of an attack happen. :P

 

For example, let's say your animation contains 5 frames, on the 3rd there's the red hitbox, then the fourth and fifth one don't have them, to prevent counterbuffs triggering improperly and also helping opponent AIs not to block when not needed:

 

[state Mark them]

type = StateTypeSet

trigger1 = Animelemtime(4)>=0

movetype = I

[NapoleonJonamite]

Learn something new every day. Thanks Daniel.

[JokerintheButt]

legit char.

[Werewood]

The use of the StateTypeSet movetype change, is good for tricking the CPU A.I. (i.e. like, if AiLevel != 0, StateTypeSet movetype = I and in HitDef set guard.dist = 0 then the CPU A.I. will not know when to guard/block the attack LOL).

 

Also, the use of the StateTypeSet statetype might help simplify the traditional 3-StateDef-Shoryuken into 1-StateDef-Shoryuken.

There are more StateTypeSet usages yet only two (2) popped up in my head.

 

[EDIT]:  Your Hookshot MUGEN code is so effective and neat!  It inspires me in a way!  Nice~

[RicePigeon]

-Not quite sure I understand the flagging thing.

Dan pretty much explained it before I could. Additionally, you may also want to put movecontact and movereversed as alternate triggers, unless the move hits more than once.

 

-Should it be faster or slower? Or are you saying that a low hit is a bad thing?

Normals typically don't hit low unless its a crouching normal (though exceptions do exist, like Viper's s.LA in (U)MvC3) but even then, 3 frame startup feels too fast for a such a move, especially one that's a medium level Normal. 6 or 7 might be better values in this case, and you may want to provide a slight frame disadvantage or neutral frames as well (nothing too fancy, 0 on hit and -1, maybe even -2, on block should fit).

 

-This is referring to the hittime attributes, yes? Will adjust.

Indeed they do. Hitstun = ground.hittime, Blockstun = guard.hittime. Generally, you want your Hitstun to always be equal to or greater than your Blockstun unless the move knocks down on hit.

[NapoleonJonamite]

Got all that done (Removed the Low hit on s.MK). Only thing I can't seem to resolve is the whole thing regarding s.HK. I have adjusted the x velocity on the ground hit, adjusted all the hit corner pushes, yet it can still "chain" into the launcher. It also, sadly helps create a "corner infinite" when the Hookshot is thrown into the mix.

[NapoleonJonamite]

Updated! Just fixed a few things, and added an alternate snd file with his Brawl voice.

[NapoleonJonamite]

Updated again today! Fixed a major bug with his s.HK.

[RicePigeon]

• You may want to consider flagging the recovery frames of Link's attacks. As they are now, they can create false positives in counterhit detection systems (ie: opponent scoring a hit on Link during the last few moments of his recovery frames and still getting the benefits of counterhit such as increased damage and hitstun when they shouldn't).
• The hitbox on his 5Z (s.HP) could be simplified. Imo, not only would this attack look better as an overhead instead of a regular normal, but the hitbox of the sword should be extended downward to the ground to better approximate the trajectory of the sword (not to mention it would avoid the whiff on crouching opponents).
• 5A (s.LK) has a high/mid hitbox, yet the hitdef classifies its ground.type as low. It looks awkward that the sword is hitting them in the head when the opponent's gethit anim suggests otherwise.
• In addition, the hitdef for 5A allows it to hit OTG, despite the fact that the hitbox will never allow it to do so except against really large characters.
• For a standing Normal, 5B (s.MK) hitting low feels awkward, especially when the move has a 3 frame startup.
• 2A (c.LK) and 2B (c.MK) both have gethit behavior for opponents that are lying down, but the moves can never hit OTG. Additionally, they doesn't cause fall, yet allows the opponent to recover from the fall?
• The blockstun on alot of his normals are significantly longer than the hitstun. His 5X jab, for example, is +1 on hit, but +11 on block. A few exceptions are his 5Z (+5H/+5B), 5A (-3H/-13B), 5B (-4H/-4B), and Launcher (+13 on block, which is way too safe if you ask me). Better, but a few of them still feel off. 5A, for example, is -3 on hit but -11 on block, which is kind of lengthy difference for a light kick.
• 2B and 2C (c.MK and c.HK, respectively) both whiff at point blank range
• I should note that 5A also has little to no knockback outside of the corner.
• Any reason why his forward throw throws the opponent backward and his backward throw throws the opponent forward?
• I should note that Link's launcher still causes fall if hitting an opponent already in a fall state (ie: 5C -> 2Z in corner. True, the opponent can recover out of this situation but...) Seems 5C cant be followed up with 2Z anymore.

And as for new feedback:

 

• Guardspark on hookshot is misaligned.
• The pillar effect for the Hammer Smash, since its classified as an attack rather than a projectile, can cause some unintended behavior against anything using reversaldefs (which can ultimately end up creating clones of Link in some cases).
• Speaking of Hammer Smash, I don't see anything to differentiate between the three versions? Not a major issue, mostly just me nitpicking, but some extra variance between the three could spice things up. Also the attack feels a little too fast, though it would be fine for a light version I suppose.
• 381 damage for a level 1 on the spin attack seems WAY too high for a level 1. I know its highly unsafe on block, but when you compare it to the 481 damage caused by his level 3...
• Speaking of Triforce Slash, the super pause makes it have 0 startup frames, when its not even a grab.

[NapoleonJonamite]

• The hitbox on his 5Z (s.HP) could be simplified. Imo, not only would this attack look better as an overhead instead of a regular normal, but the hitbox of the sword should be extended downward to the ground to better approximate the trajectory of the sword (not to mention it would avoid the whiff on crouching opponents).Better, but a few of them still feel off. 5A, for example, is -3 on hit but -11 on block, which is kind of lengthy difference for a light kick.
• I should note that 5A also has little to no knockback outside of the corner.
• Seems 5C cant be followed up with 2Z anymore.
• Guardspark on hookshot is misaligned.
• The pillar effect for the Hammer Smash, since its classified as an attack rather than a projectile, can cause some unintended behavior against anything using reversaldefs (which can ultimately end up creating clones of Link in some cases).
• Speaking of Hammer Smash, I don't see anything to differentiate between the three versions? Not a major issue, mostly just me nitpicking, but some extra variance between the three could spice things up. Also the attack feels a little too fast, though it would be fine for a light version I suppose.
• 381 damage for a level 1 on the spin attack seems WAY too high for a level 1. I know its highly unsafe on block, but when you compare it to the 481 damage caused by his level 3...
• Speaking of Triforce Slash, the super pause makes it have 0 startup frames, when its not even a grab.

 

 

-I've noticed the problem with the Spin Attack. It seems to work fine if you use mugenversion=1.0, but with the winmugen version the damage gets ridiculously high. I have yet to make it stable for both versions. This maybe a problem with the open source code from LimitedMoon's Ken.

-I thought I extended s.HP's hitbox enough for the overhead (I also thought it was s.LK), guess I need to adjust it some more.

-Going to take another look at the guard.hittimes v. ground/air.hittimes. Could have sworn I had the numbers work.

-If I increase the cornerpush too much, then say goodbye to his ability to really do a chaining similar to MVC.

-Yeah, opted to slow the animation down to where it's impossible to have a chain like that. The way it was before, there was even a corner "infinite" where you could link s.HK into the Hookshot, then continue.

-Will fix. X-axis misallignment?

-Yeah, I'm probably going to turn the pillar effect into an explod and give the Megaton Hammer a hitbox. Maybe add some extra damage to each version. Reason it's so fast is that I do want it to be chained into after a normal.

[NapoleonJonamite]

Link has been updated! More fixes done.

NOTE: He has now become 1.0 exclusive due to one of the fixes involving the AI Jadeeye had originally made. If you want him to work in Winmugen, you're going to have to ask someone to patch him.

Next up, the new sprites and hopefully color separation on them.

[Kaguto Shin Sabaki]

Great job man this is the best link in mugen though I have one issue but it's small and nit picky that starting stance of his is kinda awkward lookin I really think he'd look cooler with less joint movement and more of a firm stance I looked through the sprites and the first two sprite frames to that stance animation would look just fine with a loop kinda like ryu or ken only has the same three sprite frames looping for their stance but other than my nit picking the character is on the up and up.

 

[NapoleonJonamite]

The stance is one of the things being updated with the new sprites. Just give it time, and we'll be on our way/