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: 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.
    

Re: 【 JtheSaltyy's WIP Thread 】: Future Character Poll

 February 27, 2021, 11:09:03 AM View in topic context
 Posted by Bannana  in 【 JtheSaltyy's WIP Thread 】: Rubber Soul (Started by JtheSaltyy 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 【MFG】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 【MFG】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.
    

Re: Random Topic V10

 February 21, 2021, 03:58:39 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

To be honest, I'm no big brain trader, I jumped in on eth very early just based on intuition, right around the time in 2016/17 that China banned it as currency and caused it to drop like a brick. I had lost a bunch on litecoin (lol), and just dumped it in there hoping it would recover some losses; however, eth is not a holding coin really, so don't look into grabbing it and expecting it to end up as high a bitcoin. I do believe it will keep growing and any fraction of a single coin in eth will be worth holding, because it's being used like GAS for trading in altcoins. So if you want to trade alt, go for eth, and if you want a tiny bit of returns, go eth, because as long as it's being used as a trading currency, it will raise in value (I think it will plateau more than the bubble will pop) because the more people are going to buy into it for that purpose.

XRP is very nice

I have some Chainlink and Algo too, which are alright

I know people right now who are big into pancakeswap and the new trend of farming coins. There's a lot of new complicated ways of inflating and deflating values. I think it's interesting, but I don't want to use Binance because Binance US sucks major ass compared to the worldwide version and I'm too lazy to use a VPN :p

I'm mostly a holder anyway. I don't really like gambling because I'm just trying to store my money safely, so I just see coins as a way of diversifying my portfolio beyond standard investments, so I stick with the major stuff that standard wallets like coinbase trade.


Oh and a sidenote, find someone you can just trust to talk about the coins casually, not someone trying to sell you into buying them. I have a few friends who are big into coins so I like to bounce off ideas and opinions on them and see what I should do best. Most of trading is just trying to figure out what's going to happen based on market trends and worldwide stuff, and coins are generally the same. The differences might just be things like: is it meant to be a currency, is it tied to another 1:1, is it meant for trading other coins, do people think the tech behind it is good (lol), etc.
    

Re: Random Topic V10

 February 20, 2021, 11:58:23 PM 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

Investment world going gaga over Dogecoin with Elon Musk fully supporting it on Twitter.

How I wished someone introduced me to Bitcoin. I knew about it but sadly I didn't invest in it when it was less than 10 dollars that time. Long story short I had a friend whom I thought was an investment guru but turns out he was just an impulsive unprofessional gambler. Introduced me to Bitconnect which he invested and he lost all his money in just 1 month.

Planning on purchasing at least 1000 Dogecoin with the next 6 months. Already set up an account on Binance the only problem is my bank won't let me purchase.

Also follow the golden rule of investment. "Invest only money you can afford to lose."


[youtube]https://www.youtube.com/watch?v=if0i8U356pg[/youtube]
Don't treat altcoins like anything more than pennystocks.

People buy to dump, glhf.
    

Re: Gato+ (Garou JET) [ver. 90%]

 February 20, 2021, 11:15:52 PM 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+

Lol, I gave him a Terry feint infinite I guess.

I'm not too sure about the timing of the cancels, they might be too lenient because I was putting more time into leisurly testing for bugs.


I'm trying another big update soon that will remove the "grooves" and fold in the EAS heat bar with JET cancels and breaks. I think right now it's a little too disconnected and not cohesive as a total system, and I'm interested in making a global system effect vs character specific.
    

Re: A few questions about what defines a compilation or fullgame

 February 20, 2021, 10:24:34 PM 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

I think everyone might have a different idea, but at the most basic level I would say compilation = without major modification.

Now, what qualifies as a major modification I have no clue. A long time ago in the ancient past of 2007, an edit was not really considered your work, no matter what you did, and it would just be a compilation. I think people's views have changed and there are quite a few legitimate creators whose work consists of major edits, so perhaps they won't consider it a compilation.
    

Re: How would I go about assigning sounds to walking and running anims for running?

 February 14, 2021, 11:11:48 PM View in topic context

When you're working with the basic states like standing, walking, running, jumping, you're either using the core common1.cns found in the data folder of your mugen, or you're overriding it in your character's cns (what you've done by adding in your own state 20).

here's what's in the common for state 20
Code:
; Walk
[Statedef 20]
type    = S
physics = S
sprpriority = 0

[State 20, 1]
type = VelSet
trigger1 = command = "holdfwd"
x = const(velocity.walk.fwd.x)

[State 20, 2]
type = VelSet
trigger1 = command = "holdback"
x = const(velocity.walk.back.x)

[State 20, 3]
type = ChangeAnim
triggerall = vel x > 0
trigger1 = Anim != 20 && Anim != 5
trigger2 = Anim = 5 && AnimTime = 0
value = 20

[State 20, 4]
type = ChangeAnim
triggerall = vel x < 0
trigger1 = Anim != 21 && Anim != 5
trigger2 = Anim = 5 && AnimTime = 0
value = 21

The common will generally use those constants that you've defined in the character's main cns, so in this case, "walk.fwd" and "walk.back".

When you have some time, open up the common and check out what they do for all the states, it's helpful to see how they code everything so you know how to interact with it, or see if you need to override it for something specific.  At some point what some creators end up doing is copying that common and placing it into the character folder so they can edit it to have a common that's custom for that character.
    

Re: GanryuIsland2014 (Haohmaru's Stage) Shiyo's Style

 February 14, 2021, 08:44:21 AM View in topic context
 Posted by Bannana  in GanryuIsland2014 (Haohmaru's Stage) Shiyo's Style (Started by Kamui_Kanjai February 12, 2021, 02:33:41 AM
 Board: Edits & Addons 1.0+

Can't wait for the new version, the rippling reflection looks amazing!