Organized HitDef

[RobotMonkeyHead]

Personally I'm not a huge fan of the way the default HitDef controller is laid out in FF.  So I organized it in a way that makes sense to me.  Now, I just opened up FF and replaced the HitDef Sctrl's automatic text with it, so now when I select HitDef from the Sctrls column on the right side of the cns editor, I get this instead.  But of course you could just save it as a txt file and copy / paste it, if that's worth the extra little hassle for you.

Every line is set to it's default value, and if it's default is derived from another variable, a comment says how.  It looks like a lot at first, but the first thing I do after calling this is delete all the lines I don't need to change.  It trims down to the minimum variables very quickly and easily. 

I just figured I'd share it on here in case anyone else happened to find it useful as well.  Hope it helps someone at least!
 

[State 0, HitDef]
type = null; HitDef
trigger1 = 1
;_________________________________/ Basics
;   SCA: stand, crouch, air
;   N: normal, S: special, H: hyper
;   A: attack, P: projectile, T: throw
damage = 0,0        
getpower = 0,0      
givepower = 0,0     
attr = SC, HA       ; SCA, NA NP NT  SA SP ST  HA HP HT
hitflag = MAF       ; MHLAFD+-  medium(=HL), high, low, air, fall, down
guardflag = MA      ; MHLAFD+-  default = empty / unguardable
affectteam = E      ; EFB enemy, friend, both
priority = 4, Hit   ; on mutual hit: (1-7), (Hit, Miss, Dodge)
p1sprpriority = 1   
p2sprpriority = 0   
;_________________________________/ Sparks, Sounds & Pauses
sparkxy = 0,0      
;sparkno = ; player const
;hitsound = ; player const
pausetime = 0,0     
;guard.sparkno = ; player const
;guardsound = ; player const
guard.pausetime = 0,0
;_________________________________/ Ground Hit
animtype = light           ; light,medium,hard,back,up,diagup
ground.type = high         ; high,low,trip,none
ground.velocity = 0,0  
ground.hittime = 0     
ground.slidetime = 0  
;ground.cornerpush.veloff = ; 1.3 * guard.velocity unless attr = A, ... then 0
;_________________________________/ Air Hit
;air.animtype = ; animtype
;air.type = ; ground.type
air.velocity = 0,0
air.hittime = 20
;air.cornerpush.veloff = ; ground.cornerpush.veloff
;air.fall = ; fall
air.juggle = 0
;_________________________________/ Down Hit
;down.velocity = ; air.velocity
down.hittime = 0           ; ignored if down.velocity y != 0
down.bounce = 0            
;down.cornerpush.veloff = ; ground.cornerpush.veloff
;_________________________________/ Guarded
;guard.velocity = ; x value of ground.velocity
;guard.hittime = ; ground.hittime
;guard.slidetime = ; guard.hittime
;guard.ctrltime = ; guard.slidetime
;guard.cornerpush.veloff = ; ground.cornerpush.veloff
;guard.dist = ; player const
;_________________________________/ Air Guarded
;airguard.velocity = ; air.velocity x * 1.5, air.velocity y / 2
;airguard.ctrltime = ; guard.ctrltime
;airguard.cornerpush.veloff = ; guard.cornerpush.veloff
;_________________________________/ Falling
yaccel = 1 ; 240p: .35  480p: .7   720p: 1.4
fall = 0                   
fall.damage = 0
fall.animtype = Back ; up if air.animtype is up, back otherwise
;fall.xvelocity = ; no change
;fall.yvelocity = ; no change
fall.recover = 1
fall.recovertime = 4
;_________________________________/ Hit Specifics
hitonce = 0 ; unless attr arg2 = ..., T then 1
numhits = 1
kill = 1
guard.kill = 1
fall.kill = 1
id = 0
chainID = -1
nochainID = -1
;mindist = 0,0          ; default = no change
;maxdist = 0,0          ; default = no change
;snap = 0,0             ; default = no change
;_________________________________/ States
;p1stateno = -1         ; default = no change
;p1facing = 0           ; default = no change
;p2stateno = -1         ; default = no change
;p2facing = 0           ; default = no change
p2getp1state = 1         
;p1getp2facing = 0      ; default = no change
;forcestand = 0         ; default = 0 unless ground.velocity y != 0, then 1
forcenofall = 0        
;_________________________________/ Palette
palfx.time = 0        
palfx.mul = 1,1,1
palfx.add = 0,0,0
;_________________________________/ Shake
envshake.time = 0
envshake.freq = 0
envshake.ampl = 0
envshake.phase = 0
fall.envshake.time = 0
fall.envshake.freq = 0
fall.envshake.ampl = 0
fall.envshake.phase = 0
;_________________________________/ Universals
;ignorehitpause = 0
;persistent = 0

[The Unexpected Visitor]

Where is forcenofall?

[RobotMonkeyHead]

Nice catch.  Added.
Also updated sprpriority to 1.1s  p1sprpriority and p2sprpriority.

[Ryon]

This hitdef has way to much info on it. This is what I copy and paste.

 

[State 200, Hitdef]
type = HitDef

trigger1 = Time = 0

attr = S, NA

damage = 23, 0

animtype = Light ; Light , Medium , Heavy

guardflag = MA ; MAFD

hitflag = MAF ; MAFDL

priority = 3, Hit

pausetime = 8, 8

guard.pausetime = 0,0

sparkno = s8000

guard.sparkno = s8010

sparkxy = -10,-50

hitsound = s1, 0

guardsound = s2, 0

ground.type = High

air.type = High

ground.slidetime = 5

ground.velocity = -7

air.velocity = -7,-3

ground.hittime = 11

air.hittime = 11

airguard.velocity = -1.9,-.8

ground.cornerpush.veloff = 0

air.cornerpush.veloff = 0

down.cornerpush.veloff = 0

guard.cornerpush.veloff = 0

airguard.cornerpush.veloff = 0

fall = 0

;getpower = 0,0

[RobotMonkeyHead]

...I just copy and past this, then delete the parts I don't need. 

Always good to have multiple options tho.

[Ryon]

it is.

but having useless codes that are the same as default is not very optimized.

I'm speaking from a older mind set, present day computers can handle characters coded badly.

but years ago optimizing your code to not include useless lines of code was important, as a slow computer would lag during gameplay.

[RobotMonkeyHead]

Yea for me, deleting the parts I don't need includes deleting variables that are going to be set to the defaults anyway.

Maybe I'll update the original post at some point to include all the default variables with a note reminding coders to delete the variable if they're not going to change it, for the reason you're pointing out.

Thanks for the tip.

EDIT: First post updated.

[RobotMonkeyHead]

it is.

but having useless codes that are the same as default is not very optimized.

I'm speaking from a older mind set, present day computers can handle characters coded badly.

but years ago optimizing your code to not include useless lines of code was important, as a slow computer would lag during gameplay.

Yea as someone who's been coding over 2 decades, I hear that loud and clear.

Anyway, now that the lags not so bad on the post editor, I've updated the first post with the one I've been using lately.
The formula for it goes: 

* Every variable is set to it's default value (except guardflag). 
* If the default value is not a number, but instead is dependent on another value, that value is listed as a comment.
* All variables who's value depends on another variable are commented out.  This is for easy optimizing and so it's ready to go as pasted.
* Notes are added to clarify the defaults of some variables.

[Demitri]

I think this idea is neat (heh, get it?)

I hate how messy hitdefs can get. And it's easy to erase what isn't needed right away/at all

[Ryon]

It looks sorta better now. (I don't remember how it looked before)

but this is nice cause it shows you all possibilities, but as i said before lots of info thats not needed.

and I think for moves with multiple hitdefs it would be Huuuuuges. plus there could be alot of confusion to what codes do.

regardless nice work.

[RobotMonkeyHead]

I think this idea is neat (heh, get it?)

I hate how messy hitdefs can get. And it's easy to erase what isn't needed right away/at all

Thanks, I'm happy to hear someone else finding this useful too :) 
I might do the same thing for Projectiles, Explods and Helpers soon, so if ya like this, keep an eye out.

It looks sorta better now. (I don't remember how it looked before)

but this is nice cause it shows you all possibilities, but as i said before lots of info thats not needed.

and I think for moves with multiple hitdefs it would be Huuuuuges. plus there could be alot of confusion to what codes do.

regardless nice work.

Thank you :) I actually wind up with much smaller more efficient hit defs this way.  Relatively tiny actually. 

Everything's set to it's default, so the first thing I do after I paste this is delete every line I don't plan on messing with (including the section labels and comments). 

In the OP, that's what I meant by "it trims down to next to nothing (or the bare minimum anyway) very quickly and easily."  Starting with all the variables is just so you can see all the options off the bat, and the grouping makes it easy to eliminate huge chunks at a time.
 

[Ryon]

do you have an example of these trimmed versions?

seeing everything off the bat is great and all.

but seeing everything and not using have of it is another thing.

I think if you gave everyone a idea of what you BASICALLY need for a nice small optimized hitdef (since when a code is not written it is defaulted) that would be great.

[RobotMonkeyHead]

Sure thing. 

Here's an example of the hitdef for the rolling part of Wario's Snowman hyper.  Notice literally every single unnecessary thing is gone, because I knew what its default was, or what other variable it depended on so I could delete it without worry.  That usually takes less than 2 minutes. I also trim off the section labels and usually the comments.  Once I have it down to just the variables I need, working with it is cake. :)

[State 0, HitDef for Rolling Attack]

type = HitDef

trigger1 = root, stateno = 2105

damage = 75,10

attr = SCA, HA

hitflag = MAFD

guardflag = MA

priority = 7, Hit

p1sprpriority = 5

sparkxy = 0,0

;sparkno = ; not added yet

;hitsound = ; not added yet

;guard.sparkno = ; not added yet

;guardsound = ; not added yet

ground.velocity = -6, -12

air.velocity = -6, -12

fall = 1

fall.recover = 0

persistent = 24

[Ryon]

may i ask, why are the sparkno, hit sound, guardsparkno, and guard sound not needed?

Don't you think every move needs to have some form of impact?

also why is your trigger1 = root, stateno , thats almost the same as trigger1 = 1 ?

[RobotMonkeyHead]

The sparks, and sounds are commented as "not added yet", because the character this came from is currently under construction, but they will be there in the end. 

Even when absent, however, they default to the players constants (as noted in the op), so this hitdef would actually have them, be they random and misaligned as all hell.

As for the trigger, this came from a helper that stays in a single state while its root / parent goes through a number of different states which each trigger various animations and hitdefs in the helper in this way.

Your point is solid tho, I could have used a simpler example for a demo's sake.  Here's what the one above would look like if I'd taken that into consideration:

[State 0, HitDef ]

type = HitDef

trigger1 = animelem = 6

damage = 75, 5

attr = SCA, HA

hitflag = MAFD

guardflag = MA

priority = 7, Hit

p1sprpriority = 5

sparkxy = 40, 20

sparkno = 6300

hitsound = S10, 1

guard.sparkno = 6340

guardsound = S20, 1

ground.velocity = -6, -12

air.velocity = -6, -12

fall = 1

fall.recover = 0

persistent = 24

[Ryon]

lol persistent is a Boolean. meaning 1 true, or 0 false.

 

[RobotMonkeyHead]

 

lol persistent is a Boolean. meaning 1 true, or 0 false.

 

No, it's not.  If persistent isn't 0 or 1 it causes the trigger to activate once every nth occurrence of its truth value.  It's a logical truth modulation function, similar to the mathematical %.

 

 

[Ryon]

honestly i've never seen anyone use it other than 1 or 0.

your the first person i've seen to use it like that.

Me personally I use a time%#=#

[RobotMonkeyHead]

Yea a lot of the time, time % x = 0 is my goto as well XD

---

in case an explanation turns out to be helpful for someone reading this at some point in the future:

The reason for using 'persistent' here is that the attack anim is triggered at some random point within the same state. Using time wouldn't work because there's no saying how long this state is going on before the attack anim kicks off.

I would have used trigger = anim = x && animelemtime(1) % 24 = 0 but the animation loops more quickly than 24 frames, and I didn't want it to hit once per loop, but instead once every 24 tics from when it started. On top of that the animation changes during the entire sequence.

The sequence of attack animations is triggered by the root being in a particular state, so I just triggered the hitdef with the roots state and used 'persistent' to retrigger it once every 24 frames from there.

I realize it's kind of a mind fuck, but hopefully someone reading this finds it helpful at some point :)

[Demitri]

Informative :)

[Cayne]

Okay well someone just please be my fucking Obi-wan already? Just looking at this debate set my char back another month. RRRRRRRRRRRRRRRRRRGGGGGGGGGGGGGGGGhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhHHHHHHHHHHHHHHHHHHHHHHHHHH

[RobotMonkeyHead]

hahaha ok I'll tell ya what, if you ever want to summon me to your wip thread just write @RobotMonkeyHead (not sure why it has to be the first thing on the line in order to work) and ask a question.  It'll show up in my notifications and I'll go to your thread and do my best to answer it.  That's about as Obi Wan as I can do for ya ;D

 

[Demitri]

:P I assume this offer is open all who have commented in this thread? (not that i'd need to summon ya often)

[Cayne]

@Genesis Uses Jedi hand motion

This is not the thread your looking for...................................................... Your already a Jedi dude.

[Ryon]

Same here, don't be afraid to summon me if you need help.

@ me, or PM me, or genesis you have me on skype.