YesNoOk
avatar

Hardcoded Things in MUGEN (Read 61941 times)

Started by JustNoPoint, February 15, 2017, 05:04:42 pm
Email this topic
View printable version
Share this topic:
« previous next »
Page 1 of 11   Go Down

JustNoPoint

Hardcoded Things in MUGEN
#1  February 15, 2017, 05:04:42 pm
  • ******
    • www.justnopoint.com/
-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 the opponent can no longer be hit while on the ground.

altoiddealer

Re: Hardcoded Things in MUGEN
#2  February 15, 2017, 05:34:22 pm
  • ****
  • Robotics Engineer
    • USA
    • altoiddealer@gmail.com
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 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.

Last Edit: February 19, 2017, 02:53:24 pm by altoiddealer

Chronan

Re: Hardcoded Things in MUGEN
#3  February 15, 2017, 06:10:51 pm
  • ****
  • The Barbarian
  • Most ****able 2013
    • USA
    • Skype - chronostrifeff7h@hotmail.com
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.

2OS

Re: Hardcoded Things in MUGEN
#4  February 18, 2017, 06:22:58 am
  • ****
  • 608 Wannabe
  • Ich schicke dich zur HOELLE!! STIRB DU FEIGLING!!
    • Egypt
Just No Point said, February 15, 2017, 05:04:42 pm
-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.

altoiddealer said, February 15, 2017, 05:34:22 pm
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).

Cyanide

Re: Hardcoded Things in MUGEN
#5  February 18, 2017, 11:43:44 am
  • ******
  • Legendary XIII
  • I am the eye of the storm to come!
    • New Zealand
    • network.mugenguild.com/cyanide/
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.


In M.U.G.E.N there is no magic button

They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.

JustNoPoint

Re: Hardcoded Things in MUGEN
#6  February 18, 2017, 12:03:54 pm
  • ******
    • www.justnopoint.com/
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

AlexSin

Re: Hardcoded Things in MUGEN
#7  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.

Last Edit: February 19, 2017, 02:57:43 pm by AlexSin

jaede_

Re: Hardcoded Things in MUGEN
#8  February 18, 2017, 09:53:48 pm
  • ****
  • it's me
  • Bat's a Wrap.
    • Chile
    • koakoa@jabber.org
    • Skype - koakumadevil69
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.
Yeaaaah im shootign ducks wiht the paino
Last Edit: February 18, 2017, 09:57:34 pm by Midori M.

AlexSin

Re: Hardcoded Things in MUGEN
#9  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?

jaede_

Re: Hardcoded Things in MUGEN
#10  February 18, 2017, 10:09:47 pm
  • ****
  • it's me
  • Bat's a Wrap.
    • Chile
    • koakoa@jabber.org
    • Skype - koakumadevil69
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
Yeaaaah im shootign ducks wiht the paino

XGargoyle

Re: Hardcoded Things in MUGEN
#11  February 19, 2017, 11:17:29 am
  • ******
  • Hedgehog Whisperer
  • Red Bull addict
    • Spain
    • xgargoyle.mgbr.net
Just for the record, persistent=0 does not work in -2 states
XGargoyle: Battle posing since 1979
http://xgargoyle.mgbr.net
http://www.pandorabots.com/pandora/talk?botid=e71c0d43fe35093a  <-- Please click that link
http://paypal.me/XGargoyle  <-- Donations welcome!

AlexSin

Re: Hardcoded Things in MUGEN
#12  February 19, 2017, 11:20:59 am
  • ******
Ah yeah, right. How stupid of me to add that. In Statedef -2 they are always executed.

Cobra Caddie

Re: Hardcoded Things in MUGEN
#13  February 19, 2017, 11:24:35 am
  • *****
  • Most Dangerous Mugen
    • USA
    • caddie.smeenet.org
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.

JustNoPoint

Re: Hardcoded Things in MUGEN
#14  February 28, 2017, 01:48:31 am
  • ******
    • www.justnopoint.com/

2OS

Re: Hardcoded Things in MUGEN
#15  February 28, 2017, 04:37:28 am
  • ****
  • 608 Wannabe
  • Ich schicke dich zur HOELLE!! STIRB DU FEIGLING!!
    • Egypt
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).

inktrebuchet

Re: Hardcoded Things in MUGEN
#16  March 14, 2019, 02:00:03 pm
  • ****
  • ✨
    • USA
    • twitter.com/inktrebuchet
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)

Yoshin222

Re: Hardcoded Things in MUGEN
#17  September 05, 2019, 05:31:51 pm
  • ***
  • Getting better, still a long way to go
    • UK

  • Online
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

Nep Heart

Re: Hardcoded Things in MUGEN
New #18  September 05, 2019, 10:36:26 pm
  • ****
  • CPU Purple Heart
    • USA
    • https://www.pixiv.net/en/users/8108265
 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 of 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.
Last Edit: November 04, 2019, 01:31:01 am by Nep Heart

Archimonde

Re: Hardcoded Things in MUGEN
#19  September 23, 2019, 06:01:20 am
  • avatar
  • **
    • Vietnam
altoiddealer said, 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 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.

It is not nessesary to force character to stateno = 0 to perform match ending. Only need both Movetype = I / Ctrl = 1 / p2stateno = 5150(his own state file). That will become more handy
------Tremble Mortal and Despair. Doom has come to this world------
Page 1 of 11   Go Up
« previous next »