This thread will be used for discussing and compiling all the known and newly found reasons for MUGEN crashing. Anyone willing to contribute, go right ahead and post. It can be what caused your MUGEN to crash or a new type of MUGEN crash not yet compiled here. Thanks!
I'll update this post as often as I can.
Types of known crashes
- Typo's
- Missing files
- Broken or corrupted files
- Infinite changestates
- Non-existent coding (i.e wrong MUGEN version)
- Broken limits (commands, group number, etc.)
- Improper coding
- Clashing coding
Examples
Typo (You absolutely must have trigger1. Always.)
[state 0, velset]
type = velset
trigger2 = !time
x = 1
y = 1
Missing files (You absolutely must have 1 of these files available even if it's gonna be blank.)
[Files]
Cmd = Player.cmd
Cns =
St = Player.cns
StCommon = Basics.cns
Sprite = Player.sff
Anim = Player.air
Sound = Player.snd
Broken or corrupted files (Example is unavailable. If anyone has an image perhaps of a broken or corrupted file, leave a post below.)
Broken or corrupted files have practically become a thing of the past with the release of Fighter Factory 3
Infinite Changestates (This can be difficult to explain because there's so many ways for this to occur, but basically one way to avoid this is do NOT send yourself into a state with a command that continuously triggers if that state is going to send you back to the state you were just in.)
;---------------------------------------------------------------------------
; stand
[statedef 0]
type = s
physics = s
sprpriority = 0
[state 0, changestate]
type = changestate
trigger1 = command = "holddown"
value = 10
;---------------------------------------------------------------------------
; stand to crouch
[statedef 10]
type = c
physics = c
anim = 10
[state 10, changestate]
type = changestate
trigger1 = command = "holddown"
value = 0
Non-existent coding (A piece of coding being used in the wrong version of MUGEN is just one type of example for this type of crash. VolumeScale was not implemented until MUGEN 1.0 hence the crash when used in WinMugen.)
MUGEN Version used = WinMugen
[state 0, playsnd]
type = playsnd
trigger1 = !time
value = s0,0
volumescale = 255
Broken limits (There are many limits to break in MUGEN. One of which is having too many commands. Keep it to a minimum to avoid crashing and if you NEED said many commands, then your character probably needs to be scaled down a bit. :D)
[command]
name = "AI-0"
command = a, a
time = 0
[command]
name = "AI-1"
command = a, b
time = 0
[command]
name = "AI-2"
command = a, c
time = 0
.
.
.
.
[command]
name = "AI-299"
command = a, b, c, x, y, x, U, D, F, B
time = 0
Improper coding (Many examples can be made, but the easiest one to notice is the difference between Vars and FVars. Vars are for whole numbers ONLY much like most of everything else number related in MUGEN. FVars are for decimals AND whole numbers and can be used without much of anything breaking, but most of the time it will need to be floored because while FVars can be used for either type of number, it greatly depends on what it's being used for. Like Power for example. Power does not use decimals so the FVar would need to be floored.)
[state 0, varset]
type = varset
trigger1 = !var(0)
var(0) = 1.1
[state 0, varset]
type = varset
trigger1 = !fvar(0)
fvar(1) = 1001.9514
[state 0, powerset]
type = powerset
trigger1 = !fvar(0)
value = fvar(1)
Clashing coding (Basically, there's seemingly no reason for the crash and sometimes there won't even be an error message. The only way to find it is to backtrack as far as you can by removing everything you recently added until it stops crashing. Then you add it all back one by one while also testing testing out MUGEN each time something is added until it crashes. Once you've found the culprit and nothing's wrong with the culprit itself, then it's related to an interfering piece of coding somewhere else. Now, we leave what we think is the culprit and repeat the process again. Remove, add back one by one, test in MUGEN one code at a time until culprit is found, repeat. Once you've found the clashes, figure out why it clashes.)
In the current build of PCEA (Project Catch 'Em All),
the game crashes without error whenever we try to use a SuperPause or Pause.
I'm not sure why this is yet,
but it could have something to do with having a heavily-edited common1.cns file.
I've seen most of this kind of stuff in full games and the causes are extremely hard to track down because,
there's no error message or anything guiding you.
In Mugen 1.0, setting the character's internal name (not the displayname parameter) past a certain character limit will cause the character to be automatically KOed at the beginning of a match, among other issues.
Typo example: forgetting to close parenthesis in triggers:
[State 200, CS]
type = changestate
trigger1 = (var(20)=1 ;note that the first set of parenthesis is left often
value = 0
In Mugen 1.0, setting the character's internal name (not the displayname parameter) past a certain character limit will cause the character to be automatically KOed at the beginning of a match, among other issues.
Typo example: forgetting to close parenthesis in triggers:
[State 200, CS]
type = changestate
trigger1 = (var(20)=1 ;note that the first set of parenthesis is left often
value = 0
I've had situations where I have one worthless parenthesis in a bit of coding and it doesn't crash MUGEN and it work's just fine as well without error.
Kinda like what you've got written up there now, but with a lot more codes and shit.
Also, you mean
[Info]
name = "Alena" ;<-- this one?
displayname = "Alena"
Edit:
Haha that's weird. Added about 100 A's and my character became invincible. She could only be killed through the Mugen's F commands. She remained at 1 hp no matter what I did.
I wonder if this could be used in some way to our benefit... what happens in Training Mode I wonder.
This is an old topic but I finally made a piece of code that crashes MUGEN 1.0 with no errors. The idea is to use this in a pause menu. Quit Game
;Crash Game with no errors by Inktrebuchet
[state -2, Quit Game]
type = DisplayToClipboard
trigger1 = command = "s" ; test trigger
text = "99999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999%d "
params = 0
This causes mugen to not respond if you have more than one target.
[state n]
type = targetveladd
trigger1 = numtarget
x = target,vel x
The problem comes from mugen not knowing what target,vel x to use for x.
In Mugen 1.0, setting the character's internal name (not the displayname parameter) past a certain character limit will cause the character to be automatically KOed at the beginning of a match, among other issues.
Typo example: forgetting to close parenthesis in triggers:
[State 200, CS]
type = changestate
trigger1 = (var(20)=1 ;note that the first set of parenthesis is left often
value = 0
I don't think the character internal name did any crash. In the mugen memory, any character in the field i have only one space to store value, including internal name, and i have to say that the internal name has a same space with displayname and authorname, and that space does not include any pointer in there. so there is no reason that chars internal name can crashed mugen.
I didn't discover it, but I made use of it with that N.E.T.G.E.N joke I did last year.
You have an anim (let's say 99999 for the sake of this example) with a single frame that displays for 0 ticks, then you attempt to use ChangeAnim to switch to that anim like so:
[State n, ChangeAnim]
type = ChangeAnim
trigger1 =
value = 99999 ;Your anim number
elem = animelemno(0) ;This bit is important
M.U.G.E.N will crash without error, simply saying that it stopped responding.
Couple of interesting ones -
`PlayerSCtrlApplyElem not recognised` - 1.1 only
[State ]
type=Tag
trigger1=roundstate=2
This one crashes with a 'rare' error message, I think this is the only way to hit it normally across all versions. Cause of the issue is use of the `Tag` sctrl, which MUGEN 1.1 can parse, but not run. Therefore, the character can load with this sctrl, but as soon as it triggers, the game will crash.
%%n
[State ]
type=displaytoclipboard
trigger1=roundstate=2
text="%%n"
This one crashes with no error message. Cause of the issue is, of course, the %%n - complicated issue, but basically this will try to apply as a normal %n, causing the OS to close the application silently.
Of course these aren't realistic to hit in a character, just kind of novelties.