Extending Prevstateno

[Renzo F]

With this trick you can extend the functionality of PrevStateno, so you can know which state was previous to the previous state (or any number of ChangeStates back to the past)

The code is quite simple, and its applications are mainly used in the AI programming.


;This goes inside state -1 or -2
;(or -3 if you don't want to perform the check while in custom states)
[State -n, 3 States back to the past]
type = Varset
trigger1 = time=1
var(2) = var(1)

[State -n, State previous to the previous state]
type = Varset
trigger1 = time=1
var(1) = var(0)

[State -n, Previous state]
type = Varset
trigger1 = time=1
var(0) = prevstateno


You can also add more "iterations" by adding something like:

[State -n]
type = Varset
trigger1 = time=1
var(x+1) = var(x)

[Messatsu]

You should know that this doesn't track all previous state numbers, only the one that Mugen itself tracks via prevStateNo.  In any given tick a large number of states can be entered.  I should probably do testing, but as each new state gets entered within the same tick, I'm unsure of how or if the negative states get checked to track the states not remarked by prevStateNo.

[Renzo F]

Didn't thought about that, but given the fact that we check time=1, rather than !time we are already missing the states that change when time=0. 

[Winane]

Messatsu:
On each tick, the negative states are processed, and then the regular states.  There's no going back from the latter to the former within a tick.  Well, unless you count using KeyCtrl or Player-type helpers.
And yes, PrevStateNo gets updated with each state transition within a tick.  So if, in a single tick, you go from State 0 to 1 to 2, and then check the value of PrevStateNo, it'll return 1, not 0 (the previous tick's final StateNo).


Anyway, another alternative to Renzo's code, if you don't want to have the "time=1" limitation, and if you want to ignore transitions from one state back into itself, would be the following (completely untested) code:

[State -n, PrevPrevPrevStateNo]
type = Varset
trigger1 = PrevStateNo != var(0)
trigger1 = PrevStateNo != StateNo
var(2) = var(1)
IgnoreHitPause = 1

[State -n, PrevPrevStateNo]
type = Varset
trigger1 = PrevStateNo != var(0)
trigger1 = PrevStateNo != StateNo
var(1) = var(0)
IgnoreHitPause = 1

[State -n, PrevStateNo]
type = Varset
trigger1 = PrevStateNo != var(0)
trigger1 = PrevStateNo != StateNo
var(0) = PrevStateNo
IgnoreHitPause = 1

[Messatsu]

Something I just noticed is that prevstateno won't record state 0 as the last state or doesn't appear to after a fight has started at least.  In my Cody character, it'll go 500, 0, and then to 505.  It can only reach 505 if 500 was the prevstateno.

[Winane]

What?  Either I don't understand what you mean, or I've encountered no such problems in my latest mangled KFM.

[Kung Fu Man]

Winane: Might be worth taking into account if you haven't already, but certain triggers seem unable to function on time = 0 in the minus states and will always return false in such instances...IIRC that includes PrevStateNo.

[Renzo F]

I remember detecting state 0 as one of the previous states in in at least two character's AI code.
I tested it and works perfectly.

[Messatsu]

Nevermind.  Gross misinterpretation on my part.

[Elix]

[State -n, PrevPrevPrevStateNo]
type = Varset
trigger1 = PrevStateNo != var(0)
trigger1 = PrevStateNo != StateNo
var(2) = var(1)

[State -n, PrevPrevStateNo]
type = Varset
trigger1 = PrevStateNo != var(0)
trigger1 = PrevStateNo != StateNo
var(1) = var(0)

[State -n, PrevStateNo]
type = Varset
trigger1 = PrevStateNo != var(0)
trigger1 = PrevStateNo != StateNo
var(0) = PrevStateNo

This code was indeed completely untested. Well, I've tested it and it works partially. PrevStateNo works like clock. PrevPrevStateNo doesn't work for all crouching and standing attacks. It displays all aerial states oerfectly though ??? PrevPrevPrevStateNo works even less.

[Winane]

Works fine for me.  ???  I've added "IgnoreHitPause = 1" to each VarSet just now, to be safer, though.
Are you sure you don't have any overlapping variables?


KFM:
Good point, thanks, I should've mentioned that.  (I wouldn't say they "return false", though.)

For anyone wondering what KFM's referring to, there's some more details in this thread at RS:
http://randomselect.piiym.net/forum/index.php?topic=1162.0