The Mugen Fighters Guild

Help => M.U.G.E.N Development Help => MUGEN Class => Topic started by: Just No Point on February 15, 2017, 05:04:42 pm

Title: Hardcoded Things in MUGEN
Post by: Just No Point on February 15, 2017, 05:04:42 pm
-Guard states are hardcoded. You cannot get guardsparks and other guard specific info from any other way.

-When you use the ground.type or air.type with Trip in the HitDef (http://mugenguild.com/forum/topics/hitdef-sctrls-169450.0.html) the opponent can no longer be hit while on the ground.
Title: Re: Hardcoded Things in MUGEN
Post by: altoiddealer on February 15, 2017, 05:34:22 pm
Winposes (Roundstate 4)

Match Ending: The match will not end until one player is in State 5150 (the loser), and one is in State 0 WITH ctrl = 1 (the winner).
The enemy can be controlled via custom states during winposes, but there are very specific criteria to make it work seamlessly (see my guide (http://mugenguild.com/forum/topics/control-p2-throughout-your-characters-win-pose-160621.0.html) here)
For the winning player, it is possible to continue a special "finisher-type" animation into the win pose phase (without changing to Stand anim), but the player must be in State 0 (add triggers preventing change to stand anim), and with ctrl (add triggers in .cmd to prevent input in this scenario).  A workaround for the latter is to just set ctrl=0, then toggle it to ctrl=1 intermittently for 1 tick (to trigger winpose phase).



State 5150 (lying down defeated)
When the defeated opponent is in State 5150, MUGEN does not recognize a "Player 2" / "Player 3" / "Player 4".  Meaning, triggers such as "P2Dist", "P4Life", etc will fail and result in a debug error "Nonexistent player".
However, trigger redirections such as "enemy," "enemynear," "PlayerID," - and even "target," still function correctly in this state.
Thanks @2OS for correcting my initial flawed description



Custom States
In a custom state, Explods do not scale to the active coordinate space.  A low res character in a high res environment will be drawn tiny / a high res character in a low res environment will be drawn enormous. There are no triggers that can be used to detect the scale factor, because all relevant values returned by these triggers are already scaled, regardless of being used by Player 1 or from a custom state.  Therefore, do not use Explods to draw the enemy - only use Changeanim / Changeanim 2 (unless in a fullgame environment where coordinate space is always uniform).



Stages that move up and down
On stages that have vertical movement (which bob up and down), all players (including helpers) are constantly affected by the movement, regardless of state type, if they are in the air, etc.  Explods, however, are NOT affected by this type of stage movement - therefore it is recommended to always bind Explods to the player when they are intended to be positioned relative to the player, because otherwise they may look ridiculous when used on such levels.
Title: Re: Hardcoded Things in MUGEN
Post by: Chronan on February 15, 2017, 06:10:51 pm
Sliding during a hitstate generates MakeDust as part of the engine's physics rather than any MakeDust, Explod, or GameMakeAnim SCtrls listed in the hit states. Removal requires changing fightfx.air Action 120 to a -1 grouped sprite.
Title: Re: Hardcoded Things in MUGEN
Post by: 2OS on February 18, 2017, 06:22:58 am
-Guard states are hardcoded. You cannot get guardsparks and other guard specific info from any other way.

for the record those states are 120-155.

Player-type Triggers: During win poses, MUGEN does not recognize a "Player 2" / "Player 3" / "Player 4" / etc.
Meaning, triggers such as "P2Dist", "P4Life", etc will fail and result in a debug error "Nonexistent player".
However, trigger redirections such as "enemy," "enemynear," "PlayerID," - and even "target," still function correctly in Roundstate 4.

"nonexistence" is state 5150. it is not roundstate=4/life=0/alive=0/etc. you can put helpertype=player in that state and it will function exactly like helpertype=normal (no auto turning).
Title: Re: Hardcoded Things in MUGEN
Post by: Cyanide on February 18, 2017, 11:43:44 am
the invulnerability received from mugens "liedown.time" constant is hardcoded. When the last 10 ticks of liedown time hit, you're invulnerable.

If you need a shorter liedown time, code it in, don't use the constants otherwise you will turn invulnerable almost instantly. In addition, if your AI is bad and you come out of the liedown state during this invulnerability it's permanent and never turns off.

Not to be confused with the manually set one in state 5120.
Title: Re: Hardcoded Things in MUGEN
Post by: Just No Point on February 18, 2017, 12:03:54 pm
I need to get back on that updated KFM. He fixed that iirc and many other stupid things. I think all it needed was more optional anim standards. I shouldn't be waiting on that
Title: Re: Hardcoded Things in MUGEN
Post by: AlexSin on February 18, 2017, 09:24:02 pm

Animation 5170 glitch (tested on Mugen 1.0)

Sometimes Mugen doesn't want to play the animation 5170.
How to recreate the glitch:
- try to guard an aerial attack (either basic, or special or super) while you're in air; you don't have to guard the attack (the move doesn't have to connect), but just go into one of those states;
- now get hit by an attack that makes you fall on the ground. You don't have to jump for this to happen.
(no, it's not because the c.HK has a Trip function, it happens with many other attacks that make the enemy fall)

Et voilĂ ! There's a bug!
Here's a video showing it.
(if you can't follow what I'm doing, the video's description might help you)

You have to code every custom state in all the attacks in order to not have this problem (eg Felineki's Akuma).


Edit: thanks to Daniel9999999 for discovering the root of the problem.
KFM uses sysvar(0) which gets used in the air guard states but doesn't get reset when the character is on the ground. Read the post below for a better understanding.
To fix this you need to add this piece of code under [StateDef -2]:
Quote
[State -2, System Variable Set]
type = VarSet
trigger1 = StateType = S || Statetype = C
sysvar(0) = 0
ignorehitpause = 1
Make sure you're not using sysvar(0) for other things if you're adding this code into your character, or adapt it to your liking.

Title: Re: Hardcoded Things in MUGEN
Post by: jade_midori on February 18, 2017, 09:53:48 pm
Via some quick tracing on behavior I discovered the root of this glitch:

In state 5110 there's these lines of code that uses a system variable to tell if MUGEN should show the hitground frames and as well as other things like the sounds and explods:

[State 5110, 9] ;For hit up type
type = ChangeAnim
persistent = 0
triggerall = anim = [5171,5179]
triggerall = SelfAnimExist(5110 + (anim % 10))
trigger1 = AnimTime = 0
trigger2 = SysVar(0) ;SysVar(0) = 1 avoids hit ground anim
value = 5110 + (anim % 10)

[State 5110, 10] ;For normal
type = ChangeAnim
persistent = 0
triggerall = Anim != [5111,5119]
trigger1 = AnimTime = 0
trigger2 = SysVar(0) ;SysVar(0) = 1 avoids hit ground frame
value = 5110

Now this works fine and dandy right? Well.. there's this small goof up across all air blocking states:

[State 132, 3]
type = VarSet
trigger1 = 1
sysvar(0) = (pos y >= 0) && (vel y > 0)

Now this is necessary for air blocking to work the way it works yes, Except there's one FATAL Mistake, this variable does NOT get reset at any point outside of this AND at the end of state 5110 on the first tick, so if you land in the floor well... this variable will equal 1, and therefore, it will trigger the animation 5110 overriding any other animation in the liedown state.

How to fix this? The idea i had is overriding common1.cns states (which is why i advice every creator to have a copy of this file for them to modify), going into every hitstun state (if you wanna be extra sure every hitstate) and MAKE SURE the variable is properly set to 0 before the bounce and liedown states, alternatively you can use an extra sysvar for airblocking independently of these.
Title: Re: Hardcoded Things in MUGEN
Post by: AlexSin on February 18, 2017, 10:05:27 pm
Ah, so it was just that?
Then you can just fix it by putting this under StateDef -2:

Code:
[State -2, System Variable Set]
type = VarSet
trigger1 = StateType != A
sysvar(0) = 0
ignorehitpause = 1
persistent = 0

right?
Title: Re: Hardcoded Things in MUGEN
Post by: jade_midori on February 18, 2017, 10:09:47 pm
as long as you're not using Sysvar(0) for anything else, but you also need to account for the fact that also these states are statetype = L, so I'd say to err on safety

 [State -2, System Variable Set]
type = VarSet
trigger1 = StateType = S || Statetype = C
sysvar(0) = 0
ignorehitpause = 1
persistent = 0
Title: Re: Hardcoded Things in MUGEN
Post by: XGargoyle on February 19, 2017, 11:17:29 am
Just for the record, persistent=0 does not work in -2 states
Title: Re: Hardcoded Things in MUGEN
Post by: AlexSin on February 19, 2017, 11:20:59 am
Ah yeah, right. How stupid of me to add that. In Statedef -2 they are always executed.
Title: Re: Hardcoded Things in MUGEN
Post by: Cobra Caddie on February 19, 2017, 11:24:35 am
Tapping the directional pad causes you to stand up faster. You can get around this but it's a pain in the ass. Also friction is hardcoded which is also stupid.
Title: Re: Hardcoded Things in MUGEN
Post by: Just No Point on February 28, 2017, 01:48:31 am
channel = channel_no (int)
0 is a special channel reserved for player voices. Channel 0 voices are stopped when the player is hit. It's recommended you play your character's voice sounds on channel 0.
Title: Re: Hardcoded Things in MUGEN
Post by: 2OS on February 28, 2017, 04:37:28 am
nobody really needs to know this but there's a hardcoded selfstate from 5150 to 5120 in training mode after about 100 ticks. this was a part of the formula for my old training mode detector (i made a better one).
Title: Re: Hardcoded Things in MUGEN
Post by: ink on March 14, 2019, 02:00:03 pm
Darkened background in "Win Screen" and "Continue Screen" is hardcoded. Any explod that uses anim = [F]anim_no on these screens is also darkened. (Tested in 1.0 only)
Title: Re: Hardcoded Things in MUGEN
Post by: Yoshin222 on September 05, 2019, 05:31:51 pm
Not sure if this is common knowledge or not, but felt appropriate to post here
In Constants, the "Attack" value is a hardcoded multiplier to damage, applying AFTER defining a damage value
So if you're damage scaling, rounded to say, 7,and your Attack was 105 ,it would multiply 7 by 1.05, 7.35, the value seemingly being rounded off to its ceiling value, 8. Whether this is defined by your damage scaling code or Mugen itself, I'm still not sure of
You CANNOT change how Attack works in this example. The only real solution I can think of is to make it 100,and handle the Attack multiplier using a variable instead
Title: Re: Hardcoded Things in MUGEN
Post by: Nep Heart on September 05, 2019, 10:36:26 pm
 Speaking of hardcoded stuff, there are a few worth mentioning that I have encountered which frustratingly forced me to use workarounds to circumvent these issues.

- Fall.defence_up will always trigger if the target enters states 5100 or 5070. I believe it also triggers with ground.type = trip in hitdefs. These can avoided with custom states that mimic these common hitfall states and using low instead if trip for ground.type.

- MUGEN does not actually calculate damage, but instead calculate life loss difference. However, it apparently does calculate actual damage in training mode for some inexplicit reason. Therefore, outside of training mode, if you attempt to detect damage from an attack that does 200 or even 2000 damage, but you have 100 life remaining... it only detects it as 100 damage regardless.