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.