The Mugen Fighters Guild

M.U.G.E.N Central => Development => Topic started by: Bannana on November 30, 2014, 02:45:53 am

Title: Certain features inherently hardcoded?
Post by: Bannana on November 30, 2014, 02:45:53 am
Out of curiosity, to anyone's knowledge are there certain states that you cannot really edit through overriding or changing them within the common, or are features able to be freely overridden (albeit in a roundabout way)?

To elaborate, the docs explain that you can override the common freely (using this as an example):
Code: 
; RUN_FWD (overridden to dash-type)
[Statedef 100]
type    = S   ;Running is on the ground
physics = N   ;We'll define our own physics
anim = 100    ;Anim action 100
ctrl = 0      ;No control for duration of dash

[State 100, 1] ;To start dashing forwards
type = VelSet
trigger1 = Time = [0,5]
x = 6

[State 100, 2] ;Friction after initial dash
type = VelMul
trigger1 = Time > 5
x = .85

[State 100, 3] ;
type = ChangeState
trigger1 = AnimTime = 0
value = 0
ctrl = 1
But are there any instances where edits or overriding the common does nothing?
Title: Re: Certain features inherently hardcoded?
Post by: Cyanide on November 30, 2014, 03:18:18 am
No, if you put one of those states in your CNS it will override. But certain functions cannot be easily bypassed.

Walk, jump, crouch, those changestates are hardcoded. You need to actually remove ctrl altogether to achieve something else without entering those states. The invulnerability when there are 10 ticks to go before you stand up, that's hardcoded (and a bit broken if you break the state when that happens, if you need a shorter liedown, edit the state shorter, don't change the liedown time or you'll be invulnerable too fast)

How mugen behaves for round start and end is also hardcoded. End is particularly annoying as p2 must be in 5150 at some point for you to win.

Being hit is just a bit awkward to follow. If you can follow the states accurately mugen will behave itself

Guard is hardcoded in terms of taking block damage. Those states are the only ones that take it, there is no other way afaik to implement guard damage from the opponents hitdef.
Title: Re: Certain features inherently hardcoded?
Post by: Bannana on November 30, 2014, 04:06:13 am
Cyanide said, November 30, 2014, 03:18:18 am
Guard is hardcoded in terms of taking block damage. Those states are the only ones that take it, there is no other way afaik to implement guard damage from the opponents hitdef.
Oh, that's interesting. So if you coded a guardlike state, no matter what you do it isn't treated as a guard by the opponent's hitdef if it isn't within states 120-155? Does this mean that if you tried to make said state, you would just be hit as if you weren't guarding at all?
Title: Re: Certain features inherently hardcoded?
Post by: Cyanide on November 30, 2014, 06:48:21 am
Oh no, you could imitate guard fine. You just can't pick up the guard damage meaning you basically make a guess of some sort with gethitvar

lifeadd
trigger1 = time = 0
value = gethitvar(damage)/4

or something. Which won't give you the right amount for the attack necessarily. Probably won't make the guardspark show up either. Those states annoy me a bit because they are so locked down

Only real way to do it is edit those states for the effects you want in terms of autoguard and shit. Most people afaik haven't done this.
Title: Re: Certain features inherently hardcoded?
Post by: Bannana on November 30, 2014, 08:44:27 am
Well, on the topic of guard since it's kind of strange to me, is it considered a state like walk, jump and crouch in that it's hardcoded? Looking through the common there's no defined command that initiates the guard, it apparently happens when you hold back innately. The changestate defines that when you stop holding back the guard ends and it sends you to state 140 and that when you hold down it enters the crouching state (and vice versa), but entering the state is what confuses me.
Code: 
; GUARD (start)
[Statedef 120]
type = U    ;Leave state type unchanged
physics = U ;Leave physics unchanged

[State 120, 1]
type = ChangeAnim
trigger1 = Time = 0
value = 120 + (statetype = C) + (statetype = A)*2

[State 120, 2]
type = StateTypeSet
trigger1 = Time = 0 && statetype = S
physics = S

[State 120, 3]
type = StateTypeSet
trigger1 = Time = 0 && statetype = C
physics = C

[State 120, 4]
type = StateTypeSet
trigger1 = Time = 0 && statetype = A
physics = A

[State 120, Hi to Lo]
type = StateTypeSet
trigger1 = statetype = S && command = "holddown"
statetype = C
physics = C

[State 120, Lo to Hi]
type = StateTypeSet
trigger1 = statetype = C && command != "holddown"
statetype = S
physics = S

[State 120, 2]
type = AssertSpecial
trigger1 = 1
flag = NoWalk

[State 120, 5]
type = ChangeState
trigger1 = AnimTime = 0
value = 130 + (statetype = C) + (statetype = A)*2

[State 120, Stop Guarding]
type = ChangeState
trigger1 = command != "holdguard"
trigger2 = !inguarddist
value = 140
Title: Re: Certain features inherently hardcoded?
Post by: Websta on November 30, 2014, 10:38:31 am
Same thing with changing to state 20 if you press back or forward. State 10 if you press down and State 40 if you press up.

Those things are hardcoded into state 0, you can change it if you make your idle state something different entirely.
Title: Re: Certain features inherently hardcoded?
Post by: Bannana on December 01, 2014, 08:56:01 am
Ah, looking at it again, it makes sense. Thanks for pointing that out, I didn't think of it in that way when I first glanced at it.
Title: Re: Certain features inherently hardcoded?
Post by: Caddie on December 01, 2014, 11:49:54 pm
Something you might not have noticed before for every character. If you mash directions when knocked down, you'll stand up faster. No fighting game does this that I'm aware of, but it's hardcoded into Mugen. Overriding it is a pain in the ass but possible, the only thing is you have to make sure that your fall.defense_up is set to 0 or tapping the direction pad will effect how much damage onground attacks do to you. It should be 0 by default anyway, Mugen has dumb things by default.
Title: Re: Certain features inherently hardcoded?
Post by: Jesuszilla on December 02, 2014, 12:54:33 am
What do I need to override, Caddie? Also thanks for telling me about the defense_up thing.
Title: Re: Certain features inherently hardcoded?
Post by: -Red- on December 02, 2014, 01:14:42 am
There are two extra fail-safes MUGEN has for when you reach roundstate=3:

First one is quite common. If one of the characters get stuck in a state and never reach state 5150 or a winpose/losepose state the engine will automatically changestate you to the correct state so it can end the round properly. This is a common result one gets by accident while testing certain type of moves or winposes so you all know about that by now.

The second one is a bit more tricky and there's people who play mugen for years without knowing about it. If roundstate=3 lasts for a certain amount of time the player who's getting hit will be fully invulnerable to any incoming attack after a while.

The most realistic case where this can happen is during a time over roundstate=3 where you could in theory connect a super that starts a long string of attacks, a practical example being something like your usual KOF super where the character dashes forward and starts an autocombo. The move will eventually whiff its attacks and depending of how the move was coded like it will look really odd and the one getting hit may end up stuck in a gethit state until the engine initiates the first fail-safe.
Title: Re: Certain features inherently hardcoded?
Post by: Bastard Mami on December 02, 2014, 02:25:00 am
not hardcoded at all, if anything it is the coml´pete oposite, just one of these things most creators don't realize as mugen should have this hardcoded, but mugen's buffers sucks, it really sucks a lot , to the point that jumping attacks won't come out when you press up+attack button very closely, as the jump start has no control and mugen does not bother buffering.
Title: Re: Certain features inherently hardcoded?
Post by: Jesuszilla on December 02, 2014, 04:11:29 am
I managed to get around that by forcing buffered jumping, though. Basically, you just have to reset them to the neutral state as soon as they enter any of the basic states if the buffering conditions aren't met. I HAD to do this in order to get buffered pursuit attack working in VC Felicia when I added Vans's buffering system. This system also allows for buffered crouch and walk.

Code: 
[State -1, Buffered Walk]
type = AssertSpecial
trigger1 = NumHelper(10371)
flag = NoWalk
[State -1, Buffered Walk]
type = ChangeState
triggerall = NumHelper(10371)
triggerall = command != "holddown"
triggerall = statetype != A
triggerall = roundstate = 2
triggerall = !isHelper
triggerall = (StateNo != [11,12]) && StateNo != 20 && StateNo != 40 && !(StateNo = 52 && Time < 5)
triggerall = Ctrl && (StateNo != [120,132]) && (StateNo != [150,155]) && (StateNo != [700,720])
trigger1 = (helper(10371), Var(16) = [1,8])
trigger1 = !(helper(10371), Var(18) > helper(10371), Var(16))
trigger2 = (helper(10371), Var(17) = [1,8])
trigger2 = !(helper(10371), Var(19) > helper(10371), Var(17))
trigger3 = (helper(10371), Var(16) = -1) || (helper(10371), Var(17) = -1)
value = 20
[State -1, M.I.X. THE CRACK]
type = ChangeState
triggerall = NumHelper(10371)
triggerall = !(helper(10371), Var(14) = [1,2]) ; Buffered jump
triggerall = !((helper(10371), Var(15) = [1,8]) || (helper(10371), Var(15) = -1)) ; Buffered crouch
triggerall = statetype != A
triggerall = roundstate = 2
triggerall = !isHelper
triggerall = StateNo != 0 && (StateNo != [11,12]) && StateNo != 20 && StateNo != 52
trigger1 = Ctrl && (StateNo != [120,132]) && (StateNo != [150,155]) && (StateNo != [700,720])
value = ifElse(((helper(10371), Var(16)) || (helper(10371), Var(17))), 20, 0)
[State -1, M.I.X. THE CRACK]
type = ChangeState
triggerall = NumHelper(10371)
triggerall = helper(10371), Var(14) = [1,2] ; Buffered jump
triggerall = statetype != A
triggerall = roundstate = 2
triggerall = !isHelper
triggerall = StateNo != 0 && (StateNo != [11,12]) && StateNo != 20 && StateNo != 40 ;&& StateNo != 52
trigger1 = Ctrl && (StateNo != [120,132]) && (StateNo != [150,155]) && (StateNo != [700,720])
value = 40