Question about a code snippet in the archive

[..]

http://mugenguild.com/forumx/index.php?topic=43756.0;all 

In this link under super/hyper armor, I'm mainly looking at step 2. Is that step still referring to putting that portion inside the move state or in the armor state? And if in the move, which animation number goes there (the current move animation or something else)?

[Byakko]

Since that bit of code is before SorrowEdge even talks about adding the armor state, logically this goes in the move state. As for the animation number, since we're in the middle of amove and it's telling to go to a given animation number and there is no mention of any other animation change, logically this is the current move's animation you have to put there, because how else are you going to display the move if this piece of code says to change animation ?

[..]

That's what I thought, just wanted to make sure before I fully tried it out. Thanks. I just thought there might be some kind of conflict if the move itself started with a changeanim sctrl with the same time = 0 trigger inside of that hitdef.

[Byakko]

It's for when you come back to the state after going through the armor state. ... Though it seems to me like you should also remove the anim line in the state definition, replacing it with this block...

[..]

Aight, thanks again. I have another question though. When hit, it goes to the armor state and then reverts back to the move that was done before the armor state kicked in. The problem is, when it goes back to the prevstate, it restarts it at time = 0 instead of the time where it left off. This means if I got a rapid hitting char and kept hitting the armored person, that the armored person would never come from out of the state their in because the animtime resets to the very beginning of the animation. What could I use so that it can continue where it left off instead of starting completely over?

[Byakko]

HIDDEN TEXT HERE==>http://mugenguild.com/forumx/index.php?topic=43756.msg264640#msg264640
Hum, if you removed the "anim = " line in the definition of the state, and replaced it with the changeanim you asked about just now, the one triggered by " && anim != [number]", then it shouldn't do that.

[..]

I had removed the 'anim =' already because it looped the anim when hit. And now it stays in place. I mean, if its one hit then its fine. But this particular move is like a move where if you hold the button down, that part of the move charges longer. If i just let the button go and let the move proceed, then everything is ok. But if i were to hold the button for a long time and the enemy hits me repeatedly, it would never proceed with the move unless the enemy stops hitting me. I think it has something to do on how the charging is done with the move. Here are the changestates for the charges:

[State 3100, ]
type = ChangeAnim
trigger1 = anim != 3101 && animtime = 0 && (command != "holdb" || command != "holdc")
value = 3101

[State 3100, ]
type = ChangeAnim
trigger1 = anim != 3101 && time = 89 && (command = "holdb" && command = "holdc")
value = 3101


The first one is no charge (when i dont hold the buttons).
The second one is when i hold the buttons. If i hold the buttons past 89 ticks, it will automatically release the move.
Im thinking i should change the way the time is in the second one. When i look at the debug, everytime when hit, the time goes back to 0 but the animation remains intact. I think the move isnt proceeding because the time is not getting past 89 because of the last sentence. But in what way can I so that it will go smoothly with the armor?

-Trying gametime trigger or ignorehitpause while waiting-

[Byakko]

Uuuhh....
The point of this super armor code is to send you back to your state and use the same anim you had when you got hit.
First, obviously "time" will reset when you get back to your attack state. That's the entire point of this trigger. Second, if you have two different animations in that state, and you didn't memorize which one you were in when getting hit, then you'll obviously get back to the first one.

The first problem is that you're using two animations in the same state. First thing to do is to split the move into two statedefs - the first for charging, the second for anim 3101.
Second, If you get hit, when going through the armor state and back to the attack state, obviously the "time" trigger starts back at 0. For how long you can hold the button (89 ticks) you're going to need to use a variable. Pick an unused variable, set it at 0 at the beginning of the move (with prevstateno != [armor state] as a trigger, you need that), make it count up as long as you hold the button (a varadd triggered constantly during the charge state), if you get hit you go to armor state then back to charge state and the var isn't reset, it keeps couting up, and when it reachs 89, you changestate. If you have enough free variables, you can just leave this one at the value it's at, it will just reset the next time you get into the state.

[..]

Aight, gotcha. Tryin it out now.



Edit: Got it, everything is flowing smoothly. Just so onlookers can follow:

;inside super
[State 3100, charge_timer_start]
type = VarSet
trigger1 = !time && prevstateno != 939; <----- prevstateno prevents counter from starting from 0 when coming back from armor state
var(43) = 0; <-------starts the timer from the beginning when move starts (!time = beginning of move)

[State 3100, ]; <--------move is released when not holding either of the responding buttons in trigger1
type = ChangeAnim
trigger1 = anim != 3101 && animtime = 0 && (command != "holdb" || command != "holdc")
value = 3101

[State 3100, ];<----releases move if those same buttons are held down and the timer exceeds its limit
type = ChangeAnim
trigger1 = anim != 3101 && var(43) >= 89 && (command = "holdb" && command = "holdc")
value = 3101


;negative states
[State -1, Palm_Charge_Countdown]; 1 value number is added if the timer is below 90 going at a rate of 1% of gametime
type = VarAdd
trigger1 = var(43)<90 && (gametime%1) = 0
v = 43
value = 1

[State -1, DisplayToClipboard] ;<---- shows that var 43 is working properly in debug mode
type = DisplayToClipboard
trigger1 = time
text = "var(43) = %d"
params = var(43);<----- displays the counting up of the actual timer (var(43)) in debug mode





P.S.: Thanks for your assistance again Byakko.

[Byakko]

[State 3100, ]; <--------move is released when not holding either of the responding buttons in trigger1
type = ChangeAnim
trigger1 = anim != 3101 && animtime = 0 && (command != "holdb" || command != "holdc")
value = 3101

[State 3100, ];<----releases move if those same buttons are held down and the timer exceeds its limit
type = ChangeAnim
trigger1 = anim != 3101 && var(43) >= 89 && (command = "holdb" && command = "holdc")
value = 3101

For the record, you can simply merge those two into
[State 3100, ]
type = ChangeAnim
triggerall = anim != 3101
trigger1 = !animtime && (command != "holdb" || command != "holdc"); <--------move is released when not holding either of the responding buttons in trigger1
trigger2 = var(43) >= 89 && (command = "holdb" && command = "holdc");<----releases move if those same buttons are held down and the timer exceeds its limit
value = 3101
and the varadd can be put in your state 3100 instead of state -2 as
[State 3100, Palm_Charge_Countdown]; 1 value number is added if the timer is below 90 going at a rate of 1% of gametime
type = VarAdd
trigger1 = var(43)<90
v = 43
value = 1
Because Mugen reads the state every tick, it will read that piece of code every tick during state 3100, and as long as the var is < 90, it will find that the trigger is true and do the varadd. You don't need the var to count up if you aren't in the charge state anyway, so there's no problem in putting the varadd inside the charge state.