something troubling me for quite some times..

[onloser]

I tried to edit the iori_XI created by Zelgadis after discovering that the character tends to fly higher after getting hit up comparing to other characters. I tried to adjust float value and check the animation but have found nothing abnormal. Any suggestion ?

What are the values that have effect on a character's height or speed of flying when he was blown away or getting hit in the air ?

[Byakko]

.cns file => [Movement] => yaccel

[onloser]

thanks.. but that's not the answer..

yaccel only affects the height and speed of jumping..

the character jumps normally but when tends to fly higher when he is blown up by opponent

[Cyanide]

Have a look for yaccel in the characters hitdef.

[onloser]

I tried that one also.. I will explain the problem more clearly..

I use kyo's double kick (second kick's air velocity = -3,-10), when kyo is kicked, he was sent up to maybe the height of -10, but when iori is kicked by the same move, he tends to fly higher and longer.. By the way, both characters are using the same common1.cns.

[Cyanide]

Either state 5050 has been overridden for iori, the Yaccel in the hitdef is specified or Byakko's suggestion is correct.

Those are your options. I doubt a custom state is in use or they'd both act the same.

[Byakko]

yaccel only affects the height and speed of jumping..

the character jumps normally but when tends to fly higher when he is blown up by opponent

Hum, did you try it ?
When jumping, there's first the initial velset, and then there's the veladd that simulates gravity. You CAN modify the veladd (i.. the yaccel) and still get a decent result if the initial velset is modified accordingly. So it's still possible that the yaccel is different in Iori's constants, and you'll still get a decent jump if his jumping velocity is also different. But if the yaccel is changed and nthe initial velst is unchanged (which is the case when looking at your opponent's hitdef), then it will behave differently, exactly  like what you're getting. If not the yaccel, what else do you think can make Iori fall back to the ground when he's kicked up ? Gravity is made by yaccel.
Usually it should never be changed, precisely because of hitdefs. Just check if he has the same as everyone else.
For comparison, click on this
type = GravityGravity uses yaccel.

[onloser]

thanks for the reply..

1. I tried to experiment with y.accel, it affects only the height of jumping only..
2. I can't find "gravity" in the character files
3. there is no statedef 5050 in the character

any suggestions ?

[_Josue_]

thanks for the reply..

1. I tried to experiment with y.accel, it affects only the height of jumping only..
2. I can't find "gravity" in the character files
3. there is no statedef 5050 in the character

any suggestions ?

------------------------------------------------------------
Gravity
------------------------------------------------------------


Accelerates the player downwards, using the value of the player's "yaccel" constant.


Required parameters:

 none


Optional parameters:

 none

Example:

 ; Applies constant acceleration throughout state
 trigger1 = 1
 type = Gravity


Well well well, Open the problematic char's .def file should be iori.def or something like that
see if stcommon = common1.cns
otherwise it uses it's own file for common states, which is rarely possible.
else, you'll see if there is statedef 5050 in common1.cns which is used by all characters in mugen.
in statedef 5050 there is this controller that controls how fast the char should fall after getting hit


[State 5050, 3] ;Gravity
type = VelAdd
trigger1 = 1
y = GetHitVar(yaccel)


which I think comes from hitdef's yaccel and is not Const(movement.yaccel)
Besides, State 5050 physics are N which is neutral, and there's no


[State 5050, 3]
type = Gravity
trigger1 = 1

that makes me wonder if such feature is hardcoded.
Anyways, just try putting a very high value to yaccel, I guess 3 or 7, then check the move using iori and the other char in debug mode, see if the debug info becomes yellow, then it's a custom state problem.

[Byakko]

which I think comes from hitdef's yaccel and is not Const(movement.yaccel)
Besides, State 5050 physics are N which is neutral, and there's no gravity that makes me wonder if such feature is hardcoded.

Well, the default value for the hitdef's yaccel is 0, so if there's no other gravity controller, then yes, it's most likely  hardcoded. I've been looking around  a bit, and I couldn't find any value that, when changed (to ridiculous values like -50), would give my char a different behavior when kicked up. I can't find anything that would make one specific character fly up differently than everyone else when kicked up... There may be something in Iori's files where the author put a custom acceleration - like a velmul or someting in his statedef -2 triggered by being in the appropriate gethit state.

... Are you absolutely sure that Iori flies differently from everyone else... ? I tried looking for Zelgadis's Iori_XI, found only his Orochi Iori, but couldn't find anything noticeable.

[_Josue_]

which I think comes from hitdef's yaccel and is not Const(movement.yaccel)
Besides, State 5050 physics are N which is neutral, and there's no gravity that makes me wonder if such feature is hardcoded.

Well, the default value for the hitdef's yaccel is 0, so if there's no other gravity controller, then yes, it's most likely  hardcoded. I've been looking around  a bit, and I couldn't find any value that, when changed (to ridiculous values like -50), would give my char a different behavior when kicked up. I can't find anything that would make one specific character fly up differently than everyone else when kicked up... There may be something in Iori's files where the author put a custom acceleration - like a velmul or someting in his statedef -2 triggered by being in the appropriate gethit state.

... Are you absolutely sure that Iori flies differently from everyone else... ? I tried looking for Zelgadis's Iori_XI, found only his Orochi Iori, but couldn't find anything noticeable.

I've done a couple of experiments, I just made a perfect copy of get hit states (with different numbers, from 50000 to 50050) and sent my target to them with targetstate, the results are weird! it moves somewhat as if it were in slow motion or some thing vert rare... that makes me think that there are lots of "obscure" things hardcoded within MUGEN... that makes me wonder how are ShugenDo and the other projects such as Open Mugen doing...

[_Josue_]

var(3):=0 sets var(3) to 0. It's just a shortcut for a varset, and you can put it anywhere where you can write an expression (like a trigger).

Thanks a lot Byakko, nobody answered my topic for more than a month. Alas, you didn't mention the other issue, the SFF one...
Anyways, about this problem, it's very mysterious, you can send your foe to a custom state just with this two controls

Spoiler (click to show)

[State 731, HitDef]
type = HitDef
trigger1 = time = 0
attr = S, SA                    
damage = 77, 7                  
animtype = hard        
guardflag = MA              
hitflag = MAF                  
priority = 3, Hit              
pausetime = 7, 1
p2facing = 1
id = 7310            
sparkno = S999                  
sparkxy = -14, -30            
hitsound = S5, 4          
guardsound = 6, 0              
ground.type = Low              
ground.slidetime = 3
ground.hittime  = 1
ground.velocity = -1.7,-0.7
guard.slidetime = 3
guard.hittime = 7
guard.velocity = -7.3  
air.type = High                  
air.velocity = -1.7,-0.3
air.hittime = 12
yaccel = 1.73
fall = 1
fall.recover = 0      
getpower = 0

[State 731, TargetState]
type = TargetState
trigger1 = NumTarget(7310)
trigger1 = !moveguarded
value = 50000
ID = 7310
ignorehitpause = 1

they will behave as if in slow motion... (state 50000  is a copy of state 5000)
trigger1 = !moveguarded since they're sent to state 50000 even if guarding.

Spoiler (click to show)

[State 210, 2]
type = HitDef
triggerall = Name= "Kamaitachi"
trigger1 = AnimElem = 2
attr = S, NA
guardflag   = MA;hitflag=MA, so it can be guarded against
animtype  = hard
damage    = 33,3
priority = 1, miss
pausetime = 7,3
sparkno = S999
sparkxy = -10,-40
hitsound = S5, 4
guardsound = 6,0
guard.dist = 0
ground.type = High
p2facing = 1
p2stateno = 50000;212
id = 3700
ground.slidetime = 12
ground.hittime  = 14
ground.velocity = -3.7,-1.73
guard.slidetime = 17
guard.hittime = 17
guard.velocity = -3.37
air.velocity = -3.75,-1.73
;yaccel = 1.37
fall = 1
fall.xvelocity = -1.7
fall.yvelocity = -4.7
getpower = 0  

Even more annoying, you can actually send them to custom states with attr = S, NA
and they seem to move correctly...
What is startling about all this is that this hitdef can't be recognized by hitoverrides!

[Byakko]

Alas, you didn't mention the other issue, the SFF one...

Uh, Cyanide did that fine even before you asked the question.

Don't bother. Linked sprites seem to break quite frequently through FF.

What don't you get it ? He's litterally saying very specifically that FF makes it break. As in, the problem is FF. So of course, since he already had replied, nobody did answer your question, because the answer was already right above your question.

What is startling about all this is that this hitdef can't be recognized by hitoverrides!

HitOverRide and p2stateno really hate each other with a passion. Yes, it doesn't work, and it's a fairly well known problem. That's one of the reasons why TargetState is better.

[_Josue_]

Alas, you didn't mention the other issue, the SFF one...

Uh, Cyanide did that fine even before you asked the question.

Don't bother. Linked sprites seem to break quite frequently through FF.

What don't you get it ? He's litterally saying very specifically that FF makes it break. As in, the problem is FF. So of course, since he already had replied, nobody did answer your question, because the answer was already right above your question.

What is startling about all this is that this hitdef can't be recognized by hitoverrides!

HitOverRide and p2stateno really hate each other with a passion. Yes, it doesn't work, and it's a fairly well known problem. That's one of the reasons why TargetState is better.

And I said I found a way to prevent FF from breaking, it just requires effort, now will the SFF weight be worth the effort?

with a passion??? or   with a passion???

ah sorry, you said hate
and about the TargetState... i'ts quite strange, even with a copy of state 5000 it behaves oddly!
it even behaves quite different with the HitOverRide but at least hits... crap! what to do what to do!

Oh heck! what are you supposed to do for a custom state? what are the guidelines? or you can make the poor p2 do anything? even breaking the rules if any?

what is supposed to be coded within the custom state? besides of the animation...
a Velset? or a HitVelset?
should there be a Lifeadd? or I should use TargetLifeadd?

[Byakko]

On custom states.

You put an opponent by using type = TargetState, triggered at least by triggerall = numTarget, and when ythe move you want has hit.
TargetState puts the opponent into one of your states. As in, he wil read the code in your file and do whatever it says.
You make him play an animation you defined (he will use his own sprites but your animation)
you can put velocities, posadds and whatever
avoid doing anything with any variables, as it will use the opponent's variables, and you're sure to fuck him up if you do that
He does everything you say in your state, so if you put a type = LifeAdd with a negative value, he will do just that : he will lose some life.
When your done with him, never forget to send him back too his own state with a type = SelfState. Be sure to leave him so that he knows what to do - leave him in his liedown state or what else.

[_Josue_]

On custom states.

You put an opponent by using type = TargetState, triggered at least by triggerall = numTarget, and when ythe move you want has hit.
TargetState puts the opponent into one of your states. As in, he wil read the code in your file and do whatever it says.
You make him play an animation you defined (he will use his own sprites but your animation)
you can put velocities, posadds and whatever
avoid doing anything with any variables, as it will use the opponent's variables, and you're sure to fuck him up if you do that
He does everything you say in your state, so if you put a type = LifeAdd with a negative value, he will do just that : he will lose some life.
When your done with him, never forget to send him back too his own state with a type = SelfState. Be sure to leave him so that he knows what to do - leave him in his liedown state or what else.

Thank you...
what's wrong with TargetLifeAdd, it's not obeying the defense multiplier just in some cases!

Spoiler (click to show)

[State -2, TargetLifeAdd]
type = TargetLifeAdd
triggerall = Anim = 217
triggerall = NumTarget(3207)
trigger1 = target(3207), stateno=2170
trigger1 = target(3207), animTime = 0
value = -117
ID = 3207
kill = 1
absolute = 0
ignorehitpause =1
persistent = 0

I mean, 117 damage is dealt to all my targets, even those that (like my modified version of Omega Zero)
have a DefenceMulSet of 0.5 in state -2. That doesn't happen to normal attacks. What is very curious is that it doesn't happen if I chain the throw with another attack. i.e. if I do a normal kick and before he recovers from the hit I do this throw, then it pays attention to the absolute = 0 parameter, otherwise not.

[Cyanide]

There is a known bug with defencemulset that occured in the swap to winmugen. The multiplier does not take effect until the second hit in a combo. First hits will always deal full damage.

[_Josue_]

There is a known bug with defencemulset that occured in the swap to winmugen. The multiplier does not take effect until the second hit in a combo. First hits will always deal full damage.

Ugly crap! is there any way to get it working? I don't want to give up with mugen just because of bugs like this...
wait a second, your signature, "mugen obscurity" Does that mean there are more odd annoying bugs?

[Cyanide]

Mugen has lots. But that's not why my site is called Mugen Obscurity.

There's no decent way around it. You could probably do

[state -2]
type = lifeadd
trigger1 = movetype = H && time = 0
value = floor(gethitvar(damage)/2)

as an option. But that probably wouldn't work considering states go through a number of transitions and damage would probably kick in for all of them. Or it wouldn't work for targetlifeadd controllers.

Normally when it comes to defence if they're ALWAYS going to have it on. Like from the start, double it in the constants rather than using the function.

Attackmulset is fine.

[Rajaa Retired]

You can make the defencemul activate only when you're being thrown so it works for targetlifeadds as well, you have to be targetbinded, though. You can also make it activate when in common animations like 5950, but it might be a bit risky to do this.