Posted by Bannana
in (Extra Bout) Fatal Fury (Started by Bannana April 30, 2021, 01:36:50 amBoard: Projects
https://streamable.com/bp00h0
Bannana is Offline
Contact Bannana:
Profile Info
Show content
This section allows you to browse the content for this member. Note that you can only see content for which you have sufficient viewing permissions.
Messages by Bannana
Posted by Bannana
in (Extra Bout) Fatal Fury (Started by Bannana April 30, 2021, 01:36:50 am
Board: Projects
I'm mostly working on gravity and weight modifications at the moment, but here's an example of a Heat move to show some slight progress
https://streamable.com/bp00h0
Posted by Bannana
in (Extra Bout) Fatal Fury (Started by Bannana April 30, 2021, 01:36:50 am
Board: Projects
I completely understand the fatigue, and because of that reality I spent a lot of time on my system backends to automate character creation as much as possible. Currently I only have to really code the four special attacks, the rest of the character can be easily built from editing the variables in the backend.
Posted by Bannana
in (Extra Bout) Fatal Fury (Started by Bannana April 30, 2021, 01:36:50 am
Board: Projects
A - Punch
B - Kick
C - Strong
⮩ 6/4C - Redirect instead of a normal throw, characters have redirects that turn the opponent around and leave them open
D - Quick Sway taking the place of lanes are quick sway options, all of which has specific invul properties
⮩ 5D - Standing Dodge high invul
⮩ 2D - Hop dodge low invul
⮩ 6D - Forward Dodge fully invul after 6 frames
Specials
There are three types of specials, grouped by what modifies them
Break A special with two levels of power mapped to A and B, can be canceled early by breaking with AB
Escalation Two different specials mapped to A and B respectively, upon entering escalation mode the properties of these change.
Heat A special mapped to C, when heat is full this move becomes an alternate overdrive version of itself.
Heat bar
Derived from Wild Ambition, the heat bar fills during neutral only--movement, whiffing, and so on. It fills based on your velocity; therefore, a faster character will gain heat faster. Filling it up drops proration modifiers, giving full damage, allows for the overdrive form of the heat move, and the use of avoid during hitstun.
Heat allows for these options
AB - Heat Blow reset your opponent to neutral during hitstun at the cost of very little damage
AB - Counter Heat Blow an all or nothing opportunity to put the opponent in a counter hit state and deal major damage
ABC - Escalation mode changes the properties of special moves, and how hittimes are calculated
Escalation mode
Escalation mode changes the properties of special moves and how hittimes are calculated.
Escalation allows for these options
AC - Feint cancels the current move, regardless of its cancel status
AAAC/AABC/ABBC - Chain routes
Unlike Real Bout, only the standing punch and kick buttons are used to chain, with crouches and strong existing as possible chain enders, making the way the system works much closer to a simplified Ninja Master's or even Tekken strings. Chains are a series of three inputs made up of combinations of the standing A and B buttons, with a C finisher, thus:
AAAC
AABC
ABBC
These may seem simple, BUT standard canceling rules also apply to them; thus, the generic AB cancel flow can be canceled from an AAA, so it's really not AAA but AAAB; moreover, because special cancel rules also apply, things like canceling Gato's BA from the chart also works, so a BAAAB is possible inasmuch as you can connect the moves. Moves specific to chains benefit from a free x vel push, as in Real Bout, making them a handy way to close a distance that otherwise might require walking forward.
All of these have three possible ends to the routes. The first is canceling into a special move, as with any other normal; the second is a 2C, a free knockdown that can provide much needed oki options; the third, however, is of most interest, a 5C option that is determined by he preceding three moves in the chain.
The flow of the chain adds another layer to the cancel chart, making escalation mode an option just as viable as expending heat on an EX move.
Neutral game
Using a modified version of Vans' buffer system and JZ's deep buffering, I'm hoping this has the most nuanced form of directional buffer of any mugen style, and consequently the deepest and most impactful movement. Because my goal is a successor to Real Bout, a series with very tight, fast, and meaningful movement, I want to make it a major part of the game, dealing with the loss of lineswaying from RB by creating a game that is entirely built around it.
Movement options are the standard Fatal Fury jumps and hops, but to create an interesting neutral game, the properties of all forms of movement can be altered by how the buttons are pressed, and in what order, just like the difference between jump and hop and running jump in kof.
In addition, jump arcs can be altered in mid air by pressing left, right, or down.
Running and super jumps are also available.
Passing Bonus
To keep with the movement based game, Just Defend no longer leads to Guard Cancels, but the Passing Bonus. Upon successful JD, a directional can be pressed, which allows for the player to set up options during the hit pause where they would otherwise be in block stun.
B- dash
U - hop
F - dash
In addition this can be done during air JD, which gives otherwise unavailable options
F - Air dash
B - Air backdash
U - hop cancel
D - fastfall
In both situations Passing Bonus allows for special/super canceling the moment the recovery animation for the movement begins.
Characters
Spoiler: Kevin Rian (click to see content)Spoiler: Hokutomaru (click to see content)Spoiler: Sokaku (click to see content)Spoiler: Grant (click to see content)
Spoiler: The full package (click to see content)
Posted by Bannana
in Random Topic V10 (Started by Orochi Gill July 09, 2016, 05:00:44 am
Board: All That's Left
Ah okay, you're the exact opposite of me lol
I mostly play Fatal Fury/Real Bout
Posted by Bannana
in Random Topic V10 (Started by Orochi Gill July 09, 2016, 05:00:44 am
Board: All That's Left
whatchu play on fightcade?
Posted by Bannana
in The Final Frontier: Bayonetta. (Started by Ogre. April 17, 2021, 10:23:31 pm
Board: M.U.G.E.N Discussion
I too am fluent in the Electbyte docs, not only the 1.1 dialect but also in the extinct Winmugen branch and its No Limit Patch permutation
Posted by Bannana
in SFIV_Historic Distillery 1.0/1.1 (Started by Kamui_De_Los_Vientos March 30, 2021, 07:55:39 pm
Board: Your Releases, 1.0+
The quality of the backgrounds look great on this, might be your best one yet!
Posted by Bannana
in A couple questions (Started by SPzero65 March 22, 2021, 10:08:08 pm
Board: M.U.G.E.N Development Help
I'd have to think about the second, but the first and third I can answer immediately
! before a trigger always means that the trigger is to be activated if it's not true, that is, returns 0. It's used like a boolean, but instead of working as either 1 or 0, it's any integer, positive or negative, or 0.
!movecontact is equivalent to movecontact = 0
movecontact is equivalent to movecontact = 1
!var(30) is equivalent to var(30) = 0
var(30) is equivalent to var(30)=1 AND var(30) = -1
For the looping attack, use multiple hitdefs. Generally you can use one with trigger1 = animelem = x and trigger2 = animelem = y, but sometimes triggering one hitdef multiple times can get buggy. It also gives you more control over each hit in the sequence as opposed to having to use the same values each time.
Posted by Bannana
in Gato+ (Garou JET) 100% (Started by Bannana January 06, 2021, 01:14:27 am
Board: Your Releases, 1.0+
Bugfixes and hud stuff, go to the site
Spoiler: 3/15/21 -ver- TEXT && HUD (click to see content)
Posted by Bannana
in Amnaelio released Chae-Lim (Started by Yagoshi300 March 05, 2021, 12:25:03 am
Board: Found Releases 1.0+
Though I understand the thoughts on the sprite work, both positive and negative, the question here comes down to the question of the spirit of mugen and whether or not we should be allowed to monetize our work AND whether or not that work should be open and available freely without any sort of gatekeeping.
I have no comments on the YouTube aspect.
For me that major issue here is the question of a Patreon: for spriting or for characters? If the former, whatever; if the latter, then it's problematic.
So I agree here with everyone but I'm more interested in this other issue of whether or not he is monetizing the work of another creator in the first place, because here's where the old open source debate reappears. Though it's Ahuron, Ikaruga appeared in the thread so he should be discussed in general as an example: he has a very strict use policy (http://ikrgmugen.web.fc2.com/policy.txt ); however, his work rests on fanwork that uses material without explicit permission of SNK, SO whose wishes do we respect? Does Ikaruga have a say in the matter at all, or may his work be sprite swapped, with or without credit, because he has no base to make any policy for the use of his work?
Despite the questions of the ramifications of ripping assets from a game and telling others not to use/modify your work, this creator is at fault for not respecting Ikaruga's wishes. If this were Mouser or Tora, a creator who is no longer active, it doesn't matter, but Ikaruga IS active.
Posted by Bannana
in Garou: Mark of the Wolves AutoHitdef (Started by Bannana March 08, 2021, 02:17:25 am
Board: Code Library
Part III - PROPERLY FORMATTING THE HITDEF
Having defined all our values, we now need to get the hitdef to recall them. This will be the easiest part and will mostly come down to copy-pasting certain sections into the hitdef.
So here's the hitdef from before, but I've bolded the areas that you can automate and italicized those you can't:
type = HitDef
trigger1 = animelemtime(helper(222222),var(0))=0
attr = S,NA ;SCA,NA,SA,HA,NP,SP,HP,NT,ST,HT
hitflag = MAF ;HLAFD+-
guardflag = M ;HLA
animtype = medium ;Light, Medium, Hard, Back, Up, DiagUp
priority = 3, Hit
damage = floor((helper(222222),var(1))*fvar(30)),floor((helper(222222),var(7))*fvar(30))
pausetime = (helper(222222),var(2)),(helper(222222),var(3))
sparkno = -1
guard.sparkno = -1
hitsound = S0, (helper(222222),var(15))+random%2
guardsound = S1, 0
ground.type = high ;Low, Trip, None
ground.slidetime = (helper(222222),var(4))
guard.slidetime = (helper(222222),var(4))
ground.hittime = (helper(222222),var(5))
guard.hittime = (helper(222222),var(5))
guard.ctrltime = (helper(222222),var(5))
air.hittime = (helper(222222),var(5))
ground.velocity = (-2.29473946*fvar(9))-fvar(11),0
air.velocity = -2.204769373,-6.6174449*fvar(10)
airguard.velocity = -2.204769373*fvar(9),-6.6174449*fvar(10)
getpower = floor((helper(222222),fvar(1))),floor((helper(222222),fvar(1))-(helper(222222),fvar(3)))
givepower = floor((helper(222222),fvar(1))),floor((helper(222222),fvar(1))-(helper(222222),fvar(3)))
essentially, this hitdef is complete, all you have to do is follow the variables defined in the system.hitdef. Certain things such as the attributes that don't use ints or floats have to be manually changed, and as you can see I did not automate any velocities because those are highly specific to most moves.
For example, take note of how Gato's close D move works. Not only is it a two hit move, but one with drastically different attributes and velocities between hitdefs.
Code: [State HitDef]
type = HitDef
trigger1 = animelemtime(helper(222222),var(0))>=0
attr = S,NA ;SCA,NA,SA,HA,NP,SP,HP,NT,ST,HT
hitflag = MAF ;HLAFD+-
guardflag = M ;HLA
animtype = hard ;Light, Medium, Hard, Back, Up, DiagUp
priority = 4, Hit
damage = floor((helper(222222),var(1))*fvar(30)),floor((helper(222222),var(7))*fvar(30))
pausetime = (helper(222222),var(2)),(helper(222222),var(3))
sparkno = -1
guard.sparkno = -1
hitsound = S0, (helper(222222),var(15))+random%2
guardsound = S1, 1
ground.type = low ;Low, Trip, None
ground.slidetime = (helper(222222),var(4))
guard.slidetime = (helper(222222),var(4))
ground.hittime = (helper(222222),var(5))
guard.hittime = (helper(222222),var(5))
guard.ctrltime = (helper(222222),var(5))
air.hittime = (helper(222222),var(5))
ground.velocity = cond(animelemtime(helper(222222),var(0))=0,(-.5),(-2.29473946*fvar(9)-fvar(11))),0
air.velocity = -2.204769373,-6.6174449*fvar(10)
airguard.velocity = -2.204769373*fvar(9),-6.6174449*fvar(10)
getpower = floor((helper(222222),fvar(1))),floor((helper(222222),fvar(1))-(helper(222222),fvar(3)))
givepower = floor((helper(222222),fvar(1))),floor((helper(222222),fvar(1))-(helper(222222),fvar(3)))
[State HitDef]
type = HitDef
trigger1 = animelemtime(helper(222222),var(50))>=0
attr = S,NA ;SCA,NA,SA,HA,NP,SP,HP,NT,ST,HT
hitflag = MAF ;HLAFD+-
guardflag = M ;HLA
animtype = hard ;Light, Medium, Hard, Back, Up, DiagUp
priority = 4, Hit
damage = floor((helper(222222),var(1))*fvar(30)),floor((helper(222222),var(7))*fvar(30))
pausetime = (helper(222222),var(2)),(helper(222222),var(3))
sparkno = -1
guard.sparkno = -1
hitsound = S0, (helper(222222),var(15))+random%2
guardsound = S1, 1
ground.type = high ;Low, Trip, None
ground.slidetime = (helper(222222),var(4))
guard.slidetime = (helper(222222),var(4))
ground.hittime = (helper(222222),var(5))
guard.hittime = (helper(222222),var(5))
guard.ctrltime = (helper(222222),var(5))
air.hittime = (helper(222222),var(5))
ground.velocity = cond(animelemtime(helper(222222),var(0))=0,(-.5),(-2.29473946*fvar(9)-fvar(11))),0
air.velocity = -2.204769373,-6.6174449*fvar(10)
airguard.velocity = -2.204769373*fvar(9),-6.6174449*fvar(10)
getpower = floor((helper(222222),fvar(1))),floor((helper(222222),fvar(1))-(helper(222222),fvar(3)))
givepower = floor((helper(222222),fvar(1))),floor((helper(222222),fvar(1))-(helper(222222),fvar(3)))
So, with a little patience, and a tiny bit of work, you'll have consistent, easily editable hitdefs according to a Garou standard. And, realistically, with a little work on the backend you could modify this for any other kind of game!
If you have any questions, don't hesitate to ask!
Posted by Bannana
in Garou: Mark of the Wolves AutoHitdef (Started by Bannana March 08, 2021, 02:17:25 am
Board: Code Library
Part II - EXPLORING THE SYSTEM.HITDEF
Download the system.hitdef file and open it up in notepad/fighter factory/whatever. Go to line 70, which shows an example of the main type of string for normals
Code: trigger1 = root,stateno = 200 && root,animelemtime(1)=0
trigger1 = var(0):=4 && var(1):=4 && var(7):=0 && var(2):=8 && fvar(2):=1 && fvar(4):=1 && var(10):=46 && var(11):=-69 && var(15)=0
If you've been following so far, or even already looked through the file, each of these variable assignments represents a frontend value. They're explained in the previous part, but I will explain all of them directly here
var(0) = animelem, this is the active frame of your animation (the one with the red clsn)
var(1) = damage, this is either your raw damage, to be corrected later, or the fully corrected version, whatever method you prefer
var(7) = guard damage, follows the same methodology as damage
var(2) = p1 pausetime, this is the only hittime value you need to edit, the rest is done automatically through the backend
fvar(2) = severity modifier on hit
fvar(4) = severity modifier on block
var(10) = spark pos x
var(11) = spark pos y
var(15) = hitsound
What you might have noticed is that I took all of the hitdef values that can be assigned to a variable (i.e. intergers and floats) in MUGEN and had them assigned here. This means that within about 200 lines or so you can assign all normals without having to go through your giant CNS files, saving a great deal of time!
HOWEVER, for a two hit move there is a problem! There are some issues I came up with attempting to rewrite var(0) midway through the state and recalling it as trigger2, so, since the range of 50-59 was free I decided to allocate multihits up to 10 with those.
Take note of this on line 153:
Code: trigger1 = root,stateno = 215 && root,animelemtime(5)=0 ; *2-pt
trigger1 = var(50):=6 && var(1):=6 && var(7):=0 && var(2):=8 && fvar(2):=1 && fvar(4):=1 && var(10):=40 && var(11):=-86 && var(15)=0
Next, specials, because they give power on whiff, follow a similar pattern, but we remove the two severity modifier fvars.
Go to line 166 (and line 198 for the two hit moves):
Code: trigger1 = root,stateno = 1000 && root,animelemtime(1)=0
trigger1 = var(0):=8 && var(1):=10 && var(7):=2 && var(2):=12 && var(10):=60 && var(11):=-63 && var(15)=12
severity for these moves is applied for each move specifically because the power gain values are different for each.
On line 207 this set of assignments shows how it works:
Code: ; These cover specials that lie outside of standard hitdef qualities
[State severity determination]
type = Null
trigger1 = root,movetype != A
trigger1 = fvar(2):=0
; throw
trigger2 = (root,stateno = 800)
trigger2 = fvar(2):=3
; light specials whiff
trigger3 = root,time<=4
trigger3 = (root,stateno = 1000) || (root,stateno = 1100) || (root,stateno = 1200)
trigger3 = fvar(2):=6
; light specials hit
trigger4 = root,time>4
trigger4 = (root,stateno = 1000) || (root,stateno = 1100) || (root,stateno = 1200)
trigger4 = fvar(2):=2
; heavy specials whiff
trigger5 = root,time<=4
trigger5 = (root,stateno = 1050) || (root,stateno = 1100) || (root,stateno = 1250)
trigger5 = fvar(2):=7
; heavy specials hit
trigger6 = root,time>4
trigger6 = (root,stateno = 1050) || (root,stateno = 1100) || (root,stateno = 1250)
trigger6 = fvar(2):=3
And for the guard values, go to line 259:
Code: ; Guard constant
[State guard determination]
type = Null
trigger1 = root,movetype != A
trigger1 = fvar(4):=0
; light specials
trigger2 = (root,stateno = 1000) || (root,stateno = 1100) || (root,stateno = 1200)
trigger2 = fvar(4):=1
; heavy specials
trigger3 = (root,stateno = 1050) || (root,stateno = 1100) || (root,stateno = 1250)
trigger3 = fvar(4):=2
Much of this should be incredibly straightforward, especially with normals, so what should be difficult is dealing with specific situations with special moves, and sometimes that means you might not be able to use the autohitdef and would be better just making a manual hitdef.
That being said, in Part III I'll explain how this all comes together into the generic hitdef.
Posted by Bannana
in Garou: Mark of the Wolves AutoHitdef (Started by Bannana March 08, 2021, 02:17:25 am
Board: Code Library
This will be split into three posts to maintain clarity
Part I - INTRODUCTION AND METHODOLOGY
Part II - EXPLORING THE SYSTEM.HITDEF
Part III - PROPERLY FORMATTING THE HITDEF
Part I - INTRODUCTION AND METHODOLOGY
A majority (if not all, but I'm not going to make that argument) of games have universal pausetimes, hittimes, slidetimes, etc. for all normals and most specials (barring weird things like fireballs and supers). Garou's is incredibly simple, but is highly important for correct combo timings because all frame advantages, especially breaks, align with the pause/hit/slidetime. I dunno if anyone is looking to make more MotW characters, or even do stylistic edits in the manner of Kn (totally worth it), but this would make both of those much faster.
I personally hate the hitdef. It's inefficient because, in an efficient program, all of the valuable information concerning damage, scaling, hittime, pausetime, etc would be backend values that are called upon by the hitdef; therefore, a lot of time is wasted trudging through the cns to edit states, and I thought it would be better, and more efficient, to assign all of these functions to a file that only consists of less than 500 lines that need to be edited; moreover, because no hitdef is ever active on the first frame, so we don't have to deal with theoretical 1 tick delay, it makes perfect sense to just assign these to a helper in general.
So, in Gato+ I decided to diminish the actual amount of physical editing you have to do in any file but the AutoHitdef file,
Spoiler: leading to this (click to see content)
As far as I'm concerned, an attack state should consist of two sections:
Spoiler: Mandatory front end, e.g. sound clips on startup that are specific to each move (click to see content)Spoiler: Absolute backened that should not have to be touched aside from particular specials and supers (click to see content)N.B. I use explods here, so if you were using hitsparks in the hitdef then you would just put "(helper(222222),var(10)),(helper(222222),var(11))" there for the x and y pos.
So, how does this work?
essentially, in a backend file we will make a list of all values that, because they never change, should be determined ahead of time, and then define whether those values are frontend or backend, the difference being that the backend are always calculations based on frontend values.
Spoiler: After doing this, I determined my list should be as so (click to see content)
And to explain the idea of how the frontend and backend works in practice, take my top two: animelem and idle. In Garou I determined that the average time an idle would occur would generally be 2-3 animelems after the active frame, so my backend calculation for var(6) is as follows
Code: ; Idle is ALWAYS set two frames after an active
[State idle set]
type = VarSet
trigger1 = var(0)
v = 6 ;fv = 10
value = var(0)+2
persistent=1
ignorehitpause=1
This sort of backend caluclation makes hittime in Garou easy to work with because all hittimes in Garou are based upon the root p1 pausetime
Code: ; pause/hit/slide time notes
; THESE TIMES ARE ABSOLUTELY UNIVERSAL, NOTHING HAS TO BE CHANGED ASIDE FROM SPECIALS
[State p2 pause]
type = VarSet
trigger1 = var(2)
v = 3 ;fv = 10
value = var(2)-1
persistent=1
ignorehitpause=1
[State slide time]
type = VarSet
trigger1 = var(2)
v = 4 ;fv = 10
value = var(2)+(var(2)/2)
persistent=1
ignorehitpause=1
[State hittime time]
type = VarSet
trigger1 = var(4)
v = 5 ;fv = 10
value = var(4)+2
persistent=1
ignorehitpause=1
Thus, a light punch pausetime of 8 will return p2 pausetime of 7, slidetime of 12, and hittime of 14, all of which are accurate to source.
A note on severity and power gain
Prior to revealing the code we need to go over how power works in Garou.
In Garou there is a root power value, 66537 (or, when corrected, 15), that I found is compounded by degrees of severity, so that each move will be allocated a certain level of severity based on movetype, strength, whiffing, hitting, etc.
You can see in my musings above that I thought quite a bit about how the patterns point to a possible methodology for assigning power to moves, and what I decided to do was take this raw value, 66537, set it to fvar(0), and apply two sets of calculations to it:
Code: ; Calculation of raw power value
[State raw calculation]
type = VarSet
trigger1 = 1
fv = 1 ;fv = 10
value = floor(((fvar(0) - 1)/4194.305)*fvar(2))
ignorehitpause=1
persistent=1
; Calculation of guard power value
[State guard calculation]
type = VarSet
trigger1 = 1
fv = 3 ;fv = 10
value = floor(((fvar(0) - 1)/4194.305)*fvar(4))
ignorehitpause=1
persistent=1
The severity modifiers here are fvar(2) and fvar(4), which, like p1 pausetime earlier, are the front end that we will edit manually, and the resulting values will be plugged into the hitdef automatically, giving correct power gain values.
With that, let's move on to Part II, where I'll explain how the auto-hitdef file works.
Posted by Bannana
in Gato+ (Garou JET) 100% (Started by Bannana January 06, 2021, 01:14:27 am
Board: Your Releases, 1.0+
Final version of the 4 button put out as a patch because I don't want to upload that sff again :p. Also available on the site.
Nothing actually major here except for adding in my chain module for Vans' Tiny Buffering and finishing up my auto-hitdef backend, but now I consider this 100% done in its current form. Obviously there are some graphical things that aren't done but shwa is pretty busy so no ETA on those.
Spoiler: the changelog (click to see content)
Posted by Bannana
in Tiny Chaining for Tiny Buffering (Started by Bannana March 03, 2021, 12:18:07 pm
Board: Code Library
If you're an old boomer like me, you play old games--and when I say old, I mean DUSTY ass games in the corner of the arcade that no one played because the lines were long and you just wanted to play--and you know of the esoteric, ancient, late 90s world of chain combos, where links don't matter and hitting random buttons don't work.
There are two types of chain combos:
buffered, or kara, chains, as found in in Real Bout
on hit chains, as found in Ninja Master's this game has HUGE chains, and is a major hidden gem, hmu to play some rounds
YES THOSE ARE SCANLINES, THEY LOOK GOOD WITH THEM OK i have old man eyes
In SNK games that aren't KOF or Mark of the Wolves, these chains are an important part of the game because they expand the standard SNK system of
normal xx special xx super
into
a > b > c xx special xx super
and this simple normal chaining develops in complexity to the point where you're throwing out 5 hits before you even cancel into the special:
Rick Strowd chain out of standing A (courtesy of Dream Cancel)
Karasu chain out of LP (courtesy of SRK)
N.B. If you're a french bread player,
you might see some major antecedents to the melty, and especially UNI, style of what I call a "progressive chain,"
a chaining of options up from a > c together before canceling (obviously not counting the perfection that is reverse beat).
So, enough about chains and to the topic at hand, this is a little module to add to Vans' Tiny Buffering to make chains worry free!
Before this, authors like Mouser would use a -2 bitwise variable:
Code: [State 200, VarSet]
type = VarSet
trigger1 = Time = 1
var(6) = 0
[State -3, VarSet]
type = VarSet
trigger1 = HitPauseTime
trigger1 = !(var(6) & 112)
var(6) = (command = "holdfwd") | (command = "holdback") * 2 | (command = "holddown") * 4 | (command = "holdup") * 8
ignorehitpause = 1
[State -3, VarSet]
type = VarSet
trigger1 = HitPauseTime
trigger1 = !(var(6) & 112)
var(6) = var(6) | (command = "a") * 16 | (command = "b") * 32 | (command = "c") * 64
ignorehitpause = 1
In this situation, the variable simply identifies that a certain combination of inputs happen, and that is cached and recalled in the -1:
Code: [State -1]
type = ChangeState
value = 320
triggerall = roundstate = 2
triggerall = (command = "b" && command != "holddown") || ((var(6) & 32) && !(var(6) & 4))
trigger1 = stateno = 200 && AnimElem = 4,> 0 && AnimElem = 7,< 0
trigger2 = stateno = 205 && AnimElem = 3,> 0 && AnimElem = 6,< 0
trigger3 = stateno = 210 && AnimElem = 4,> 0 && AnimElem = 6,< 0
trigger4 = stateno = 215 && AnimElem = 2,> 0 && AnimElem = 4,< 0
HOWEVER this is sort of a poor man's buffer. Mouser, while a great coder, is not buffering the inputs as a game would, but instead is just trying to catalogue possible combinations to appease mugen's input parser. The reason why he did this was because he had no method to work with inputs directly, which is why Vans initially developed Tiny Buffering. Because Tiny Buffering is heavily KOF based, and thus is highly compatible with SNK games, it can be used to buffer chains effectively, efficiently, and effortlessly.
THIS CODE USES THE MISC VAR(50)-VAR(59) VALUES THAT VANS LEFT OPEN, PLEASE NOTE THAT ANY VAR ISSUES DUE TO OVERRIDING ARE YOURS AND NOT MINE! REMEMBER THAT ALL CODE I OFFER MUST BE MODIFIED TO REFLECT THE COMMAND LAYOUTS OF YOUR CHARACTER!
The code, verbatim, is as so:
Code: ;------------------- CHAINING ---------------------------------------------------;
; BY BANNANA --- ye, i'm no longer a code borrower, but code lender! :^)
;var(0) is set to x, subtracts over time
;if var(1) is set *while* var(0) > 0, var(50) is set to x
;my rule of thumb - light attack = 10, heavy attack = 20
;if !var(50) during a state, then pressing button sets (50) to 3, because the hitpause puses the count and doesn't require a larger active number.
;thus, assuming A=x and B=y
[State 10371, B chain Dec]
type = VarAdd
triggerall = root, HitPauseTime = 0
trigger1 = var(50)
var(50) = -1
[State 10371, B chain Init]
type = VarSet
trigger1 = command = "y"
var(50) = cond(var(0),10,3)
And in the cmd you will write a trigger as so:
Code: trigger1 = (helper(10371), var(50) && (helper(10371),command != "holddown"))
trigger1 = stateno = [stateno] && animelemtime(x)>0 && animelemtime(x)<0
To explain this, it's best to explain why Vans' buffering works:
1) x is pressed, so a var(x) is set to x
2) at any point at which there is no hitpause, x counts down by 1 per tick
3) if a hitpause is in effect, that count will PAUSE
4) if x = 0, any buffer is null
Knowing this, my chain method piggybacks on this by using this logic:
1) x is pressed, so a var(x) is set to x
2) IF BUFFERED
>>>>>>>> y is pressed while var(x) > 0, then we can confirm that the move was meant to be buffered and var(y) is set to y
3) IF NOT BUFFERED
>>>>>>>> y is pressed while the hitpause of x is occuring, thus var(x) > 0; therefore, we can confirm that the move is meant to be buffered and var(y) is set to (y)
It's quite simple, yet I think much better than Mouser's, not only because it frees up a variable, but because it allows for inputs not to be categorized, but actually buffered, with the required timing defined and measured.
if you have any questions, or need clarification (because I'm no teacher :p), feel free to reply.
Re: 【 JtheSaltyy's WIP Thread 】: Future Character Poll
February 27, 2021, 11:09:03 am
View in topic context
Posted by Bannana
in Saltyy's WIPs: CvS2 Strider (Started by jay_ts September 13, 2020, 08:58:01 pm
Board: Projects
I like to see wacky stuff, so Khan for sure.
Re: Character of the Month: January 2021 Voting
February 26, 2021, 10:44:48 pm
View in topic context
Posted by Bannana
in Character of the Month: January 2021 Voting (Started by 【ＭＦＧ】gui0007 February 25, 2021, 03:26:01 pm
Board: Contributions of the Month
Tough choices here
Athena & Miles
Re: Code-heavy character mirror matches cause multiple glitches.
February 25, 2021, 05:20:51 am
View in topic context
Posted by Bannana
in Code-heavy character mirror matches cause multiple glitches. (Started by Kolossoni February 25, 2021, 04:38:32 am
Board: M.U.G.E.N Development Help
Off the top of my head, the helper issue might be the helpermax being reached, because unlike explods it has a cap at 56.
Re: Character of the Month: January 2021 Nominations
February 23, 2021, 12:16:56 am
View in topic context
Posted by Bannana
in Character of the Month: January 2021 Nominations (Started by 【ＭＦＧ】gui0007 February 09, 2021, 04:09:29 pm
Board: Contributions of the Month
oh I haven't nom'd any yet!
koop's already in so
The Mandalorian by CpnCrossfader - 2
Re: A few questions about what defines a compilation or fullgame
February 22, 2021, 12:19:05 am
View in topic context
Posted by Bannana
in A few questions about what defines a compilation or fullgame (Started by NecusX February 20, 2021, 06:01:50 pm
Board: M.U.G.E.N Discussion
Here's an easy example of the same character, Rasetsumaru, in the same style, Samurai Shodown V SP, by two very different creators, Ali and Montana.
https://streamable.com/2006h8
The ways in which different creators study games, whether or not they guess or use raw data, as well as how they choose to code that data, changes the outcome.
Compound this distinction with 20 characters all by different authors and you'll definitely find some discrepancies.
Posted by Bannana
in (Extra Bout) Fatal Fury (Started by Bannana April 30, 2021, 01:36:50 amBoard: Projects
https://streamable.com/bp00h0
Posted by Bannana
in (Extra Bout) Fatal Fury (Started by Bannana April 30, 2021, 01:36:50 amBoard: Projects
Posted by Bannana
in (Extra Bout) Fatal Fury (Started by Bannana April 30, 2021, 01:36:50 amBoard: Projects
B - Kick
C - Strong
⮩ 6/4C - Redirect instead of a normal throw, characters have redirects that turn the opponent around and leave them open
D - Quick Sway taking the place of lanes are quick sway options, all of which has specific invul properties
⮩ 5D - Standing Dodge high invul
⮩ 2D - Hop dodge low invul
⮩ 6D - Forward Dodge fully invul after 6 frames
Specials
There are three types of specials, grouped by what modifies them
Break A special with two levels of power mapped to A and B, can be canceled early by breaking with AB
Escalation Two different specials mapped to A and B respectively, upon entering escalation mode the properties of these change.
Heat A special mapped to C, when heat is full this move becomes an alternate overdrive version of itself.
Heat bar
Derived from Wild Ambition, the heat bar fills during neutral only--movement, whiffing, and so on. It fills based on your velocity; therefore, a faster character will gain heat faster. Filling it up drops proration modifiers, giving full damage, allows for the overdrive form of the heat move, and the use of avoid during hitstun.
Heat allows for these options
AB - Heat Blow reset your opponent to neutral during hitstun at the cost of very little damage
AB - Counter Heat Blow an all or nothing opportunity to put the opponent in a counter hit state and deal major damage
ABC - Escalation mode changes the properties of special moves, and how hittimes are calculated
Escalation mode
Escalation mode changes the properties of special moves and how hittimes are calculated.
Escalation allows for these options
AC - Feint cancels the current move, regardless of its cancel status
AAAC/AABC/ABBC - Chain routes
Unlike Real Bout, only the standing punch and kick buttons are used to chain, with crouches and strong existing as possible chain enders, making the way the system works much closer to a simplified Ninja Master's or even Tekken strings. Chains are a series of three inputs made up of combinations of the standing A and B buttons, with a C finisher, thus:
AAAC
AABC
ABBC
These may seem simple, BUT standard canceling rules also apply to them; thus, the generic AB cancel flow can be canceled from an AAA, so it's really not AAA but AAAB; moreover, because special cancel rules also apply, things like canceling Gato's BA from the chart also works, so a BAAAB is possible inasmuch as you can connect the moves. Moves specific to chains benefit from a free x vel push, as in Real Bout, making them a handy way to close a distance that otherwise might require walking forward.
All of these have three possible ends to the routes. The first is canceling into a special move, as with any other normal; the second is a 2C, a free knockdown that can provide much needed oki options; the third, however, is of most interest, a 5C option that is determined by he preceding three moves in the chain.
The flow of the chain adds another layer to the cancel chart, making escalation mode an option just as viable as expending heat on an EX move.
Neutral game
Using a modified version of Vans' buffer system and JZ's deep buffering, I'm hoping this has the most nuanced form of directional buffer of any mugen style, and consequently the deepest and most impactful movement. Because my goal is a successor to Real Bout, a series with very tight, fast, and meaningful movement, I want to make it a major part of the game, dealing with the loss of lineswaying from RB by creating a game that is entirely built around it.
Movement options are the standard Fatal Fury jumps and hops, but to create an interesting neutral game, the properties of all forms of movement can be altered by how the buttons are pressed, and in what order, just like the difference between jump and hop and running jump in kof.
In addition, jump arcs can be altered in mid air by pressing left, right, or down.
Running and super jumps are also available.
Passing Bonus
To keep with the movement based game, Just Defend no longer leads to Guard Cancels, but the Passing Bonus. Upon successful JD, a directional can be pressed, which allows for the player to set up options during the hit pause where they would otherwise be in block stun.
B- dash
U - hop
F - dash
In addition this can be done during air JD, which gives otherwise unavailable options
F - Air dash
B - Air backdash
U - hop cancel
D - fastfall
In both situations Passing Bonus allows for special/super canceling the moment the recovery animation for the movement begins.
Characters
Spoiler: Kevin Rian (click to see content)
Spoiler: Hokutomaru (click to see content)
Spoiler: Sokaku (click to see content)
Spoiler: Grant (click to see content)
Spoiler: The full package (click to see content)
Posted by Bannana
in Random Topic V10 (Started by Orochi Gill July 09, 2016, 05:00:44 amBoard: All That's Left
I mostly play Fatal Fury/Real Bout
Posted by Bannana
in Random Topic V10 (Started by Orochi Gill July 09, 2016, 05:00:44 amBoard: All That's Left
Posted by Bannana
in The Final Frontier: Bayonetta. (Started by Ogre. April 17, 2021, 10:23:31 pmBoard: M.U.G.E.N Discussion
Posted by Bannana
in SFIV_Historic Distillery 1.0/1.1 (Started by Kamui_De_Los_Vientos March 30, 2021, 07:55:39 pmBoard: Your Releases, 1.0+
Posted by Bannana
in A couple questions (Started by SPzero65 March 22, 2021, 10:08:08 pmBoard: M.U.G.E.N Development Help
! before a trigger always means that the trigger is to be activated if it's not true, that is, returns 0. It's used like a boolean, but instead of working as either 1 or 0, it's any integer, positive or negative, or 0.
!movecontact is equivalent to movecontact = 0
movecontact is equivalent to movecontact = 1
!var(30) is equivalent to var(30) = 0
var(30) is equivalent to var(30)=1 AND var(30) = -1
For the looping attack, use multiple hitdefs. Generally you can use one with trigger1 = animelem = x and trigger2 = animelem = y, but sometimes triggering one hitdef multiple times can get buggy. It also gives you more control over each hit in the sequence as opposed to having to use the same values each time.
Posted by Bannana
in Gato+ (Garou JET) 100% (Started by Bannana January 06, 2021, 01:14:27 amBoard: Your Releases, 1.0+
Spoiler: 3/15/21 -ver- TEXT && HUD (click to see content)
Posted by Bannana
in Amnaelio released Chae-Lim (Started by Yagoshi300 March 05, 2021, 12:25:03 amBoard: Found Releases 1.0+
I have no comments on the YouTube aspect.
For me that major issue here is the question of a Patreon: for spriting or for characters? If the former, whatever; if the latter, then it's problematic.
So I agree here with everyone but I'm more interested in this other issue of whether or not he is monetizing the work of another creator in the first place, because here's where the old open source debate reappears. Though it's Ahuron, Ikaruga appeared in the thread so he should be discussed in general as an example: he has a very strict use policy (http://ikrgmugen.web.fc2.com/policy.txt ); however, his work rests on fanwork that uses material without explicit permission of SNK, SO whose wishes do we respect? Does Ikaruga have a say in the matter at all, or may his work be sprite swapped, with or without credit, because he has no base to make any policy for the use of his work?
Despite the questions of the ramifications of ripping assets from a game and telling others not to use/modify your work, this creator is at fault for not respecting Ikaruga's wishes. If this were Mouser or Tora, a creator who is no longer active, it doesn't matter, but Ikaruga IS active.
Posted by Bannana
in Garou: Mark of the Wolves AutoHitdef (Started by Bannana March 08, 2021, 02:17:25 amBoard: Code Library
Part III - PROPERLY FORMATTING THE HITDEF
Having defined all our values, we now need to get the hitdef to recall them. This will be the easiest part and will mostly come down to copy-pasting certain sections into the hitdef.
So here's the hitdef from before, but I've bolded the areas that you can automate and italicized those you can't:
type = HitDef
trigger1 = animelemtime(helper(222222),var(0))=0
attr = S,NA ;SCA,NA,SA,HA,NP,SP,HP,NT,ST,HT
hitflag = MAF ;HLAFD+-
guardflag = M ;HLA
animtype = medium ;Light, Medium, Hard, Back, Up, DiagUp
priority = 3, Hit
damage = floor((helper(222222),var(1))*fvar(30)),floor((helper(222222),var(7))*fvar(30))
pausetime = (helper(222222),var(2)),(helper(222222),var(3))
sparkno = -1
guard.sparkno = -1
hitsound = S0, (helper(222222),var(15))+random%2
guardsound = S1, 0
ground.type = high ;Low, Trip, None
ground.slidetime = (helper(222222),var(4))
guard.slidetime = (helper(222222),var(4))
ground.hittime = (helper(222222),var(5))
guard.hittime = (helper(222222),var(5))
guard.ctrltime = (helper(222222),var(5))
air.hittime = (helper(222222),var(5))
ground.velocity = (-2.29473946*fvar(9))-fvar(11),0
air.velocity = -2.204769373,-6.6174449*fvar(10)
airguard.velocity = -2.204769373*fvar(9),-6.6174449*fvar(10)
getpower = floor((helper(222222),fvar(1))),floor((helper(222222),fvar(1))-(helper(222222),fvar(3)))
givepower = floor((helper(222222),fvar(1))),floor((helper(222222),fvar(1))-(helper(222222),fvar(3)))
essentially, this hitdef is complete, all you have to do is follow the variables defined in the system.hitdef. Certain things such as the attributes that don't use ints or floats have to be manually changed, and as you can see I did not automate any velocities because those are highly specific to most moves.
For example, take note of how Gato's close D move works. Not only is it a two hit move, but one with drastically different attributes and velocities between hitdefs.
Code:
[State HitDef]
type = HitDef
trigger1 = animelemtime(helper(222222),var(0))>=0
attr = S,NA ;SCA,NA,SA,HA,NP,SP,HP,NT,ST,HT
hitflag = MAF ;HLAFD+-
guardflag = M ;HLA
animtype = hard ;Light, Medium, Hard, Back, Up, DiagUp
priority = 4, Hit
damage = floor((helper(222222),var(1))*fvar(30)),floor((helper(222222),var(7))*fvar(30))
pausetime = (helper(222222),var(2)),(helper(222222),var(3))
sparkno = -1
guard.sparkno = -1
hitsound = S0, (helper(222222),var(15))+random%2
guardsound = S1, 1
ground.type = low ;Low, Trip, None
ground.slidetime = (helper(222222),var(4))
guard.slidetime = (helper(222222),var(4))
ground.hittime = (helper(222222),var(5))
guard.hittime = (helper(222222),var(5))
guard.ctrltime = (helper(222222),var(5))
air.hittime = (helper(222222),var(5))
ground.velocity = cond(animelemtime(helper(222222),var(0))=0,(-.5),(-2.29473946*fvar(9)-fvar(11))),0
air.velocity = -2.204769373,-6.6174449*fvar(10)
airguard.velocity = -2.204769373*fvar(9),-6.6174449*fvar(10)
getpower = floor((helper(222222),fvar(1))),floor((helper(222222),fvar(1))-(helper(222222),fvar(3)))
givepower = floor((helper(222222),fvar(1))),floor((helper(222222),fvar(1))-(helper(222222),fvar(3)))
[State HitDef]
type = HitDef
trigger1 = animelemtime(helper(222222),var(50))>=0
attr = S,NA ;SCA,NA,SA,HA,NP,SP,HP,NT,ST,HT
hitflag = MAF ;HLAFD+-
guardflag = M ;HLA
animtype = hard ;Light, Medium, Hard, Back, Up, DiagUp
priority = 4, Hit
damage = floor((helper(222222),var(1))*fvar(30)),floor((helper(222222),var(7))*fvar(30))
pausetime = (helper(222222),var(2)),(helper(222222),var(3))
sparkno = -1
guard.sparkno = -1
hitsound = S0, (helper(222222),var(15))+random%2
guardsound = S1, 1
ground.type = high ;Low, Trip, None
ground.slidetime = (helper(222222),var(4))
guard.slidetime = (helper(222222),var(4))
ground.hittime = (helper(222222),var(5))
guard.hittime = (helper(222222),var(5))
guard.ctrltime = (helper(222222),var(5))
air.hittime = (helper(222222),var(5))
ground.velocity = cond(animelemtime(helper(222222),var(0))=0,(-.5),(-2.29473946*fvar(9)-fvar(11))),0
air.velocity = -2.204769373,-6.6174449*fvar(10)
airguard.velocity = -2.204769373*fvar(9),-6.6174449*fvar(10)
getpower = floor((helper(222222),fvar(1))),floor((helper(222222),fvar(1))-(helper(222222),fvar(3)))
givepower = floor((helper(222222),fvar(1))),floor((helper(222222),fvar(1))-(helper(222222),fvar(3)))
So, with a little patience, and a tiny bit of work, you'll have consistent, easily editable hitdefs according to a Garou standard. And, realistically, with a little work on the backend you could modify this for any other kind of game!
If you have any questions, don't hesitate to ask!
Posted by Bannana
in Garou: Mark of the Wolves AutoHitdef (Started by Bannana March 08, 2021, 02:17:25 amBoard: Code Library
Part II - EXPLORING THE SYSTEM.HITDEF
Download the system.hitdef file and open it up in notepad/fighter factory/whatever. Go to line 70, which shows an example of the main type of string for normals
Code:
trigger1 = root,stateno = 200 && root,animelemtime(1)=0
trigger1 = var(0):=4 && var(1):=4 && var(7):=0 && var(2):=8 && fvar(2):=1 && fvar(4):=1 && var(10):=46 && var(11):=-69 && var(15)=0
If you've been following so far, or even already looked through the file, each of these variable assignments represents a frontend value. They're explained in the previous part, but I will explain all of them directly here
var(0) = animelem, this is the active frame of your animation (the one with the red clsn)
var(1) = damage, this is either your raw damage, to be corrected later, or the fully corrected version, whatever method you prefer
var(7) = guard damage, follows the same methodology as damage
var(2) = p1 pausetime, this is the only hittime value you need to edit, the rest is done automatically through the backend
fvar(2) = severity modifier on hit
fvar(4) = severity modifier on block
var(10) = spark pos x
var(11) = spark pos y
var(15) = hitsound
What you might have noticed is that I took all of the hitdef values that can be assigned to a variable (i.e. intergers and floats) in MUGEN and had them assigned here. This means that within about 200 lines or so you can assign all normals without having to go through your giant CNS files, saving a great deal of time!
HOWEVER, for a two hit move there is a problem! There are some issues I came up with attempting to rewrite var(0) midway through the state and recalling it as trigger2, so, since the range of 50-59 was free I decided to allocate multihits up to 10 with those.
Take note of this on line 153:
Code:
trigger1 = root,stateno = 215 && root,animelemtime(5)=0 ; *2-pt
trigger1 = var(50):=6 && var(1):=6 && var(7):=0 && var(2):=8 && fvar(2):=1 && fvar(4):=1 && var(10):=40 && var(11):=-86 && var(15)=0
Next, specials, because they give power on whiff, follow a similar pattern, but we remove the two severity modifier fvars.
Go to line 166 (and line 198 for the two hit moves):
Code:
trigger1 = root,stateno = 1000 && root,animelemtime(1)=0
trigger1 = var(0):=8 && var(1):=10 && var(7):=2 && var(2):=12 && var(10):=60 && var(11):=-63 && var(15)=12
severity for these moves is applied for each move specifically because the power gain values are different for each.
On line 207 this set of assignments shows how it works:
Code:
; These cover specials that lie outside of standard hitdef qualities
[State severity determination]
type = Null
trigger1 = root,movetype != A
trigger1 = fvar(2):=0
; throw
trigger2 = (root,stateno = 800)
trigger2 = fvar(2):=3
; light specials whiff
trigger3 = root,time<=4
trigger3 = (root,stateno = 1000) || (root,stateno = 1100) || (root,stateno = 1200)
trigger3 = fvar(2):=6
; light specials hit
trigger4 = root,time>4
trigger4 = (root,stateno = 1000) || (root,stateno = 1100) || (root,stateno = 1200)
trigger4 = fvar(2):=2
; heavy specials whiff
trigger5 = root,time<=4
trigger5 = (root,stateno = 1050) || (root,stateno = 1100) || (root,stateno = 1250)
trigger5 = fvar(2):=7
; heavy specials hit
trigger6 = root,time>4
trigger6 = (root,stateno = 1050) || (root,stateno = 1100) || (root,stateno = 1250)
trigger6 = fvar(2):=3
And for the guard values, go to line 259:
Code:
; Guard constant
[State guard determination]
type = Null
trigger1 = root,movetype != A
trigger1 = fvar(4):=0
; light specials
trigger2 = (root,stateno = 1000) || (root,stateno = 1100) || (root,stateno = 1200)
trigger2 = fvar(4):=1
; heavy specials
trigger3 = (root,stateno = 1050) || (root,stateno = 1100) || (root,stateno = 1250)
trigger3 = fvar(4):=2
Much of this should be incredibly straightforward, especially with normals, so what should be difficult is dealing with specific situations with special moves, and sometimes that means you might not be able to use the autohitdef and would be better just making a manual hitdef.
That being said, in Part III I'll explain how this all comes together into the generic hitdef.
Posted by Bannana
in Garou: Mark of the Wolves AutoHitdef (Started by Bannana March 08, 2021, 02:17:25 amBoard: Code Library
Part I - INTRODUCTION AND METHODOLOGY
Part II - EXPLORING THE SYSTEM.HITDEF
Part III - PROPERLY FORMATTING THE HITDEF
Part I - INTRODUCTION AND METHODOLOGY
A majority (if not all, but I'm not going to make that argument) of games have universal pausetimes, hittimes, slidetimes, etc. for all normals and most specials (barring weird things like fireballs and supers). Garou's is incredibly simple, but is highly important for correct combo timings because all frame advantages, especially breaks, align with the pause/hit/slidetime. I dunno if anyone is looking to make more MotW characters, or even do stylistic edits in the manner of Kn (totally worth it), but this would make both of those much faster.
I personally hate the hitdef. It's inefficient because, in an efficient program, all of the valuable information concerning damage, scaling, hittime, pausetime, etc would be backend values that are called upon by the hitdef; therefore, a lot of time is wasted trudging through the cns to edit states, and I thought it would be better, and more efficient, to assign all of these functions to a file that only consists of less than 500 lines that need to be edited; moreover, because no hitdef is ever active on the first frame, so we don't have to deal with theoretical 1 tick delay, it makes perfect sense to just assign these to a helper in general.
So, in Gato+ I decided to diminish the actual amount of physical editing you have to do in any file but the AutoHitdef file,
Spoiler: leading to this (click to see content)
As far as I'm concerned, an attack state should consist of two sections:
Spoiler: Mandatory front end, e.g. sound clips on startup that are specific to each move (click to see content)
Spoiler: Absolute backened that should not have to be touched aside from particular specials and supers (click to see content)
N.B. I use explods here, so if you were using hitsparks in the hitdef then you would just put "(helper(222222),var(10)),(helper(222222),var(11))" there for the x and y pos.So, how does this work?
essentially, in a backend file we will make a list of all values that, because they never change, should be determined ahead of time, and then define whether those values are frontend or backend, the difference being that the backend are always calculations based on frontend values.
Spoiler: After doing this, I determined my list should be as so (click to see content)
And to explain the idea of how the frontend and backend works in practice, take my top two: animelem and idle. In Garou I determined that the average time an idle would occur would generally be 2-3 animelems after the active frame, so my backend calculation for var(6) is as follows
Code:
; Idle is ALWAYS set two frames after an activeThis sort of backend caluclation makes hittime in Garou easy to work with because all hittimes in Garou are based upon the root p1 pausetime
[State idle set]
type = VarSet
trigger1 = var(0)
v = 6 ;fv = 10
value = var(0)+2
persistent=1
ignorehitpause=1
Code:
; pause/hit/slide time notesThus, a light punch pausetime of 8 will return p2 pausetime of 7, slidetime of 12, and hittime of 14, all of which are accurate to source.
; THESE TIMES ARE ABSOLUTELY UNIVERSAL, NOTHING HAS TO BE CHANGED ASIDE FROM SPECIALS
[State p2 pause]
type = VarSet
trigger1 = var(2)
v = 3 ;fv = 10
value = var(2)-1
persistent=1
ignorehitpause=1
[State slide time]
type = VarSet
trigger1 = var(2)
v = 4 ;fv = 10
value = var(2)+(var(2)/2)
persistent=1
ignorehitpause=1
[State hittime time]
type = VarSet
trigger1 = var(4)
v = 5 ;fv = 10
value = var(4)+2
persistent=1
ignorehitpause=1
A note on severity and power gain
Prior to revealing the code we need to go over how power works in Garou.
In Garou there is a root power value, 66537 (or, when corrected, 15), that I found is compounded by degrees of severity, so that each move will be allocated a certain level of severity based on movetype, strength, whiffing, hitting, etc.
You can see in my musings above that I thought quite a bit about how the patterns point to a possible methodology for assigning power to moves, and what I decided to do was take this raw value, 66537, set it to fvar(0), and apply two sets of calculations to it:
Code:
; Calculation of raw power value
[State raw calculation]
type = VarSet
trigger1 = 1
fv = 1 ;fv = 10
value = floor(((fvar(0) - 1)/4194.305)*fvar(2))
ignorehitpause=1
persistent=1
; Calculation of guard power value
[State guard calculation]
type = VarSet
trigger1 = 1
fv = 3 ;fv = 10
value = floor(((fvar(0) - 1)/4194.305)*fvar(4))
ignorehitpause=1
persistent=1
The severity modifiers here are fvar(2) and fvar(4), which, like p1 pausetime earlier, are the front end that we will edit manually, and the resulting values will be plugged into the hitdef automatically, giving correct power gain values.
With that, let's move on to Part II, where I'll explain how the auto-hitdef file works.
Posted by Bannana
in Gato+ (Garou JET) 100% (Started by Bannana January 06, 2021, 01:14:27 amBoard: Your Releases, 1.0+
Nothing actually major here except for adding in my chain module for Vans' Tiny Buffering and finishing up my auto-hitdef backend, but now I consider this 100% done in its current form. Obviously there are some graphical things that aren't done but shwa is pretty busy so no ETA on those.
Spoiler: the changelog (click to see content)
Posted by Bannana
in Tiny Chaining for Tiny Buffering (Started by Bannana March 03, 2021, 12:18:07 pmBoard: Code Library
There are two types of chain combos:
buffered, or kara, chains, as found in in Real Bout
YES THOSE ARE SCANLINES, THEY LOOK GOOD WITH THEM OK i have old man eyes
In SNK games that aren't KOF or Mark of the Wolves, these chains are an important part of the game because they expand the standard SNK system of
normal xx special xx super
into
a > b > c xx special xx super
and this simple normal chaining develops in complexity to the point where you're throwing out 5 hits before you even cancel into the special:
Rick Strowd chain out of standing A (courtesy of Dream Cancel)
Karasu chain out of LP (courtesy of SRK)
Karasu chain out of LP (courtesy of SRK)
N.B. If you're a french bread player,
you might see some major antecedents to the melty, and especially UNI, style of what I call a "progressive chain,"
a chaining of options up from a > c together before canceling (obviously not counting the perfection that is reverse beat).
you might see some major antecedents to the melty, and especially UNI, style of what I call a "progressive chain,"
a chaining of options up from a > c together before canceling (obviously not counting the perfection that is reverse beat).
So, enough about chains and to the topic at hand, this is a little module to add to Vans' Tiny Buffering to make chains worry free!
Before this, authors like Mouser would use a -2 bitwise variable:
Code:
[State 200, VarSet]
type = VarSet
trigger1 = Time = 1
var(6) = 0
[State -3, VarSet]
type = VarSet
trigger1 = HitPauseTime
trigger1 = !(var(6) & 112)
var(6) = (command = "holdfwd") | (command = "holdback") * 2 | (command = "holddown") * 4 | (command = "holdup") * 8
ignorehitpause = 1
[State -3, VarSet]
type = VarSet
trigger1 = HitPauseTime
trigger1 = !(var(6) & 112)
var(6) = var(6) | (command = "a") * 16 | (command = "b") * 32 | (command = "c") * 64
ignorehitpause = 1
In this situation, the variable simply identifies that a certain combination of inputs happen, and that is cached and recalled in the -1:
Code:
[State -1]
type = ChangeState
value = 320
triggerall = roundstate = 2
triggerall = (command = "b" && command != "holddown") || ((var(6) & 32) && !(var(6) & 4))
trigger1 = stateno = 200 && AnimElem = 4,> 0 && AnimElem = 7,< 0
trigger2 = stateno = 205 && AnimElem = 3,> 0 && AnimElem = 6,< 0
trigger3 = stateno = 210 && AnimElem = 4,> 0 && AnimElem = 6,< 0
trigger4 = stateno = 215 && AnimElem = 2,> 0 && AnimElem = 4,< 0
HOWEVER this is sort of a poor man's buffer. Mouser, while a great coder, is not buffering the inputs as a game would, but instead is just trying to catalogue possible combinations to appease mugen's input parser. The reason why he did this was because he had no method to work with inputs directly, which is why Vans initially developed Tiny Buffering. Because Tiny Buffering is heavily KOF based, and thus is highly compatible with SNK games, it can be used to buffer chains effectively, efficiently, and effortlessly.
THIS CODE USES THE MISC VAR(50)-VAR(59) VALUES THAT VANS LEFT OPEN, PLEASE NOTE THAT ANY VAR ISSUES DUE TO OVERRIDING ARE YOURS AND NOT MINE! REMEMBER THAT ALL CODE I OFFER MUST BE MODIFIED TO REFLECT THE COMMAND LAYOUTS OF YOUR CHARACTER!
The code, verbatim, is as so:
Code:
;------------------- CHAINING ---------------------------------------------------;
; BY BANNANA --- ye, i'm no longer a code borrower, but code lender! :^)
;var(0) is set to x, subtracts over time
;if var(1) is set *while* var(0) > 0, var(50) is set to x
;my rule of thumb - light attack = 10, heavy attack = 20
;if !var(50) during a state, then pressing button sets (50) to 3, because the hitpause puses the count and doesn't require a larger active number.
;thus, assuming A=x and B=y
[State 10371, B chain Dec]
type = VarAdd
triggerall = root, HitPauseTime = 0
trigger1 = var(50)
var(50) = -1
[State 10371, B chain Init]
type = VarSet
trigger1 = command = "y"
var(50) = cond(var(0),10,3)
And in the cmd you will write a trigger as so:
Code:
trigger1 = (helper(10371), var(50) && (helper(10371),command != "holddown"))
trigger1 = stateno = [stateno] && animelemtime(x)>0 && animelemtime(x)<0
To explain this, it's best to explain why Vans' buffering works:
1) x is pressed, so a var(x) is set to x
2) at any point at which there is no hitpause, x counts down by 1 per tick
3) if a hitpause is in effect, that count will PAUSE
4) if x = 0, any buffer is null
Knowing this, my chain method piggybacks on this by using this logic:
1) x is pressed, so a var(x) is set to x
2) IF BUFFERED
>>>>>>>> y is pressed while var(x) > 0, then we can confirm that the move was meant to be buffered and var(y) is set to y
3) IF NOT BUFFERED
>>>>>>>> y is pressed while the hitpause of x is occuring, thus var(x) > 0; therefore, we can confirm that the move is meant to be buffered and var(y) is set to (y)
It's quite simple, yet I think much better than Mouser's, not only because it frees up a variable, but because it allows for inputs not to be categorized, but actually buffered, with the required timing defined and measured.
if you have any questions, or need clarification (because I'm no teacher :p), feel free to reply.
Re: 【 JtheSaltyy's WIP Thread 】: Future Character Poll
February 27, 2021, 11:09:03 am View in topic context
Posted by Bannana
in Saltyy's WIPs: CvS2 Strider (Started by jay_ts September 13, 2020, 08:58:01 pmBoard: Projects
Re: Character of the Month: January 2021 Voting
February 26, 2021, 10:44:48 pm View in topic context
Posted by Bannana
in Character of the Month: January 2021 Voting (Started by 【ＭＦＧ】gui0007 February 25, 2021, 03:26:01 pmBoard: Contributions of the Month
Athena & Miles
Re: Code-heavy character mirror matches cause multiple glitches.
February 25, 2021, 05:20:51 am View in topic context
Posted by Bannana
in Code-heavy character mirror matches cause multiple glitches. (Started by Kolossoni February 25, 2021, 04:38:32 amBoard: M.U.G.E.N Development Help
Re: Character of the Month: January 2021 Nominations
February 23, 2021, 12:16:56 am View in topic context
Posted by Bannana
in Character of the Month: January 2021 Nominations (Started by 【ＭＦＧ】gui0007 February 09, 2021, 04:09:29 pmBoard: Contributions of the Month
koop's already in so
The Mandalorian by CpnCrossfader - 2
Re: A few questions about what defines a compilation or fullgame
February 22, 2021, 12:19:05 am View in topic context
Posted by Bannana
in A few questions about what defines a compilation or fullgame (Started by NecusX February 20, 2021, 06:01:50 pmBoard: M.U.G.E.N Discussion
https://streamable.com/2006h8
The ways in which different creators study games, whether or not they guess or use raw data, as well as how they choose to code that data, changes the outcome.
Compound this distinction with 20 characters all by different authors and you'll definitely find some discrepancies.