In the sf3 games, if you hit your opponent with an attack that knocks down, but then while he's falling hit him with one that does not knock down, he will recover from his fall.e.g.: shoryu ken makes him fall -> light punch makes him recoverThought about adding it for ryu, and here's what i came up with (after trying other much more complicated but less efficient stuff):Code: [State -3, autoairrecover]type=hitfallsettrigger1=stateno=5050value=!(gethitvar(type)!=3&&gethitvar(yveladd)<=0&&prevstateno!=5080&&pos y<=-20)gethitvar(type)!=3 ->char wasn't trippedgethitvar(yveladd)<=0 ->char wasn't hit downwardsprevstateno!=5080 -> char wasn't OTGpos y<=-20 -> so that the char won't recover too close to the groundThe ! before all of that makes it so that if all these conditions are true, hitfall is set to 0What it basically does is reset the hitfall attribute once it has served its purpose (after state 5035), so that next time the char gets hit he'll only fall if the attack knocks down.EDIT: replaced with the new and improved version that i've been using since some time ago and been forgetting to post
O_O AWSOME I THINK THIS IS WORTH ALOT >> I MEAN ... Exuce me there Ahem, thanks for the code i been trying to figure that out.
First post tip makes your character air recovery always behave like in SF3 when being hit.To make characters you hit with your character behave like that, without having to include the first post tip in all of them, the best I could come up with so far is three steps:1) In your HitDefs, use the ID parameter. Give, where possible, all attacks that should produce this special recovery behavior (i.e. all attacks that do not knock down) the same ID. This is no problem if you don't use HitDef IDs for anything else. If you are already using HitDef IDs and need most of them to be different from each other, this method can still be used, but it will grow in code-size regarding step 3).2) In your character, include state 5020 from the common1.cns, but modified like so:Quote; Custom HITA_SHAKE[Statedef 5021]; change the statedef number to 5021type = Amovetype = Hvelset = 0, 0[State 5021, this is it]; this is the important modification. everything else here is just copied from 5020 and optimized a bit - except the other bolded part, the SelfState further downtype = HitFallSettrigger1 = !timevalue = ifelse(alive, 0, -1)[State 5020, 1]; Anim for HIT_LIGHT to HIT_HARDtype = ChangeAnimtrigger1 = !Time && (GetHitVar(animtype) != [3, 5])value = ifelse((GetHitVar(airtype) = 1), 5000, 5010) + GetHitVar(animtype)[State 5020, 2]; Anim for HIT_BACKtype = ChangeAnimtrigger1 = !Time && (GetHitVar(animtype) = [3, 5])value = 5030[State 5020, 3]; Anim for HIT_UP/HIT_DIAGUP (only if it exists)type = ChangeAnimtrigger1 = !Time && (GetHitVar(animtype) = [4, 5]) && (SelfAnimExist(5047 + GetHitVar(animtype)))value = 5047 + GetHitVar(animtype); 5051 - 4 + type[State 5020, 4]; Freeze animtype = ChangeAnimtrigger1 = Timevalue = anim[State 5020, 5]; in common1.cns this is a ChangeState - but we want to put the opponent back in his own states where he belongstype = SelfStatetrigger1 = HitShakeOvervalue = 5030[State 5020, FFB Light]type = ForceFeedbacktrigger1 = anim = 5000 || anim = 5010persistent = 0time = 6waveform = square[State 5020, FFB Medium]type = ForceFeedbacktrigger1 = anim = 5001 || anim = 5011persistent = 0time = 8waveform = sinesquareampl = 110, -1, -.3[State 5020, FFB Hard]type = ForceFeedbacktrigger1 = anim = 5012 || anim = 5002 || anim = 5030 || (anim = [5051, 5059])persistent = 0time = 15waveform = sinesquareampl = 1403) Now after step 1) all attacks that should bring about SF3 air recovery behavior have a certain HitDef ID. In my example, this ID is 200. Under StateDef -3 add:Code: [State -3, opponent falling behavior]type = TargetStatetriggerall = numtarget(200)trigger1 = target(200), alive && target(200), hitfallvalue = 5021ignorehitpause = 1It works like this: If you have hit an opponent with an attack that does not knock down (attack with ID 200) & this opponent is still alive & he has the hitfall flag set, put this opponent into our modified state 5021. There, his hitfall flag will be correctly set to 0, and he will not fall when he is put back in his own states.There are two drawbacks I can think of. The first is when you need different HitDef IDs for different attacks, for example if you're using them for a custom-made AI. In this case, you will run into a problem with step 3). More or less, you would have to have as many instances of the opponent falling behavior code block as you have unique HitDef IDs and just list all possible HitDef IDs. One with numtarget(200) and target(200), one with numtarget and target(210) and so on. This bloats the code up, but otherwise that's it.The other potential drawback is that this method does put the player you hit out of his own states for a bit. I have been using this method for some months now in Mike Bison, Chunli and Guile and have not encountered oddities. The risk remains, however, that the character you hit and put into your 5021 state behaves strangely because of he has himself special bevaviors defined for state 5020 that you would force him to skip by putting him in your state 5020-equivalent.
... Some chars have their AI that can recover when they shouldn't be able to (example : Warusaki's boss chars, shôryuuken them and they'll recover extremely fast), can adding this prevent them from doing so ? i.e can it work the other way around, preventing them from recovering.
Byakko said, July 30, 2005, 03:23:27 pm... Some chars have their AI that can recover when they shouldn't be able to (example : Warusaki's boss chars, shôryuuken them and they'll recover extremely fast), can adding this prevent them from doing so ? i.e can it work the other way around, preventing them from recovering.I never even thought of that.... >> and i just used the code lol. no wonder its a bit buggy. thanks for the advice. still good to know on other hand, maybe it can be imporved so it wont effect already recovering characters
Byakko said, July 30, 2005, 04:48:34 pmQuotethanks for the advice.What, me ? That wasn't an advice, that was a question you can take it basicly both ways, the question is basic statement with provides advice that wasnt really thought of untill this point of time. thats why i said thanks for the advice, but i just i should stated, thanks for bringing up this certain Issue.
Byakko said, July 30, 2005, 03:23:27 pm... Some chars have their AI that can recover when they shouldn't be able to (example : Warusaki's boss chars, shôryuuken them and they'll recover extremely fast), can adding this prevent them from doing so ? i.e can it work the other way around, preventing them from recovering.warusaki3's characters on AI recover automatically with high probability, and yeah I think it's possible they ignore the fall.recovertime parameter of the hits they catch since the trigger used is GetHitVar(fall.recover) instead of CanRecover. This is something we could mention to warusaki if it's really the case, will confirm later.But on topic and to answer the question:No, this code does not really damage automatic recovery codes such as warusaki's. Such recovery is commonly decided in state 5050, and if my code kicks in the hit char never reaches 5050 (knocked up, falling) at all and goes to 5040 (recovering in air, not falling) instead. Difference is, the character recovers in 5040 instead of 5200 or 5210 but eh. Recovering is recovering. XD If my code is not triggered, then the automatic recovery can kick in no problem.
i meant it as a defensive advantage, not an offensive disadvantage, so that's why it only affects the char itselfabout putting the char in a custom state so often... something i wouldn't wanthow aboutCode: [Statedef 5021]type = Amovetype = Hvelset = 0, 0[State 5021, this is it]type = HitFallSettrigger1 = !timevalue = ifelse(alive, 0, -1)[State 5021, back to self]type = SelfStatetrigger1 = !timevalue = 5020?so that the char still goes through his own 5020
GetHitVar(Type) doesn't work, constantly returns 0 (even when not hit)Code: [State -2, ghvt]type = Helpertrigger1 = gethitvar(type) = 1trigger2 = gethitvar(type) = 0stateno = 7031[State -2, ghvt]type = Helpertrigger1 = gethitvar(type) = 2stateno = 0[State -2, ghvt]type = Helpertrigger1 = gethitvar(type) = 3stateno = 198[State -2, ghvt]type = Helpertrigger1 = gethitvar(type) = 4stateno = 193[State -2, ghvt]type = Helpertrigger1 = gethitvar(type) = 5stateno = 197=>123And yes, that spark is helper 7031.And no, I don't know how Mugen makes the char go to state 5070 since there's nothing about gethitvar(type) in state 5000. Probably hardcoded.
weird, 'cause it seems to make a difference:http://rapidshare.de/files/14561187/wtfftw.rar.htmledit: nevermind, that's just because a tripped char doesn't go through state 5050yeah, forgot that gethitvars only last a tick (well, not even that, they seem to be set, read and reset in the same tick)gonna make some more tests concerning this
