type = ChangeState
value = 1010
triggerall = Var(29) > 0
triggerall = statetype != A
triggerall = abs(P2bodydist X) > 150
triggerall = random < var(30)*0.6
triggerall = Prevstateno != 1010
trigger1 = ctrl

cmd read from top to bottom trumps that code.

Quote

- Code 2 does not have ctrl; it should break gethits and other states

The ignorehitpause=1 is missing from it. If a state change happens during the hitpause (which does happen in standard hit states) then prevstateno will no longer return 1000 so by the time Code 2 could activate, prevstateno is not 1000.

Spoiler, click to toggle visibilty

Example :

Code:

;---------------------------------------------------------------------------
; Stand get-hit (shaking)
[Statedef 5000]
type    = S
movetype= H
physics = N
velset = 0,0

[State 5000, 1] ;Anim for HIT_LIGHT to HIT_HARD
type = ChangeAnim
trigger1 = Time = 0
trigger1 = GetHitVar(animtype) != [3,5]
value = ifelse((GetHitVar(groundtype) = 1),5000,5010) + GetHitVar(animtype)

[State 5000, 2] ;Anim for HIT_BACK
type = ChangeAnim
trigger1 = Time = 0
trigger1 = GetHitVar(animtype) = [3,5]
value = 5030

[State 5000, 3] ;Anim for HIT_UP/HIT_DIAGUP (only if it exists)
type = ChangeAnim
trigger1 = Time = 0
trigger1 = (GetHitVar(animtype) = [4,5]) && (SelfAnimExist(5047 + GetHitVar(animtype)))
value = 5047 + GetHitVar(animtype) ;5051 - 4 + type

[State 5000, 4] ;Freeze anim
type = ChangeAnim
trigger1 = Time > 0
value = anim

[State 5000, 5] ;State type gets set to aerial if getting hit up
type = StateTypeSet
trigger1 = Time = 0
trigger1 = GetHitVar(yvel) != 0 || GetHitVar(fall)
trigger2 = Pos Y != 0
statetype = a

[State 5000, FFB Light]
type = ForceFeedback
trigger1 = anim = 5000
trigger2 = anim = 5010
persistent = 0
time = 6
waveform = square

[State 5000, FFB Medium]
type = ForceFeedback
trigger1 = anim = 5001
trigger2 = anim = 5011
persistent = 0
time = 8
waveform = sinesquare
ampl = 110,-1,-.3

[State 5000, FFB Hard]
type = ForceFeedback
trigger1 = anim = 5012
trigger2 = anim = 5002
trigger3 = anim = 5030
persistent = 0
time = 15
waveform = sinesquare
ampl = 140

[State 5000, 6]
type = ChangeState
trigger1 = HitShakeOver
trigger1 = GetHitVar(yvel) = 0 && !GetHitVar(fall)
value = 5001 ;Stand get-hit (knocked back)

[State 5000, 7]
type = ChangeState
trigger1 = HitShakeOver
value = 5030

As you can see, this is the state active during the hitpause, but as soon as the hitpause ends (Hitshakeover), the state changes to another one. It's the same for all the other common hit states. So prevstateno will be 5000 when the hitpause is already over.

Quote

- Code 2 should always cause a loop.

Not if the AI is jumping or crouching. The sequence is like this :
1. Current State : 1000, Prevstateno =0
2/a. Current State : 1000, last tick of the attack, prevstateno=0
2/b. Current State : 0, attack ended, prevstateno=1000. State -1 has already been checked for this tick before 2a, so Code 2 won't trigger.
2/c. Hardcoded AI jumps, so state changes to 40. Stateno=40, prevstateno=0. This happens between ticks
3. When process reaches state -1, Current state=40, Prevstateno=0.

[state -1, AI Jump]
type = changestate
value = 1000
triggerall = ailevel
triggerall = statetype != A
trigger1 = prevstateno = 1000

[state -1, AI Jump]
type = changestate
value = 1000
triggerall = ailevel
triggerall = statetype != A
triggerall = stateno != 0
trigger1 = p2bodydist x >= 0
trigger1 = ctrl
trigger1 = random <= 30

Quote

var(30) was meant to be for the scaling of the AI level, where the higher the difficulty the more the character would use the move, but now I see how the random backfired on me completely.

Using var(30) for AI level is the correct way, the incorrect part was probably the values you assigned for it.
A distribution of values that work well for me for the 8 difficulty levels would be something like : 2,6,11,16,24,36,55,75,120 (+/- some depending on the character), and as a general rule, I never go over the 120-200 range for the maximum difficulty because it's not going to make the AI any stronger, but instead more predictable and likely to use the same moves all the time.

Quote

- Notice at 3:07 I finally do manage to break him with Ryu; you can explain that away all you want, you'd first have to tell me why it was so consistent at first

Of course it's consistent. You are putting two determined state machines against each other. Both are essentially doing this :
"X time after I start this attack, the other guy gets hit. When the other guy gets hit, X time after that, I get hit. When I get hit, I start the attack." So they always get hit 2X number of ticks after the start of the attack by the projectile from the other one. That means a constant point of the animation. X is a constant value because they aren't knocked back from the hit, aren't moving, and the projectile is always fired at the same point of the animation and travels at a constant velocity.

Now, when you fight against him using Ryu, X is not a constant, and there is no such loop. He gets hit whenever you want, and not 2X time after the projectile. So while 2X was obviously not equal to the length of the move in state 1000, when you were jumping over the fireball and hitting him, you did manage to hit him at that tick, so what I explained before happened.
In this case, he went from state 1000 to 420, then the tick ended, clsn was processed, he got hit, entered state 5000, and then the next tick stated. At this point, prevstateno was already equal to 420, not 1000.

Quote

Can you tell me what order things are processed in as in state -1, state -2, etc.? I still don't know what the order is 

It's this :

I. State -3. If there is any changestate activated, skip the rest of state -3, but don't process the new state yet. (don't process statedef either.). This state is skipped if the character is in a custom state.
II.State -2. Same as above for changestates here. However, changestates in -3 don't skip state -2. This means that in state -2, your Stateno triggers will return the new state number, even though the statedef for that state is not processed yet (meaning if you changed into state 1000 from 5000 then Stateno will return 1000 BUT Movetype will return H, the last movetype you had before the state change.)
III. State -1. Same applies as for the above two.
IV. The current State's Statedef if it hasn't been processed yet since the entering of the state.
V.The current State.
VI. If the current state contains a Changestate, and it activates, then go to IV after that changestate is processed.
VII. If the Movetype=H and we got hit during the previous tick, take damage equal to the damage done by that attack. If there is an active binding, apply the position. (Bindtoparent, etc)
VIII. Collisions are checked. If there was a hit, the character is changed to the appropriate hit state (5xxx).
IX. Any hardcoded changes, such as AI walking, etc. happen, then proceed to I and start the next tick. This is what I usually refer as "between ticks"

Note that most of this is not documented, and is purely based on experience. A lot of it is counter-intuitive, too.

By the way, the "safe" way to avoid AI interference would be to put changestates that change out of normal states when an attack is over into state -3. Unfortunately no one does that. Not even Elecbyte. Even though not doing it will mean the character spends a tick in state 0 which is wasted because state -1 processing is already over when it is entered.

Place AI changestates in statdef 0 - 40. Problem solved? Haven't tested. Don't see why that wouldn't work.

Seravy said, January 02, 2013, 09:51:30 am

Because as soon as state 10-40 are entered, prevstateno value is already changed.

Not necessarily.