YesNoOk
avatar

Can we unlock MUGEN's full potential? Here's one example! (Read 1665 times)

Started by -Red-, February 01, 2010, 12:19:33 am
Email this topic
View printable version
Share this topic:
Page 1 of 11   Go Down

-Red-

Can we unlock MUGEN's full potential? Here's one example!
#1  February 01, 2010, 12:19:33 am
  • ******
  • Complicated.cns
  • No, I've never played a Zelda game before, shut up
    • Argentina
I'll proceed to post something I wrote yesterday, it's an interesting trick I discovered while developing my fullgame. If you have any suggestions about another kind of weird tricks please post here. I know this may be better to be discussed in developing section but whatever, I'll let you do the moving if you desire.


It's so simple I can't believe no one actually does this kind of things on they fullgames yet! :O.

I found this crazy trick to archieve many different things and effects that are either impossible or quite wrong and accurate otherwise. It's a trick that involves the gethivar triggers and a certain data from the hifdefs. This is how it works...

First I'll show you a hitdef sample from my fullgame, there are certain comments there but the important part is at the end:


[State 200]
type = HitDef
triggerall = !fvar(4) && numenemy
trigger1 = (!movecontact && !movereversed)
attr = S,NA
damage = ceil((58.8235+ifelse(var(8),10,0))*fvar(13)*fvar(14)*fvar(15)),0 ; DAMAGE TOTAL CALCULATION
getpower = ceil(46.875)
givepower = ceil(15.625)
animtype = light
air.animtype = back
hitflag = MAFD
guardflag = MA

hitsound = -1 + 0*(var(41):=0) ; USING P.O.T.S. TRICK IN THIS SECTION
guardsound = -1 + 0*(var(42):=0)
sparkno = -1 + 0*(var(43):=9620)
guard.sparkno = -1 + 0*(var(44):=9630)
sparkxy = -10 + 0*(var(45):=64), var(46):=-93

ground.type = high
ground.slidetime = 12
ground.hittime = 10
ground.velocity = -7
pausetime = 9,10
guard.velocity = -6
guard.pausetime = 8,9

air.type = high
air.velocity = -4,ifelse(p2statetype = A,-5,-1)*fvar(5) ; GRAVITY DAMPENER
air.hittime = 10
airguard.velocity = -4,-1
yaccel = 0.5

fall = 0
air.fall = 1
fall.recover = 1
fall.recovertime = 11+ceil(10*fvar(25)) ; RECOVERY DAMPENER
down.bounce = ifelse(p2statetype = L,0,1)
fall.yvelocity = -3.5
ground.cornerpush.veloff = 0
fall.envshake.time = ceil(50*fvar(9)) ; STUN DMG - IMPORTANT!
fall.envshake.freq = 0.0 ; ELEMENTAL DAMAGE - IMPORTANT!
fall.envshake.ampl = 0 + 0*(fvar(29):=2) ; COUNTER HIT ID - IMPORTANT!
fall.envshake.phase = 1.0 ; P2FACING PARAMETER - IMPORTANT!
hitonce = 1 ; WHO THE HELL DO YOU THINK I AM? SOME CRAPPY CODER WITH SILLY BUGS?


As you see there's a section dedicated to the fall.envshake data, now this is the important part. Most of the time you never use that data and if you have to use it for a certain effect you can just find another way to trigger the envshake effect either via custom state or helper and variable triggers. I'm always assuming this kind of thing is going to get used on fullgames because I guess it's hard to adapt every single char to never use fall.envshake on it's attacks...

How this works it's simple, you basically never, NEVER give a value to "ampl" other than 0, otherwise the envshake effect will come out, if this data is 0 then you will be free to give any value to any of the other fall.envshake data.

Then the enemy will receive the desired effect by just using gethitvar(fall.envshake.-insert here data read-), this is how it's like in my fullgame:


; STUN DAMAGE
fall.envshake.time = ceil(50*fvar(9)) ; STUN DMG

This data is used to deal an exact amount of STUN DAMAGE. The enemy has a variable set to a certain maximum value (With K' it's 750) and when he get's hit that variable loses a certain amount depending of the "fall.envshake.time" received and when the variable reaches 1 the character get's dizzy and resets the stun damage value when needed.

This line is basically used as a "stun damage" data so I can deal ANY kind of stun damage with ANY kind of attack (including helpers) and without depending of other data like pausetime or damage dealt

While you can use varsets on every state and increase your own variable that when reaches it's max value makes the enemy dizzy this is not recomendable at all when you have something much better than this neat trick, remember that if you use stuff like variables, deal a hit and get hit at the same time you will not get movehit/contact as valid hence you will not deat stun damage, but with this system you WILL do stun damage even if getting hit at the same time. What's more important, this let's you choose the actual value so you can make totally accurate stun damage based on any game, infact you can even add your own stuff like the dampener I added (the fvar(9)) so you deal less stun damage on longer combos.

You can find a guide about how to use this on this forum in the correct section...


; ELEMENTAL DAMAGE
fall.envshake.freq = 0.01 ; FIRE DAMAGE

This was my latest discovery, with this line I was able to identify what kind of elemental damage the attack is dealing and trigger effects accordingly. In my game I'm using this to create an accurate KOF palfx time system.

As you may know in KOF (And most of the games) when you deal fire damage for example, the enemy gets a burn palfx on it's body until he get's hit by an attack that doesnt posseses the same element (or no element at all), until he bounces on the ground or lies down or until he recoveries from the attack (this is most likely to be visible on the ground on an attack that doesnt knockdown).

However MUGEN doesnt allow you to do this kind of restrictions just like that, instead you have palfx that can be applied by attacks but you dont have a parameter to imitate KOF's palfx timing but instead a mere "palfx.time" parameter which means after the time limit is reach the effect will no longer be active. What's more important is that the palfx will be active even if the enemy gets to a moment where he shouldnt be burning (Read above if you dont remember).

So how can you get a palfx that reacts like in KOF? simple, when you get hit and are under a certain circumstance where you should be burning you can release a helper (It works with an explod aswell but it's much better and easier to use a helper) that indicates the elemental damage dealt to you. The palfx must be triggered with the helper's presence and the helper must be destroyed when a point where no palfx is needed is reach.

So when gethitvar(fall.envshake.freq) = 0.01 you get burned, easy huh? The you can just use any other value for different elements and maybe to repeat an element but that should burn you under irregular circumstances. Youre probably thinking "why are you using such an odd value?", that's because you can use the number at the left for something else (Creativity is the limit!) and hence having a data that acts as 2 things! in fact you may have unlimited stuff to stick to this particular line if you're smart enough and have good math knowledge (for the triggers).


; NOT USED
fall.envshake.ampl = 0 + 0*(fvar(29):=2) ; COUNTER HIT ID

Try to keep this at 0 all the time because if you give this a value the envshake will be triggered. Of course you can give this a really minimal value and the screen will not look like it shakes at all or you can use this data on an attack that never knocksdown but chances are you will end up dizzy by paying attention to the whole combination of the lines rather than being free to use any value by just keeping this as 0.

You also see a "+ 0*(fvar(29):=2)" thing, dont pay attention to it as it's just a fix I did to correctly display some counter hit graphics under double conter hits (cross counters?).


; FACING PARAMETER
fall.envshake.phase = 1.0 ; P2FACING PARAMETER

This is something you probably wont care but chances are someone actually had to suffer the bug Im gonna mention in a few lines (And so that guy will say "Oh! So THAT'S how you fix that thing!").

This basically acts as an alternative way to use the "p2facing" parameter but it's better. This is only important if you're coding a double sided character, otherwise you can stick to "p2facing".

The way a double sided character animations are coded usually fall under this kind of values:

; NORMAL ANIM
[State 2000]
type = ChangeAnim
trigger1 = !time && movetype != H
value = 1503+ifelse(facing=-1,10000,0)

you basically have the normal anim (1503) and the second side which always is the normal anim + 10000. The reason why you cant use a variable to keep track of the side you're facing is because there's a delay between setting the var and reading the side you're looking at, so you will end up with incorrect side animations when you get hit or block an attack. Using "Ifelse" and "facing" is much better and flawless but it's only perfect if you also do the next trick:

When you get hit by an attack with the "p2facing" parameter forcing you to face the enemy and you werent looking at him you will turn and face him on the correct state, however even after using the correct way to trigger the animation you character will still display the incorrect side DURING the hitshaketime, this is because the character still thinks he's facing the same direction he was facing before getting hit (This data updates after the hitshaketime is over). In order to fix this you must add the next line on the statedef:

facep2 = ceil(gethitvar(fall.envshake.phase))

This will indicate if the attack is an attack that makes you face him or not (Important! Never use p2facing on hitdefs again if using this technique!) and since this is in the gethit state by itself then you character will update it's facing value before changing the animation hence fixing that silly bug. This line should be added only on certain states (Like the starting get hit states such as 5000,5010 and 5020 or on certain phases of the guarding states. Of course also pay attention to custom states).


Well there you go! This is just an example of how can certain stuff be used on a totally different way and by that archieving interesting effects or just fix bugs otherwise impossible to fix or far more complex. Since you probably are NOT working on something similar to my game you can use all the parameters for something totally different (Like the facing parameter trick, if you're not making doublesided chars then you have a free data line to use). As I said creativity is the limit on this, who knows what else can be done with this? Even better saving shift or burst systems are possible with this.

The only thing I wasnt able to do so far is to create a system that allows you to determinate how much guard bar damage an attack deals (You know, this attack deals X damage to the guard bar so you get guard crushed).
pls

PotS

Re: Can we unlock MUGEN's full potential? Here's one example!
#2  February 01, 2010, 12:22:12 am
  • ******
    • www.mugenguild.com/pots/
What I'm doing is using a HitDef parameter (envshake time IIRC) to store the attacker's ID, then using that ID I can check the guy's vars (or the helper's) to see what he meant to do with the hit.
Use anything you want from my works.  If you need to contact me use email, not private messages.

-Red-

Re: Can we unlock MUGEN's full potential? Here's one example!
#3  February 01, 2010, 12:37:24 am
  • ******
  • Complicated.cns
  • No, I've never played a Zelda game before, shut up
    • Argentina
how many uses you have with that technique? (Asking to know, not to mock about it : P). you think that may work better for a palfx system like in KOF? or is to avoid problems on simul? (Which I avoid by having a tag team system)
pls

PotS

Re: Can we unlock MUGEN's full potential? Here's one example!
#4  February 01, 2010, 12:47:13 am
  • ******
    • www.mugenguild.com/pots/
Half the reason I did it was to avoid problems in Simul, yes, but it also lets me do anything I want with the hits.  Think the current uses are just stun, juggle and special hit behaviours (shock etc), but they're only limited by what you can do with variables.

For KOF PalFX you'd just have the attacker set a variable, e.g. 0 for none 1 for red fire and 2 for purple fire, and the target would detect that and apply a PalFX on himself.
Use anything you want from my works.  If you need to contact me use email, not private messages.

Bastard Mami

Re: Can we unlock MUGEN's full potential? Here's one example!
#5  February 02, 2010, 02:09:24 am
  • ******
  • [E]
    • Mexico

  • Online
that sounds good, I was already using enshakes in the hitdefs as they should but this is an easy change anyway; too bad I am currently more concerned on getting the genral mechanics working right but I will keep on watching this topic.

-Red-

Re: Can we unlock MUGEN's full potential? Here's one example!
#6  February 03, 2010, 12:33:43 am
  • ******
  • Complicated.cns
  • No, I've never played a Zelda game before, shut up
    • Argentina
@ P.o.t.S._ now I remember why I didnt use such a clever yet simple trick, it's because of the double hits (cross counters), I found lots of problems with that, like movecontact not working because of the tick delay and movetype = H on the character, movecontact doesnt work and everything fucks up.

Then there's also the automatic target dropping on some circumstances and all that. I just dont like when stuff doesnt work like they should. I checked the way you trigger the flame effects on the enemy and they wont work right on simul (You yourself limited the helper number to 1 because It's probably just impossible to attach one helper per enemy burned without getting bugs).

I just love using those envshake tricks because they avoid those kind of bugs overall and since Im working on fullgames I dont need to rely on tricks that may be bogus on certain (sometimes very rare) situations :P.

Perfectionist bitch
pls

PotS

Re: Can we unlock MUGEN's full potential? Here's one example!
#7  February 03, 2010, 12:44:58 am
  • ******
    • www.mugenguild.com/pots/
Rednavi said, February 03, 2010, 12:33:43 am
because of the double hits (cross counters), I found lots of problems with that, like movecontact not working because of the tick delay and movetype = H on the character, movecontact doesnt work and everything fucks up.

Then there's also the automatic target dropping on some circumstances and all that.
It doesn't make use of any of that, that's why I coded special hits through it instead of TargetState/whatever.

[E]: I messed up up there, it's not regular envshake but fall.envshake (time).
Use anything you want from my works.  If you need to contact me use email, not private messages.

-Red-

Re: Can we unlock MUGEN's full potential? Here's one example!
#8  February 09, 2010, 12:16:39 am
  • ******
  • Complicated.cns
  • No, I've never played a Zelda game before, shut up
    • Argentina
Im alienated to fullgame coding, that's why I mess up when someone talks to me about stuff I dont use :P

can you explain how do you do that? or im just getting it the wrong way and in fact both of us are talking about the same :P

Quote
What I'm doing is using a HitDef parameter (envshake time IIRC) to store the attacker's ID, then using that ID I can check the guy's vars (or the helper's) to see what he meant to do with the hit.

you mean what? storing the ID of the char that hits you? or to store your target's ID? How do you store the ID of the one who attacks you? I think that would expand my chances of making more stuff on my fullgame because using one parameter for just 1 or 2 things may end up limiting me (I even use fall.damage to identify if an attack can be interrupted with some sort of BURST).

pls

Epic Winnery

Re: Can we unlock MUGEN's full potential? Here's one example!
#9  February 09, 2010, 02:41:40 am
  • ****
  • FTW!!!
PotS said, February 01, 2010, 12:22:12 am
What I'm doing is using a HitDef parameter (envshake time IIRC) to store the attacker's ID, then using that ID I can check the guy's vars (or the helper's) to see what he meant to do with the hit.

Sounds like something that is possible to "mimmick" the opponent's super and or make a Life Point system instead of the Life Bars.

And I've read some time ago that if you needed to do this certain code to projectiles so it wouldnt bounce back. Then I was thinking "Why not add that code to characters who have reflective barriers?"

What does envshake even do anyways?  :P

PotS

Re: Can we unlock MUGEN's full potential? Here's one example!
#10  February 09, 2010, 10:57:25 am
  • ******
    • www.mugenguild.com/pots/
Rednavi said, February 09, 2010, 12:16:39 am
you mean what? storing the ID of the char that hits you? or to store your target's ID?
The character that hit you.

Rednavi said, February 09, 2010, 12:16:39 am
How do you store the ID of the one who attacks you?
Kinda the same way I suppose you were storing all the stuff you sent by HitDef parameters. Here's the current code:

[State 200, Hit]
type = hitdef
...
fall.envshake.time = ID

[State -2, Attacker ID]; Var is just to simplify, this step could be cut I guess
type = varset
trigger1 = movetype = H
trigger1 = gethitvar(fall.envshake.time)
trigger1 = playerIDexist(gethitvar(fall.envshake.time))
var(16) = gethitvar(fall.envshake.time)
ignorehitpause = 1

And from there you just redirect stuff with playerID(var(16)), like:

[State 5000, Juggle Receive]
type = varadd
trigger1 = !time
trigger1 = var(16)
var(29) = playerID(var(16)), var(28)
ignorehitpause = 1
Use anything you want from my works.  If you need to contact me use email, not private messages.

Bane84

Re: Can we unlock MUGEN's full potential? Here's one example!
#11  February 09, 2010, 12:45:47 pm
  • avatar
  • ***
  • Original characters are my forte.
    • http://network.mugenguild.com/bane84/
I've actually used this implementation in my SSBB core.  Works great with the playerID redirection trigger (or whatever it's called).

-Red-

Re: Can we unlock MUGEN's full potential? Here's one example!
#12  February 10, 2010, 01:02:16 am
  • ******
  • Complicated.cns
  • No, I've never played a Zelda game before, shut up
    • Argentina
Ah I see! the player ID is the same as the hitshake and you analize each var and use another for different situations (Bah like you said, I just didnt pay attention). Seems like I'll run out of variables If I have to use this :(

so if you use this to make a stun substraction code you'll have to set a variable on each state right? One more var for that system...

Anyway, I have yet to find a way to fix the ultimate shit on mugen: when you kill someone the enemy goes further than usually (extra velladds when the enemy dies) but I checked the states and there's no extra veladds when dead.

Infact I discovered that this only happens on the common (special) gethit states and also only if they are using the common anim for that state (My K' has a second anim for when looking on the other side as its double sided and when he's killed on the other side no extra velocity is applied).

I was able to fix the hitliedown states so when you are down you can't get up faster, this is easy as it's just a new state mimicking that one but since it's a new state it wont have that special property.

However you also have to replace the bouncing states as they give you full invincibility if within 10 ticks from getting up.

hmmm... I guess I'll talk about how to make a pause menu without glitches on the command buffering next time :P


EDIT:

Quote
Kinda the same way I suppose you were storing all the stuff you sent by HitDef parameters. Here's the current code:

I dont use "playerIDexist" stuff on those things, I just use gethitvars on the states that should read them since it's a fullgame and all that...
pls
Page 1 of 11   Go Up