Mugen Engine Bugs

[Seravy]

This is a list of mugen engine bugs I found so far. In case any of these is not true, let me know. Otherwise, it is a useful list to read for everyone.

1. If you use StateNo=-1 in the Hitoverride controller, even though the documents say it doesn't change your state, it does even less...It has no effect at all, you still take damage and go to the proper 50xx state, as though there was no Hitoverride in effect at all.
2. Destroying helpers can cause memory leaks which makes the engine halt with an exception. This happens only if you destroy a helper that has already created helpers and/or explods, and you didn't remove/destroy those helpers yet (or are removing them during the samer tick). Both times I encountered this error, the helper had a high amount of helpers or explods out (20+), with the same ID number. (first case the helper spawned copies of itself, second, it spawned explods with the same ID number)
3.  The affectteam parameter cannot make a player hit himself. A helper can hit his player with no problems.
4.  In a HitDef controller's attr string, the first half is ignored and the statetype is used instead as far as I could tell. So a Standing State with a hitdef attr= A, NP will make an S,NP attack instead.
5. Even if a helper has Pausemovetime=999999, after the helper gets hit, it can no longer move during pauses.

Anyone who knows other bugs are welcome to add it as well.

Also something that's not a bug but is worth mentioning :
Something becomes a target when it is hit by your attack, and only stays that way for that one tick.
This means modifying opponent life and power without hitting them (and making them change states) is not possible.

I found out these the hard way, wasting a lot of time trying, so I hope it will be useful to know.

[Cyanide]

3.  The affectteam parameter of a HitDef doesn't work. (You need to use Lifeadd, etc to "hit" yourself)

Thats only true if you're doing the attacking. If it's a helper, or a projectile, they will quite happily hit you after being launched.

I'm unsure about 4, and i've mentioned it needs to be tested in order to work out what and when it does anything.

[Seravy]

Actually it WAS a helper that did the attacking. And I also tried the projectile instead of hitdef method. Both cases, only the opponent took damage, so either it was not working or the syntax is different from what was in the documentation. If you were able to make it work, please post a working implementation of the code.

For 4, my guess is, it only matters for projectiles.

[Cyanide]

Well this was in one of my old characters (gotenks) with his ghost helpers

Both
[State 6050, 1]
type = HitDef
trigger1 = Time >= 0
attr = S, HA
animtype  = Medium
damage    = 150,50
guardflag = MA
pausetime = 1,5
getpower = 15
sparkno = S6410
sparkxy = 10,0
hitsound   = S14,0
guardsound = S15,0
ground.type = high
ground.slidetime = 22
ground.hittime  = 11
ground.velocity = -1
air.velocity = -1,-1
air.fall = 1
affectteam = F
and
[State 6050, 1]
type = HitDef
trigger1 = Time >= 0
attr = S, HA
animtype  = Medium
damage    = 150,50
guardflag = MA
pausetime = 1,5
getpower = 15
sparkno = S6410
sparkxy = 10,0
hitsound   = S14,0
guardsound = S15,0
ground.type = high
ground.slidetime = 22
ground.hittime  = 11
ground.velocity = -1
air.velocity = -1,-1
air.fall = 1
affectteam = B
allowed the ghosts to hit gotenks. Didn't know much back then and used a load of uneccessary triggers to stop the attack hitting twice, but this works perfectly well.

[felineki]

DefenseMulSet only gets applied to combos. (IIRC, in an older version of Mugen it was more intuitively applied to all damage?)

Cornerpush is busted, only functions when opponent is completely in the corner at the moment they're hit.

[Seravy]

Ok, I tried affetteam, and this time it worked. Wonder why it didn't before...perhaps a stray nothitby controller somewhere?

[Seravy]

Discovered another bug :

Attacks that have their hitdef trigger on the first tick of the attack (time=0), seems to be sometimes unguardable. I had two characters, using the same cns file (Physically same on the disk), with the same attack code (including the hitdef), and the attack of one character was guardable, the other one wasn't. The only difference between the two characters was the size and placement of the clsn boxes. After changing the hitdef to trigger at time=1, both characters started to work properly.
I assume, changing to defense does take time to handle for the engine, and depending on the order of character codes executed, it might end up hitting before the defending change is handled if both happen in the same tick. It is the first time I noticed it so I don't know how often this happens.

[XRedDragonClawsX]

This is a list of mugen engine bugs I found so far. In case any of these is not true, let me know. Otherwise, it is a useful list to read for everyone.

1. If you use StateNo=-1 in the Hitoverride controller, even though the documents say it doesn't change your state, it does even less...It has no effect at all, you still take damage and go to the proper 50xx state, as though there was no Hitoverride in effect at all.
2. Destroying helpers can cause memory leaks which makes the engine halt with an exception. This happens only if you destroy a helper that has already created helpers and/or explods, and you didn't remove/destroy those helpers yet (or are removing them during the samer tick). Both times I encountered this error, the helper had a high amount of helpers or explods out (20+), with the same ID number. (first case the helper spawned copies of itself, second, it spawned explods with the same ID number)
3.  The affectteam parameter of a HitDef doesn't work. (You need to use Lifeadd, etc to "hit" yourself)
4.  In a HitDef controller's attr string, the first half is ignored and the statetype is used instead as far as I could tell. So a Standing State with a hitdef attr= A, NP will make an S,NP attack instead.
5. Even if a helper has Pausemovetime=999999, after the helper gets hit, it can no longer move during pauses.

Anyone who knows other bugs are welcome to add it as well.

Also something that's not a bug but is worth mentioning :
Something becomes a target when it is hit by your attack, and only stays that way for that one tick.
This means modifying opponent life and power without hitting them (and making them change states) is not possible.

I found out these the hard way, wasting a lot of time trying, so I hope it will be useful to know.

Okay. I honestly feel that #3-5 are not accurate.
#3 The affectteam parameter was most likely created that way to prevent hitting yourself. It would look completely awkward. Overlapping collision boxes 1 and 2 would cause a self-hit.

#4 Both sections of the attr parameter are used. It helps determine the behavior effect it has on the opponent. Ie: attr: S,NA - Puts the opponent in a standing get hit state. Determines what can/can't be blocked.

#5 States are not checked once a player has been hit, helper or not.


For #2, that one may be questionable.

[Rajaa Retired]

i'd say number 2 goes along the line as, Helpers that are summoned at exactly the same time cause lag, while helpers that destroyself at the same time cause MAJOR LAG. I guess the explods and stuff that the helper summons only adds nasty frosting to the cake.

I never saw helpers spawn a copy of themselves like that, i dealt with  lot of helpers at one time; so that part is very questionable.

[Seravy]

Maybe it only crashes for me? I wonder. I don't get any lag, I get an exception error message.
For #3, it works as I already found out so I'll change that.
For #5, I meant that if it has pausemovetime, and gets hit, after the hit ends, and the helper goes back to state 0 and anything after, he still cannot move, as the pausemovetime is reset/ignored.
For #4 If I have a S,NA hitdef and an A for Statetype in the statedef of the same state, the attack misses an opponent with NothitBy for A, and hits one for S. That's what I meant.

[MikeDaBike]

#4 Both sections of the attr parameter are used. It helps determine the behavior effect it has on the opponent. Ie: attr: S,NA - Puts the opponent in a standing get hit state. Determines what can/can't be blocked.

To put the opponent into a standing hit state you use forcestand=1 in the hitdef. If the S attribute would do that, you would find your opponent standing in mid air if you hit him.

I did a little testing for the hit attr and its true, the first half is ignored, your statetype is used instead.

But I found another problem considering the NotHitBy controller, that I think was discussed in the forum before.
It doesnt work the way you would think.
For example if you put this into your state 0:
[State 0, NotHitBy]
type = NotHitBy
trigger1 = 1
value = S,NA
time = 1
What happens? Every normal attack (C and A too) will miss and every Standing attack (throw and proj. too). Maybe it's wrong to call this a bug, I think it could be intended to work that way.

The HitBy controller seems to work as expected though. So if you want to test the attr parameter in the Hitdef controller better use the HitBy controller.

[Seravy]

Yes, the Nothitby works exactly that way.
Problem is,

NothitBy
Value= S, NA

does the exact same thing as

HitBy
value = CA, SA,HA,AP,AT

Basically listing all attacks left out from Nothitby in a Hitby does the same thing according to the documentation and according to my tests, in reality too.
That means, making a Nothitby for only standing normal attacks is impossible this way, if you want to be immune to only those more complicated methods need to be used like a hitoveride, when S,NA actually works that way. Unfortunately hitoverride doesn't work without changing states, so it's pretty complicated to do it without affecting your character somehow.
This is not a bug, it's only lack of common sense and lack of a very important feature... (found this out when I made the Cloud card for Sakura which should have given immunity to Air non-hyper non-throw type attacks)

[Seravy]

I found a new one :

6.When using NoKo to prevent knockout for a period of time, even if you gain life and go above 0, the engine remembers you had 0 life at a point and makes you lose the fight as soon as the NoKo effect ends.
This only applies if your character continues fighting with 0 life for some time, if he gains back the life in the same tick (basically having more than 0 at the end of every tick), he is safe.

[Cyanide]

6.When using NoKo to prevent knockout for a period of time, even if you gain life and go above 0, the engine remembers you had 0 life at a point and makes you lose the fight as soon as the NoKo effect ends.
This only applies if your character continues fighting with 0 life for some time, if he gains back the life in the same tick (basically having more than 0 at the end of every tick), he is safe.

Under the last normal release of mugen NoKO is not documented. In addition, it's one of the things that has been "discovered" within the engine itself. Most likely it is an incomplete flag. Just like tagin and tagout are incomplete. And things like helpertype = projectile is not implemented. It probably IS a bug, but it's a bug in a feature that's not meant to be made use of yet.

[DeFrenZ]

DefenseMulSet only gets applied to combos. (IIRC, in an older version of Mugen it was more intuitively applied to all damage?)

and it's value also work in the opposite way as it's documented

[XRedDragonClawsX]

6.When using NoKo to prevent knockout for a period of time, even if you gain life and go above 0, the engine remembers you had 0 life at a point and makes you lose the fight as soon as the NoKo effect ends.
This only applies if your character continues fighting with 0 life for some time, if he gains back the life in the same tick (basically having more than 0 at the end of every tick), he is safe.

Under the last normal release of mugen NoKO is not documented. In addition, it's one of the things that has been "discovered" within the engine itself. Most likely it is an incomplete flag. Just like tagin and tagout are incomplete. And things like helpertype = projectile is not implemented. It probably IS a bug, but it's a bug in a feature that's not meant to be made use of yet.

Would you mind explaining more about these tags, and how they are formatted? Are they controllers or what?
Tagin
Tagout
NoKO

[Cyanide]

I think the docs uploaded here on guild describe them.


tagin
tagout
assertspecial
NoKO is an assertspecial as you know or you wouldn't be talking about it. I can't really tell you more than you already know about that one. Like i say, they're there, but they're not complete and we don't have real documentation on how they're MEANT to act, just what they currently do/don't do.

Better not to use them rather than deal with odd bugs that aren't really supported

[Seravy]

#7 : The vel parameter of the ModifiyExplod controller is not working.
#8 : using the scale parameter of Angledraw disables transparency. Even if you use the Trans controller. I found no way so far to use dynamic scaling and transparency together.

[Hadoabuser]

#7 : The vel parameter of the ModifiyExplod controller is not working.

Works fine for me.

[Rajaa Retired]

#7 : The vel parameter of the ModifiyExplod controller is not working.
#8 : using the scale parameter of Angledraw disables transparency. Even if you use the Trans controller. I found no way so far to use dynamic scaling and transparency together.

you have to use the trans sctrl.