YesNoOk

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.

***
Bannana is Offline
Contact Bannana:

Bannana

Contributor

Messages by Bannana

    

Re: Gato- [Public beta]

 May 07, 2021, 11:28:31 AM View in topic context
 Posted by Bannana  in Gato- [Public beta] (Started by Bannana May 05, 2021, 08:49:12 AM
 Board: Your Releases, 1.0+

1. For sure normals have been a mixed bag, I'm still not sure about them myself. I keep going back and forth on chains like Real Bout, but I think if I double down on long pausetimes I should just bite the bullet and put them in.
2. hmm, this is a hitbox issue. I'm not sure what to say, my gravity caused the first issue, so removing it during the move just leaves the y velocities that were from the original, where it works. I'll look into this, but it it works in the corner lol!


3. It wasn't meant to work much like the source Fuu-ga, but I wasn't sure if it would overcomplicate it to allow you free use of all air moves. I agree with you though.
4. Hmm, this is something to think more about.
5. Yeah, a line of code was left out :p

Quick update to fix that EX issues and the fuu-ga followups now include all possible air moves
    

Re: Gato- [Public beta]

 May 07, 2021, 07:31:52 AM View in topic context
 Posted by Bannana  in Gato- [Public beta] (Started by Bannana May 05, 2021, 08:49:12 AM
 Board: Your Releases, 1.0+

Updates today covering everything brought up so far as well as extra tweaks.
Spoiler: 5/6/21 (thanks Rowen!) (click to see content)
    

Re: Gato- [Public beta]

 May 05, 2021, 09:31:52 PM View in topic context
 Posted by Bannana  in Gato- [Public beta] (Started by Bannana May 05, 2021, 08:49:12 AM
 Board: Your Releases, 1.0+

1. Hit pause is 10,5 outside of escalation and 5,5 during. I see the dilemma though, I was thinking of tweaking my formula too. As far envshake, I understand what you mean, I haven't totally gone though extra fluff like that so it's good to keep in mind.

2. Hmm, it's the exact same states, animations, and hitboxes as my other Gato. I was having trouble with this on certain characters but it just put it down to their hitboxes. I did some velocity tweaks prior to uploading, so perhaps that might be a side effect.

3-4. Yeah, just spitballing here for the moment lol

5. Oh this move was broken like I expected it would be! I should check my cancel var, I might not have reset it in the state. Are you using the j.2A command move prior to canceling? It's probably because I left a ctrl=1 sitting around somewhere.

6. This is a sentiment I completely understand. It overriding the move was one of two options, the other being BC. I do think you might be right here.


I appreciate the feedback! My normal testers are far too busy at the moment so things like these I would normally know about prior to release haven't been cleaned up.
    

Gato- [Public beta]

 May 05, 2021, 08:49:12 AM View in topic context
 Posted by Bannana  in Gato- [Public beta] (Started by Bannana May 05, 2021, 08:49:12 AM
 Board: Your Releases, 1.0+


Spoiler: extra images (click to see content)

YEAH It's Gato AGAIN, I know; but, new system, new look, new moves. Total beta, so any feedback would be welcome. Tweaks to damage and heat scaling won't really be undertaken until I have a few more characters done. Probably more FX on the way, I dunno.

Unlike the last Gato, which is much more like MotW+, this is a totally "new" thing based somewhat upon mechanics from Wild Ambition+other Real Bout stuff. For more than a cursory explanation of the system info, check out the project thread, which I'll be updating as time goes on.

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)
AB - Avoid
5AB - Anti-high attack anti-high attack with a low profile hitbox
   (Can be used in hitstun during max Heat)
6/4AB - Passing move each character will have a unique passing move that has invul between startup and cool down.
   (All passing moves can be canceled out of into any move on landing)
AC - Feint
ABC - Escalation mode changes the properties of special moves, and how hittimes are calculated

Break A special with two levels of power mapped to A and B, can be canceled early by breaking with AB
Rai-ga - DP A/B

Escalation Two different specials mapped to A and B respectively, upon entering escalation mode the properties of these change.
Air rekka - j.QCF A > D A
⮩ E. faster speed for D A rekka
Air throw - j.QCB B
⮩ E. Bounce on ground, faster land recovery animation

Heat A special mapped to C, when heat is full this move becomes an alternate overdrive version of itself.
Fuu-gaaa - QCB C (only hits downed opponent, launches)
EX - QCB BC
Free jump outside of heat, can be canceled with A/B/C

Heat fills during neutral--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 no matter what, allows for the overdrive form of the heat move, and the use of avoid during hitstun. At max heat escalation mode can be activated.

Upon successful Just Defend, a cardinal 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.

He has a cancel chart but I haven't written it out yet, so just know that 5B and j.2A can be canceled out of. Avoids are always able to be canceled on hit. And, yeah, his command move is j.2A, I didn't write it in the movelist for whatever reason.

Not on the site, get it here
    

Re: Having multiple CNS files [vs] Having one

 May 05, 2021, 05:01:58 AM View in topic context
 Posted by Bannana  in Having multiple CNS files [vs] Having one (Started by Kolossoni May 05, 2021, 03:27:36 AM
 Board: M.U.G.E.N Discussion

I dislike scrolling through and editing long files, so if a file is going to be edited frequently and isn't simply backend I prefer to keep it around 1000 lines or so, and I generally split up my normals, specials, supers, system, negative states, and extra files.

It makes my workflow much faster, otherwise I'd have to use a table of contents at the top of the file for ease of access.
    

Re: Untitled Fatal Fury project/system/fullgame

 May 01, 2021, 07:11:48 AM View in topic context
 Posted by Bannana  in Untitled Fatal Fury project/system/fullgame (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
    

Re: Untitled Fatal Fury project/system/fullgame

 April 30, 2021, 10:02:29 PM View in topic context
 Posted by Bannana  in Untitled Fatal Fury project/system/fullgame (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.
    

Untitled Fatal Fury project/system/fullgame

 April 30, 2021, 01:36:50 AM View in topic context
 Posted by Bannana  in Untitled Fatal Fury project/system/fullgame (Started by Bannana April 30, 2021, 01:36:50 AM
 Board: Projects

As I wrote when I released Gato, he was put together as a testbed for a potential fullgame/system that developed out of my work with Wild Ambition. Since then I've been working hard on developing that, and I've made enough progress to outline my what I'm interested in doing with it.

I'll have more examples and updates in the coming days as I start to finalize some stuff with Gato, but for now I want to leave the basic ideas. This game is heavily influenced by parts of Wild Ambition, more so than other fatal fury games, so keep that in mind as I go through this.

Two levels of proration
Flat health (the less health, the less damage taken)
Combo based

Basics
A - Punch
B - Kick
C - Strong
A+B - Avoid

Avoid moves

5AB - anti-high attack with a low profile hitbox; however, a significant difference between this and previous games is that it does not put the opponent into a normal hitstate, but a stagger instead. Being hit in this state ALSO puts you into stagger.

6/4AB - passing move: each character will have a unique passing move that has invul between startup and cool down. Being hit puts you into stagger.

Specials
There are three types of specials, grouped by what modifies them:

Break moves
A special with two levels of power mapped to A and B, can be canceled early by breaking with A+B

Escalation moves
Two different specials mapped to A and B respectively, upon entering escalation mode the properties of these change.

Heat move
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 acts like a tension meter, filling it up during neutral drops proration modifiers, giving full damage no matter what, allows for the overdrive form of the heat move, and the use of avoid during hitstun. At max heat escalation mode can be activated.

Escalation mode

Taken from Blue Mary's move of the same name, Escalation mode changes the properties of special moves, and how hittimes are calculated, allowing for true combos.

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

Because this project is essentially a poor man's version of what I would like to make an original game out of, but lack the time and skill to make original characters, all the characters will play as highly arranged, almost anime-ish versions of themselves. What I mean by anime-ish is that each character will have a highly unique kit (derived from available attacks) that, while stopping short of being gimmicky, will make them play closer to a game like Guilty Gear or Melty Blood than Fatal Fury or Real Bout.

Currently I'm working on Gato, using the three button Gato+ build as my point of departure, and I'm about 50% done, a lot of what I need to do is tweak velocities, timings

I've already teased some Gato tech, but all of that is still WIP and changes can happen at any time.

The main idea is to focus on characters who haven't appeared in any kof games (with the exception of Gato but he's just grandfathered in), making a sort of side or extra story sort of game.
Spoiler: Gato (click to see content)
Spoiler: Sokaku (click to see content)
Spoiler: Franco Bash (click to see content)
Spoiler: Rick Strowd (click to see content)
Spoiler: Bob (click to see content)
Spoiler: Kevin Rian (click to see content)
Spoiler: Grant (click to see content)

The full package

Right now system and characters are the most important part, but with those done I'll being working with ikemen.
I'm hoping to eventually put together the final thing with nearly everything except for the characters new. This includes music, stages, fx, sfx etc. The core idea of my work will be Naomi/dreamcast like in implementation. If you've seen the effects I made for Gato you get a better idea of what I mean.

Classic stages like Pioneer Plaza and Delta Park will reappear for sure, though in what form I can't say at the moment.
    

Re: Random Topic V10

 April 29, 2021, 10:51:00 AM View in topic context
 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
    

Re: Random Topic V10

 April 29, 2021, 05:38:47 AM View in topic context
 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?
    

Re: The Final Frontier: Bayonetta.

 April 21, 2021, 11:31:43 PM View in topic context
 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
    

Re: SFIV_Historic Distillery 1.0/1.1

 March 30, 2021, 08:23:00 PM View in topic context
 Posted by Bannana  in SFIV_Historic Distillery 1.0/1.1 (Started by Kamui_Kanjai 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!
    

Re: A couple questions

 March 22, 2021, 10:37:09 PM View in topic context
 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.
    

Re: Gato+ (Garou JET) 100%

 March 16, 2021, 02:00:45 AM View in topic context
 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)
    

Re: Amnaelio released Chae-Lim

 March 09, 2021, 11:29:16 PM View in topic context
 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.
    

Re: Garou: Mark of the Wolves AutoHitdef

 March 08, 2021, 02:23:11 AM View in topic context
 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!
    

Re: Garou: Mark of the Wolves AutoHitdef

 March 08, 2021, 02:20:09 AM View in topic context
 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.
    

Garou: Mark of the Wolves AutoHitdef

 March 08, 2021, 02:17:25 AM View in topic context
 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.
    

Re: Gato+ (Garou JET) 100%

 March 04, 2021, 05:52:10 AM View in topic context
 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)
    

Tiny Chaining for Tiny Buffering

 March 03, 2021, 12:18:07 PM View in topic context
 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.