Question about PotS' TickFix code

[Zzyzzyxx]

Codes like this are usually found in chars made by PotS or those who use his style of gameplay:

[State -1, Tick Fix]
type = ctrlset
triggerall = !ctrl
trigger1 = (stateno = 52 || stateno = 105 || stateno = 5120) && !animtime
trigger2 = (stateno = [200, 259]) && !animtime
trigger3 = ((stateno = [700, 701]) || (stateno = [710, 729]) || stateno = 760) && !animtime
trigger4 = (stateno = 5001 || stateno = 5011 || stateno = 151 || stateno = 153) && hitover
value = 1

I don't know the purpose of them. If they are supposed to fix some kind of bug in Mugen, what bug could it be?

[Rajaa Retired]

He seems to believe there is a problem with regaining control at the end of animations. I'm not sure how effective that is, though, seeing as how negative states activate before a character's current state, so the end of the animation would happen 1 tick after the end of the animation is reached -- which means it that wouldn't activate when that code tells it to.

I don't really know, though. I may be wrong. P.o.t.S might be the only one with the knowledge of the reasoning behind that code. Maybe it's in his greatest hits of characters feedback thread -- I never fully read it.

[Seravy]

The normal processing order :

-tick starts
-state -1 is processed (and does nothing because you don't have ctrl yet)
-state 52 or whichever else is processed and changes to state 0, giving back control
-state 0 is processed
-tick ends

With the code :
-tick starts
-ctrl is set if it's the last tick of the state
-State -1 is processed and if there is command input, you will start another attack
-If you started an attack, then the attack state is processed. The last tick of state 52, etc will not be processed. Otherwise the same thing happens as above.
-tick ends

So overall, the code makes you able to attack during the tick when the previous move ends and you appear to be doing nothing.

The problem is when you changestate and give ctrl, your character will appear in the idle animation, but there is no state -1 processing in that tick because it's already processed before the changestate. This code can fix that.

[Rajaa Retired]

Wouldn't the ctrl parameter on the changestate fix that?

[Demented Fortune Cookie]

No, it would only allow you to walk/jump/guard straight out of whichever state you were in, since you go from that state to state 0 (to walk/jump/guard state) without going through the negative ones.

PotS' (or [E]'s, I'm not sure who came up with it first) tick fix makes sense since it also allows you to attack/dodge/parry during that tick, but I don't like the way it is implemented since it can skip the last tick of whichever state you are in =/

(Pretty sure I sucked at making any sense there...)

[hjk]

This goes back to a GLITCH that I managed to prove existed in WINMugen although it would appear that it was fixed in 1.0.

When one tried to activate a changestate by using time=0 or by using a value of time within 2 ticks of the end of an animation, or even by using a value of time that only accounted for 2 ticks (i.e. time= [5,6] in an animation taht lasts for 12 ticks in total) there were times where the changestate would not trigger. I managed to do this using PotS' chars, Byakko chars, waru's chars, and Cyanide's chars. In 1.0, I found that I couldn't replicate it though, but I only tested it using Rajaa's chars (and failed) and have yet to test anyone else's and have not tested in on PotS's chars that last the code.

[E] found a fix for it resulting in [E]'s/PotS's tick fix.

I still wonder if 1.0 fixed this shitty glitch:
http://www.youtube.com/watch?v=WHvDln0qbiw

[Zzyzzyxx]

This video shows how the tick fix works:

http://www.mediafire.com/?9q5ddt7rh421lr6

In the first situation, notice that Jmorph's Ken skips from state 410 right to state 440.

In the second situation (with TickFix disabled), he changes to state 11 for 1 tick, then applies his Crouching MK.

I used command.buffer.time = 12 in Ken's cmd in order to make him apply his Crouching MK automatically while I advance frame by frame.

Thanks for the replies. This topic is now solved. Although I find strange that PotS gives control after normal attacks but not after special/supers.

[Ricepigeon]

This goes back to a GLITCH that I managed to prove existed in WINMugen although it would appear that it was fixed in 1.0.

When one tried to activate a changestate by using time=0 or by using a value of time within 2 ticks of the end of an animation, or even by using a value of time that only accounted for 2 ticks (i.e. time= [5,6] in an animation taht lasts for 12 ticks in total) there were times where the changestate would not trigger. I managed to do this using PotS' chars, Byakko chars, waru's chars, and Cyanide's chars. In 1.0, I found that I couldn't replicate it though, but I only tested it using Rajaa's chars (and failed) and have yet to test anyone else's and have not tested in on PotS's chars that last the code.

[E] found a fix for it resulting in [E]'s/PotS's tick fix.

So if it was fixed in 1.0, does that mean the code is necessary anymore? (Like how 1.0 made Winane's AI activation redundant with the addition of the AILevel trigger) Or would there still be that 1 tick issue?

[Bastard Mami]

the bug is still present just like the common state bugs that vans found while coding angel.

refer to  Zzyzzyxx's post, the way mugen works, once x state's animatino time has ended you end up wasting one tick until you regain control again, thus making you unable to block, attack, etc... the reason pots did not put the special moves in that block is that those change a lot by char as you are only supossed to put the very last state, chars that use that fix and whose creators understand why it is used also put special and super moves in there.