A place to have fun with Mugen
PortalHomeFAQMemberlistSearchRegisterComic WIP TrackerDownloadsLog inChat
Translate the Website
Log in
Log in automatically: 
:: I forgot my password
Latest topics
» ---> volzzilla requests help with replies in the topics listed here <---
by volzzilla Today at 12:27 am

» Unknown Soldier by Mazemerald and LESSARD majorly updated for release
by volzzilla Today at 12:26 am

» MMV Birthday WIP Teaser - *2 Clues Given*
by Mazemerald Yesterday at 10:51 pm

» Spector Palettes
by Mazemerald Yesterday at 10:50 pm

» CvS Garuda first up!!!
by Mazemerald Yesterday at 10:49 pm

» (WIP) Kuki Sanban (Numbuh 3)
by Doom Yesterday at 9:33 pm

Special Features at MMV

Chat on MMV w/ Discord

Share | 

 Dynatron's bug exterminator guide: avoiding common coding errors

View previous topic View next topic Go down 


Posts : 180
Join date : 2014-04-24
Age : 22

PostSubject: Dynatron's bug exterminator guide: avoiding common coding errors   June 23rd 2016, 5:21 pm

People have said that I am great at finding bugs in chars. Hunting for bugs might seem really difficult at first, but it gets a lot easier once you know what common mistakes to look for. Please keep in mind, when I say "common mistakes", I don't mean to insult this forum. These are issues many Mugen creators make and have the potential of making, including creators from MFG, to MFFA, to IMT, to this place right here. A lot of these points I make can be seen on Pots's MFG post, "The greatest hits of character feedback", and I felt this site needed a similar guide to common pitfalls one could unwittingly tumble into.

- Most important, Download Training by Stupa. This is an essential tool for playtesting. During this little list, I will frequently talk about this character and how its functions can help fixing some of these issues. Download it here http://mugen.wikia.com/wiki/Training/stupa's_version
- Check if the attacks that use Power regain the users Power. Attacks that use meter, be it EX moves or Hypers, should not give power back. This tactic has never been employed in any fighting game ever, so it's generally a bad idea. To fix this, I recommend going into the hitdef of the attack and changing the getpower = 0,0. The second 0 is for chip damage.
- Normals are not supposed to use chip damage. Normals, unless the name of the game you're trying to emulate is Mortal Kombat, should not do chip damage, aka damage that occurs when the opponent is blocking. Only Specials and Hypers do this as the rule of thumb. Make the second damage value in the hitdef of the attack equal 0 for Normals.
- The Head pos and Mid pos should be accurate to the character. This lets the game know where the head and waist of the character is. You can find out if you've aligned the head pos and mid pos properly by pitting your character up against Training in the Training mode and pressing LK (or a) for the Head pos and pressing MK (or b) for the mid pos. To fix this, go to the head pos and mid pos section of the Size part in the cns to the correct values. My rule of thumb is to move the numbers to what you think is correct, then save it and load up the game again to check to see if you did it right.
- Remember to use a dampener. This makes it so that the damage gets weaker the longer a combo goes. Now, I'm no coder, but I do know one thing: Pots's damage dampener is shit tier (well, not really shit tier as much as it is outdated). The reason it's outdated is because if the char with pots's dampener gets hit by a debuff, or uses a buff, it screws with the dampener. A better alternative would be found here http://mugen.wikia.com/wiki/Damage_Scaling#Basic_Damage_Scaling_tutorial this one avoids that issue.
- Be sure to use as little hitboxes as possible. Detailed hitboxes might look professional, but having 40 of them is unnecessary when 2 or 3 could do the trick just fine. Plus, the detailed hitboxes can slow down weaker computers. You may see this as a subjective sort of thing, but keeping the hitboxes simple ultimately saves valuable time. Also, AutoCLSN is complete and utter clown shoes, so don't use it.
- Don't use the DCvsMarvel, Fighter Factory default, Eternity Of Heroes, Legends of the Dark Knight or Megaman Robot Master Mayhem character templates. I haven't seen anybody using these, but I think this is worth stating. These templates are filled to the brim with bugs and will ultimately make character creation a lot harder for you. While the CVG, AvX and Ryon's MvC templates are flawed, they'll definitely help more than these other ones I've mentioned.
- Pay attention to the frame data of the attacks. A little rundown of what frame data is for those who haven't heard of it: frame data is what determines if an attack is safe (your opponent cannot hit back after the move connects, or the attack cannot be punished) or unsafe (the move can punished if it connects). Now, if an attack connects without the opponent blocking, the move should be safe on hit, since it would render the move pointless if you are successful with your attack and your opponent can just hit you right back without giving you a chance to do anything. If an attack connects and the opponent blocks it, it should usually be unsafe. There are exceptions to the latter rule, like not every attack that is blocked should be unsafe, like light attacks. To check out safe an attack is, go to your trusty friend training and press MP (or y) to check for damage values and advantage frames.
- Take note about the priority of the moves. A long time ago, people would usually make it so that when there was a red hitbox, it would not be covered by a blue hitbox. However, people decided that this tactic, called infinite priority, was unfair and that the blue hitbox should eclipse the red entirely. Unfortunately, this was later seen as wrong as well, referred to as negative priority as it makes it so that the moves cannot beat other moves. So, your question must be, "what do I do in terms of hitboxes then?" Well, you should make the blue hitbox partially cover the red. How much you want it to be is up to how useful you want the Normal to be. Some characters have Normals that serve different purposes, like an uppercut intending to swat an opponent out of the air. I know this answer is kind of vague, but hey, just go with what you think is a fair amount of priority.
- Make sure there are overheads and low attacks. I see this more often then any other issue on this list. A low attack is an attack that you cannot block while standing. A high attack, or an overhead, is a move you cannot block while ducking. Change the guardflag in the hitdef to L. That'll make it so that the opponent will have to block low. You should also go to all the air attacks and change the guardflag in their hitdefs to HA (aka it cannot be blocked while crouching, but can be blocked while standing/in the air).
- Check to see if your attacks miss close up. Sometimes with attacks, mostly projectiles, if you get too close to your foe it'll miss. We obviously don't want that, so that's something to think about when testing.
- Add in some variations of the move depending on the button pressed. This one is a little on the subjective side, but I feel it's worth noting. Play some Street Fighter 2 and pick Ryu. If you do a fireball with QCF+LP, QCF+MP, and QCF+HP, you'll notice that each fireball is different from the other in terms of speed and recovery time. Not only does it make the character more fun to play, but it's also fun to think about. Maybe this character with a beam will have a beam attack that you can aim like Cyclops? Maybe the beam could cause multiple hits like Ironman's unibeam? Maybe LP could be a slow fireball, MP could be a faster fireball, and HP could be a slow, but powerful beam? There's a lot of possibilities to talk about, and it's very fun thinking about all of them.
- Try to have some variety with the moves. In games, a character's moveset is made so that each Special is for a different purpose, like for example Guile's Sonic Boom is a projectile, and his Flash Kick is an anti-air. It seems very odd when a character has several different projectiles that all seem to do the same thing.
- More tips about blocking. In practically every game except Marvel, you cannot air block an attack that is on the ground. Ground grabs cannot work when the opponent is in the air, and air grabs cannot hit when the opponent is on the ground. Grabs cannot be combo'd into as a rule of thumb. Projectiles have no blocking restrictions, aka there are no projectiles that hit overhead or low. Now there are exceptions to these rules, but it's best you stick with these.
- Be sure to align your sprites correctly. Be sure to use onion skin when building the SFF. It'll help you keep track of everything.
- Make sure to use Fighter Factory 3. FFU and FF classic are both inferior.

Alright, this is all I have so far. I'll be sure to update this list. I hope this helps all of you guys

Edit: Updated to add in more stuff. You guys think I should say something in the edit or make a post with new stuff or something? Also, I'm going to be adding a new post about advanced coding tricks at some point, so yeah.

Last edited by Doom on August 26th 2016, 5:09 pm; edited 4 times in total (Reason for editing : Received some tips from Daniel and Rice)
Back to top Go down
View user profile


Posts : 1413
Join date : 2015-08-23
Age : 21
Location : Brazil

PostSubject: Re: Dynatron's bug exterminator guide: avoiding common coding errors   June 23rd 2016, 6:45 pm

I love you for making this post, thanks
Back to top Go down
View user profile


Posts : 4413
Join date : 2014-08-22

PostSubject: Re: Dynatron's bug exterminator guide: avoiding common coding errors   June 23rd 2016, 7:25 pm

It's great what you're doing! Razz
Thank you friend ...
Back to top Go down
View user profile


Posts : 2136
Join date : 2015-06-04
Location : México

PostSubject: Re: Dynatron's bug exterminator guide: avoiding common coding errors   June 23rd 2016, 8:54 pm

Good idea, this could be really helpful for any new creators out there.
Back to top Go down
View user profile https://www.youtube.com/channel/UC0y46-XHBIoPw2vo3yDmO2w


Posts : 6328
Join date : 2012-05-02

PostSubject: Re: Dynatron's bug exterminator guide: avoiding common coding errors   July 9th 2016, 11:47 pm

thank you for sharing, made this a sticky Smile
Back to top Go down
View user profile


Posts : 4030
Join date : 2014-08-11

PostSubject: Re: Dynatron's bug exterminator guide: avoiding common coding errors   July 11th 2016, 7:59 am

Nice sticky useful MUGEN topic!   I will try to use some of your MUGEN de-bug points in my MUGEN stuff!  study

About the frame data part, I want to mention that for all melees (MUGEN HitDef/ReversalDef) and projectiles (pure MUGEN Projectile or MUGEN Helper-based Projectile), MUGEN engine always behaves weirdly when an attack's animation first 1st frame is the attacking frame, provided that the attack is being defined and activated just in the beginning of the animation (i.e. Time = 0) in the aforementioned MUGEN State Controllers -- its MUGEN Enemies may not be able guard/block at all.  No
Also, your MUGEN player's and your MUGEN enemies' distances and velocities might also affect the active attacking and guarding frames, some unwanted "Hit-or-Miss" effects might happen......too bad MUGEN engine doesn't allow dynamic frame boxes change by MUGEN CNS code.......well, I was studying something like this a while ago before, as seen on this Japanese MUGEN web page:

>> I'm going to be adding a new post about advanced coding tricks at some point
Can't wait to seeing your advanced MUGEN code for every good MUGEN de-bug point you are making! bounce
Back to top Go down
View user profile https://onedrive.live.com/?cid=7DB65F02B0BBD12E
Mistah Jorge


Posts : 1937
Join date : 2013-07-04
Age : 19
Location : Portugal

PostSubject: Re: Dynatron's bug exterminator guide: avoiding common coding errors   July 11th 2016, 9:36 am

ha.... the training character is a good character for testing, shoutout for people who don't know how to proper set the mid and head position (like me before)
Back to top Go down
View user profile


Posts : 4030
Join date : 2014-08-11

PostSubject: Re: Dynatron's bug exterminator guide: avoiding common coding errors   December 19th 2016, 12:25 pm

For a MUGEN character's non-Projectile attack, its MUGEN Enemy may not be able to guard/block the attack at all if this is the attack setting :
1) the attack animation's first 1st frame has the red attack collision box:
    [Begin Action 200] ; standing light punch for a MUGEN example
    Clsn1: 1 ;red attack collision box
    Clsn1[0] =  29,-113, 75,-86
    Clsn2: 2 ;blue get-hit collision boxes
    Clsn2[0] = -23,-116, 15,  1
    Clsn2[1] = -16,-129,  5,-112   
    200, 0, 0, 0, 3
2) the HitDef MUGEN Controller is used during the start of the MUGEN state time in the attack state:
    [Statedef 200] ; standing light punch for a MUGEN example
    type = S
    movetype = A
    physics = S
    [State 200, 1]
    type = HitDef
    trigger1 = Time = 0 || AnimElem = 1
    attr = S, NA
    damage = 48,0
    animtype = Light
    guardflag = MA
    hitflag = MAF

There are several ways to fix this MUGEN engine's bug => just make sure don't let the attack take place right at the start of the attack animation.......... geek
Back to top Go down
View user profile https://onedrive.live.com/?cid=7DB65F02B0BBD12E


Posts : 4030
Join date : 2014-08-11

PostSubject: Re: Dynatron's bug exterminator guide: avoiding common coding errors   December 29th 2016, 12:47 pm

Many MUGEN users tend to skip the MUGEN in-game intro(s) by pressing buttons during so, especially after they have already seen it/them several times.

Some MUGEN characters' MUGEN in-game intro(s) are long and the sounds/voices used during so are long too.  After skipping that/those, the sounds/voices can still be heard.  If you want to fix it then here is a MUGEN way:

1) in your MUGEN character's CNS file (be it a custom common1.cns or any other renamed/overridden MUGEN CNS files), give a particular sound channel number to the PlaySnd MUGEN State Controller(s) used in the MUGEN in-game intro state (commonly the Statedef 191), something like this:
[State 191, PlaySnd]
type = PlaySnd
trigger1 = Time = 0  ; or during any animation times
value = 191,0
volumescale = 100
channel = 19         ; this is the particular sound channel number ONLY for this in-game intro
lowpriority = 0
freqmul = 1.0
loop = 0
pan = 0
;abspan = 0
ignorehitpause = 1
persistent = 0

2) then in your MUGEN character's CNS file that has the [Statedef -2] line, under it, add a StopSnd MUGEN State Controller like this:
[State -2, StopSnd]  ; stop the in-game intro sound/voice when it is out of the in-game intro state
type = StopSnd
trigger1 = StateNo != 191
channel = 19
ignorehitpause = 1

* if your MUGEN character has more than one (1) in-game intros, then you can just use the same particular channel = 19 for the PlaySnd sounds/voices used in those extra in-game intro states (i.e. Statedef 192/193/194/....etc.)
** then add more MUGEN Triggers to the StopSnd sounds/voices for those extra in-game intro states (i.e. trigger2 = StateNo != 192/193/194/...etc.)
!!! once you have used channel = 19 for this in-game intro PlaySnd/StopSnd purpose, then don't use it again for any other PlaySnd/StopSnd purposes...
Back to top Go down
View user profile https://onedrive.live.com/?cid=7DB65F02B0BBD12E
Dynatron's bug exterminator guide: avoiding common coding errors
View previous topic View next topic Back to top 
Page 1 of 1

Permissions in this forum:You cannot reply to topics in this forum
The Mugen Multiverse :: Mugen :: Mugen Resources-
Jump to: