Cyanide's post about his bindtime problem made me do this thread. Also, I didn't see a thread like this existing already.What are the known bugs that the Mugen engine has, how they affect, and ways to more-less fix them?I made this thread for curiosity, and if possible, to inform creators (such as myself ).
Not my bindtime problem. But there was a help thread where i mentioned it, people refuted it slightly. So i tested it and then had no backup other than my own eyes so i wanted someone else to confirm it.Known mugen issuesReversaldef and hitdef cannot be active at the same timehitoverride cancels out any hitdef with p2stateno in itCertain states in the common1.cns cannot be detected at tick 0 while using statedef -2.
Cyanide said, November 25, 2007, 01:17:53 amCertain states in the common1.cns cannot be detected at tick 0 while using statedef -2.iirc, time = 0 does not work in st-2 ; i have not tested st-1 but it should be the same case, as it looks like time is somehow updated after the state has already been entered; this is considering that ina tick mugen first reads to st-3, then st-2, then st-1, tehn your current state, then the state you change to, until it changes states 2500 times or it does not find a change state. using trigger1 =1 work on time = 0,so it must be only time not working.bug:when you enter a state with physics = A or S or C, any vel you might get is applyed friction and yaccel, but after the character arleady has moved.
R[E]ika said, November 25, 2007, 01:35:20 amCyanide said, November 25, 2007, 01:17:53 amCertain states in the common1.cns cannot be detected at tick 0 while using statedef -2.iirc, time = 0 does not work in st-2 ; i have not tested st-1 but it should be the same caseTime=0 only works for states that start on Time=-1. That's basically all states that don't require any changestates - basic movement and "get hit shake" (although you can only notice the movement starts on Time=-1 when you try to change to those states during a superpause).Time=-1, however, doesn't work even for those states that start on it.So we can say that "Time= InitialTime" doesn't work, to be more correct.After making some boring tests, I think that happens because the ChangeState functions only happen after the negative states have been processed, and before the "positive" states are processed (for ChangeStates in State -1) or while they are being processed (for ChangeStates inside positive states). Therefore, those initial ticks aren't processed in the negative states so they never detect "Time= InitialTime" but rather what the time was before changing state.That was too fast and confusing... so here's how I think all these things happen in Mugen during a tick:1) Increase Time by 12) Process negative states3) Process positive states4) Display to screenExample: Let's say a char is changing state in Time=9 when the whole process (tick, basically) starts, here's what happens:1) Time increases from 9 to 102) Nothing unusual3) Char changes state -> Time goes back to 04) Debug shows Time=0 without having shown Time=10, although the latter was fully processed (so the negative states didn't actually miss any tick)1) Time increases from 0 to 12) Time was never 0 here, so Time=0 triggers in these states don't work...Proof of sorts:Say State 200 ends after Time=10 (during Time=11), so in the debug you see the char get to Time=10 then change back to State 0 with Time=0. So then, we use an explod Sctrl in a negative state using "trigger1= Stateno=200 && Time=11".You'd think it doesn't show up, right? Wrong. It does appear because, by the time the negative state is processed, the char has yet to change states, so the Time value that is read is the one during which the char changed state: Time=11.That came out a bit confusing because I was figuring out some stuff myself while typing. EDIT: Typed all this but forgot to get to my point , I mean that Time=0 not working in negative states isn't a bug, but rather a "limitation" of Mugen's state system (or whatever you want to call it).
at pots: yeah, that is pretty much the same that i think happens. [offtopic]using an alt ctrl variable for the ai, and disable ctrl at all would be the way to completely disable mugen's default ai.
Two bugs I forgot to Report:[state -1]type = varsettrigger1 = var(59) != 1var(59) = 1Does NOT always instantly activate... (Tested 25 times and 2 times my AI did not activate on time).... You tryKen34's Old SF3 KenIt had a 100% parry for every "Idle" or "Attacking" State uncontrolled.Somehow people on YouTube (including myself) have videos of themselves actually hitting his Ken and defeating it. I am still wondering how this would be possible.
Tee Hee Hee said, December 03, 2007, 01:45:06 pm[state -1]type = varsettrigger1 = var(59) != 1var(59) = 1That's because if you change var(59), State -1 is only read again in the following tick, so that varset takes one tick to activate. Not a bug, see my above post.
if you want it to always activate, you must put it as the first thing in st-3, and even then, it owuld not activate first thing if you are in custom states.
P.o.t.S. said, December 03, 2007, 04:46:55 pmTee Hee Hee said, December 03, 2007, 01:45:06 pm[state -1]type = varsettrigger1 = var(59) != 1var(59) = 1That's because if you change var(59), State -1 is only read again in the following tick, so that varset takes one tick to activate. Not a bug, see my above post.OK so I read your above post and admittedly was confused, but I do have a reply for the post I am quoting.What I mean by the AI did not instantly activate was that there was a good noticable period of 50-60 ticks or more (guesstimating) where the AI I coded did not activate.That is something I want you all to test for yourselves. Something tells me it has something to do with the amount of characters you make Mugen process through.Reference... this post:Tee Hee Hee said, October 18, 2007, 12:46:12 amMove non-commands -> I decided to see what would happen if I simply deleted the command for taunt "s" in the CMD and make a new move with just "s" and see what happens. I deleted this and the char worked fine for a few weeks and I never touched it. Then I came into Mugen one day and I founnd that my character is only taunting whenever I press anything, even the directional buttons. NOTE: Very ImportantI noticed later that in Mugen, things can get screwed up based on the number of chars in it. I had tons of PotS and Warusaki3 edits in my Mugen Select and what do ya know, removing the ones that were piling up was the answer. . Mugen has flaws, especially when there's an overload Test that please
QuoteWhat I mean by the AI did not instantly activate was that there was a good noticable period of 50-60 ticks or more (guesstimating) where the AI I coded did not activate.Accurate test with no guesstimating needed. Just cos AI isn't doing anything instantly, doesn't mean your variable isn't on.[state -2]type = displaytoclipboardtrigger1 = var(59) != 1params = var(0)text = "%d before var activates"[state -2]type = varsettrigger1 = var(59) = 0roundstate != 2var(0) = gametime
Cyanide said, December 04, 2007, 02:56:15 amQuoteWhat I mean by the AI did not instantly activate was that there was a good noticable period of 50-60 ticks or more (guesstimating) where the AI I coded did not activate.Accurate test with no guesstimating needed. Just cos AI isn't doing anything instantly, doesn't mean your variable isn't on.I see... hmmm... *thinking about everything.*Here's the stuff i don't understand on general linesCyanide said, December 04, 2007, 02:56:15 am[state -2]type = displaytoclipboardtrigger1 = var(59) != 1params = var(0)text = "%d before var activates"What specifically do you mean by "%d"... I know it isn't directly related to Mugen itself but could you elaborate for slow people like me Cyanide said, December 04, 2007, 02:56:15 am[state -2]type = varsettrigger1 = var(59) = 0roundstate != 2var(0) = gametimeWhat is the significance in "var(0) = gametime" if that wasn't just a choice you amde to highlight your example... (that's a serious question BTW)??
1. read the displaytoclipboard sctrl documentation.2. try the code.that should answer your questions.
Actually should have used 1 for the original trigger. Don't want it to go away.Essentially what that's doing is saving gametime (how much match time has elapsed) to a variable while the AI is off. It's then displaying that value through displaytoclipboard (which you should go read up you may find it useful) until the point where the AI is activated at which point it stops giving you a solid value of when AI has been activated.
R[E]ika said, December 04, 2007, 03:35:32 am1. read the displaytoclipboard sctrl documentation.2. try the code.that should answer your questions.Cyanide said, December 04, 2007, 03:54:25 amActually should have used 1 for the original trigger. Don't want it to go away.Essentially what that's doing is saving gametime (how much match time has elapsed) to a variable while the AI is off. It's then displaying that value through displaytoclipboard (which you should go read up you may find it useful) until the point where the AI is activated at which point it stops giving you a solid value of when AI has been activated.I'll definitely be trying this out later ....... Thanks GuysI really want to know about this (edited post for here)...NoChainIDTee Hee Hee said, December 08, 2007, 08:57:20 pmWell, I decided to take some time and make two lazy additions to some chars that I really like and this makes me sad...:This is in no way meant to be an insult to anyoneAhuron's Duck King:Well, I've seen post upon post saying that Ahuron is a bad creator, but I wouldn't go so far. What I think is that he may have been a bit lazy at times, but really, I like the creations for what they are overall...:Ahuron I would call kind of negligent because:- then created a nochainID with another state.* I believe that had he tested that (unless the chars I downloaded are old versions), he would have discovered that in doing so he was effectively dooming his chars to an inability to connect any of their Attacks containing that nochainIDIdeally I don't think this (with teh NoChainID) should be happening at all in the first place and it is not the first time I have seen something like.It should regain it's ability to strike after p2 has recovered from the "GetHit"I believe I remember this same thing happening when with Byakko's Kim. This one I really want to get to the bottom of... I'm not sure if I could properly test it because the chances are that I do not fully understand it if no one has yet complained about it, being that it is so in the blue.
No there's nothing wrong with ID/chainID/nochainID either. In Duck's case, he seemed pretty concerned in not letting ID=1100 attacks combo from other attacks, yet he has none of those. ??? Probably just some leftover coding.
The HitBy and NotHitBy sctrls. Hate 'em. Forgot details. I think the last time I got mad over problems with them were with Zangief's lariats and this:[State 1110, not hit by sca projs and c attacks]type = HitBytrigger1 = animelemno(0) = [1, 9] value = sa, aa, atvalue2 = c, atignorehitpause = 1If I remember that right it doesn't really work as it should* but I eventually gave up because no other combination I tried did produce the desired "not hit by sca projs and c attacks" effect. That I used the inversion "only hit by all sa attacks, throws and c throws" and HitBy instead of the more obvious NoHitBy shows I played around with several different approaches. o.O*The resulting invulnerability is either greater or less than what the code says.
