YesNoOk

Recent Posts

    

Re: CVS Mugen Fighting Jam - Sonson and Ruby Heart Joined The Game - 8 March 2021!

 March 08, 2021, 04:03:43 AM View in topic context
#1
avatar  Posted by drewski90  in CVS Mugen Fighting Jam - Sonson and Ruby Heart Joined The Game - 8 March 2021! (Started by yudhiyou April 13, 2017, 03:29:39 PM
 Board: Edits & Addons 1.0+

Update 8 March 2021,

Sonson created by NDSilva, Koopa901, varo_hades, and gui0007 has been joined into game roster.
Ruby Heart created by Buckus and gui0007 has been joined into game roster.

The updates:
- Sonson and Ruby Heart join into the game with adjusted gameplay system.
- Add AI on Ruby Heart.
- Fix Hugo difficult to execute 360 and 720 command input special and super moves.
- Update Hugo super cancel. Only Hammer Frenzy super move can be cancelled from Giant Palm Bomber special move.

Enjoy... :)

and with that the capcom roster is full

now that only leaves the guests, capcom, and snk leftover roster to fill up and then that's gonna be it
    

Explod sprPriority bug

 March 08, 2021, 03:47:32 AM View in topic context
#2
 Posted by Jmorphman  in Explod sprPriority bug (Started by Jmorphman March 08, 2021, 03:47:32 AM
 Board: Tips, Tricks, Tutorials

MUGEN will sometimes incorrectly display Explods with the wrong sprPriority, if several Explods are created all at once or in rapid succession, and if all use the same sprPriority. Emphasis on the "sometimes": this error does not at all happen consistently, but it does occur fairly often if the conditions required for it to happen are repeated over and over.

This can be avoided simply by making sure each Explod is given a different sprPriority; of course, it is also possible that this error might not be worth handling if those having inconsistent layering on those Explods is not super important.

With the basic explanation of the issue out of the way, I think it'd be best to demonstrate with a concrete example: I discovered this issue a few days ago while I was coding B.B. Hood; over in the MFG Discord, 2OS also mentioned running into the exact same issue before. She has a projectile move where she fires a missile at the opponent, and as the missile travels forward, it is constantly spewing clouds of exhaust. This is what it should look like:

Note that the missile has at this point already exploded without hitting the opponent. Anyhow, my implementation of this effect uses hi-res FX, and I have opted to use a two Explods for each distinct exhaust cloud. One Explod goes on top of the other, with the upper one using additive transparency, and the bottom using subtractive transparency. I therefore had two Explod controllers making each respective type of Explod as the projectile moved forward; I also set each controller's sprPriority to 3.

The top layer Explod appeared in the code above the bottom layer one, which meant that each time a new exhaust cloud Explod pair was created, MUGEN would first draw the top layer Explod and then draw the bottom layer one below the first. This produced the desired effect, and I had used the same basic method for much of B.B. Hood's other effects. However, occasionally, this would happen:

This occurs in exactly the same point of the move as the first screenshot, but note the odd glow in the leftmost exhaust clouds. Here's a picture of the two side by side for better clarity:

Both of these screenshots were taken during the same gameplay session; I did not make any changes or otherwise reload the character in any way. Instead, MUGEN is occasionally screwing up the layering of the many Explods it's currently drawing in these screenshots.

The glow effect is a result of two top layer/additive transparency Explods being layered right over one another (because the glow only happens where two distinct exhaust clouds touch/overlap one another). This can be verified by giving all top layer/additive transparency Explods a sprPriority of 3, and the bottom layer/subtractive transparency Explods a sprPriority of 2:

Each cloud displays fine, except when two of them are overlapping. It's a bit difficult to tell that the glow shows up in the rightmost clouds, so here's a version of the same effects but with proper layering.

In those overlapping spots, the glow shows up because the top layers of each respective cloud have a sprPriority of 3, and the subtractive layers drawn beneath both. In other words, there's an additive layer, then another additive layer, then the two subtractive layers. The desired layering when two clouds overlap one another should instead be additive, then subtractive, then another additive, and then another subtractive.

The previous example was, of course, just an experiment, showing what happens when this problem is made to happen to every Explod. Going back to the original example, MUGEN will usually and correctly draw each Explod pair with the proper layering. But it does fuck up sometimes, so you should try and avoid situations like this happening (in my case, I just gave each additive/subtractive Explod pair its own unique sprPriority). Then again, if I wasn't using fancy hi-res effects that required dual layered transparency, this thing wouldn't really matter. But even so, if you're ever making a bunch of Explods all at once, and the layering of those Explods is really important, make sure to take precautions to avoid something like this happening!

    

CVS Mugen Fighting Jam - Sonson and Ruby Heart Joined The Game - 8 March 2021!

 March 08, 2021, 03:23:41 AM View in topic context
#3
 Posted by yudhiyou  in CVS Mugen Fighting Jam - Sonson and Ruby Heart Joined The Game - 8 March 2021! (Started by yudhiyou April 13, 2017, 03:29:39 PM
 Board: Edits & Addons 1.0+

Update 8 March 2021,

Sonson created by NDSilva, Koopa901, varo_hades, and gui0007 has been joined into game roster.
Ruby Heart created by Buckus and gui0007 has been joined into game roster.

The updates:
- Sonson and Ruby Heart join into the game with adjusted gameplay system.
- Add AI on Ruby Heart.
- Fix Hugo difficult to execute 360 and 720 command input special and super moves.
- Update Hugo super cancel. Only Hammer Frenzy super move can be cancelled from Giant Palm Bomber special move.

Enjoy... :)
    

Re: POTS Kotaro custom (Ned trying...)

 March 08, 2021, 03:00:23 AM View in topic context
#4
 Posted by ヒカリ ♡  in POTS Kotaro custom (Ned trying...) (Started by Nedflandeurse March 06, 2021, 02:43:57 PM
 Board: Projects

Nice to see you adventuring yourself like that! Needless to say, the sprites look gorgeous :smitten:
And don't worry about all of that, take your time, coding is not as hard as it looks!
    

Re: Lilly Kane

 March 08, 2021, 02:48:53 AM View in topic context
#5
 Posted by ヒカリ ♡  in Lilly Kane (Started by ashina January 13, 2008, 04:07:26 PM
 Board: Sprite Projects

That's really good! I also saw your other sprites in your deviantart, they are all great. :smitten:
Started watching you on DA. ;D
    

Re: STREET FIGHTER III X

 March 08, 2021, 02:37:33 AM View in topic context
#6
 Posted by Mastertkof  in STREET FIGHTER III X (Started by Mastertkof January 07, 2017, 12:32:10 AM
 Board: Projects

Juri is going to be something more than "ok"
the final resultt, if i do all scripts... will be "EPIC!"
but perhaps... i never finsish it.
anyway.... i want to show you guys

without anykind of edition on this (just a gif done by blender)

    

Re: Marvel Cinematic Universe: THE END (until the next movie comes out)

 March 08, 2021, 02:25:33 AM View in topic context
#7
 Posted by Jmorphman  in Marvel Cinematic Universe: THE END (until the next movie comes out) (Started by Iced July 15, 2012, 03:54:44 AM
 Board: Entertainment

Emma Caulfield indeed was on Buffy, but her character was specifically a former vengeance demon; her basic deal is that she loses her powers and turns human and is forced to learn how to adjust and deal with modern human society and life in general. She was primarily used for comedy purposes; she only once or twice ever appears in a demonic form or is otherwise menacing/antagonistic. But that was a single role from nearly 20 years ago, and she's done other work; it's her most well-known role, of course, but if they cast her because of it, it was for her comedy chops.

The Evan Peters of it all is a way different story, and I agree that it does feel a bit trolling—even if I personally wasn't bothered by it. Ultimately, I feel like it was more of a fun tease than anything malicious, though.

This is 100% deliberately misleading, and that's not the fanbase, it's impossible to not see the connection that turns up to be a lie.
Most of this stuff is not really from Marvel Studios, it's the reporting around them. Like, they announce WandaVision, and news outlets will naturally gravitate towards the closest thing it resembles: House of M, then that gets hyped up by fans, etc. That cycle is just killer, but I can't blame Marvel for it at all.

That said, there's a few things that are legit: the Spider-Man 3 stuff might be one of them. I think the crucial thing here is that they're all (including Tom Holland himself) going hard on the denial that Tobey Maguire and Andrew Garfield aren't in the third movie. There hasn't been any official casting news from either Marvel itself, nor even an film industry report (where Electro and Doctor Octopus were both announced). And if they are indeed not in it, then that's fine.

If it turns out they're just straight up lying to everyone because Maguire and Garfield are actually in the movie, then that's really grating. I dunno why they can't just avoid talking about it. It's OK to say "wait and see" or "wouldn't you like to know", or shit like that.

also he multiverse is absolutely coming in Doctor Strange 2, but it has been a weird rollout of the concept between Endgame directly introducing it and then Spider-Man 2 doing that ultimately pointless fakeout with Mysterio.
    

Re: Garou: Mark of the Wolves AutoHitdef

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

Re: Everything Anime and Manga Thread

 March 08, 2021, 02:18:03 AM View in topic context
#10
 Posted by rgveda99  in Everything Anime and Manga Thread (Started by ( ゚ o゚) It's Urza! August 27, 2007, 02:30:58 AM
 Board: Entertainment

About time.  :coollove:

https://www.crunchyroll.com/anime-news/2021/03/06/the-devil-is-a-part-timer-returns-for-2nd-season-after-8-years-1st-trailer-released

Quote
In a surprise announcement tonight, it was revealed that The Devil is a Part-Timer! will be getting a second TV anime season in celebration of the light novel's 10th anniversary, which is written by Satoshi Wagahara and illustrated by 029. The first season of the show aired from April 4, 2013, to June 27, 2013. The first trailer, key visual, and confirmation of the returning cast were revealed, giving us the first taste of what the new season will be serving up.

Hoping Grimgar and Mayou get another season. But we are getting Log Horizon season 3.
    

Garou: Mark of the Wolves AutoHitdef

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

error with A.I

 March 08, 2021, 02:02:14 AM View in topic context
#12
avatar  Posted by mugenfan89  in error with A.I (Started by mugenfan89 March 08, 2021, 02:02:14 AM
 Board: M.U.G.E.N Configuration Help

I'm getting these errors in debug mode while one of my chars sometimes freezes whenever I fight against him.

warning : player Baraka (56) in state 131 has no target with hit id-1
warning : player Baraka (56) in state 131 has no d-th partner
warning : player Baraka (56) in state 131 has no i-the enemy

or also

warning : player Baraka (57) in state 130 has no TARGET WITH HIT ID - 1
warning : player (57) in state 130 has no d-th partner
warning : player Baraka (57) in state 130 has no I-the enemy

How can I solve this???

Please any help is appriciated.
    

Re: Haohmaru updated (06/03/2021)

 March 08, 2021, 01:51:47 AM View in topic context
#13
 Posted by MightyKombat  in Haohmaru updated (06/03/2021) (Started by KarmaCharmeleon March 06, 2021, 06:42:21 PM
 Board: Your Releases, 1.0+

Also that one Terry super's official name is actually "High Angle Geyser" and not overheat
    

Re: POTS Kotaro custom (Ned trying...)

 March 08, 2021, 01:49:16 AM View in topic context
#14
 Posted by Mastertkof  in POTS Kotaro custom (Ned trying...) (Started by Nedflandeurse March 06, 2021, 02:43:57 PM
 Board: Projects

prealted skirts  :smitten:


man... sure this is a great project, just keep doing something... when you can...
yatagarasu is amazing.
    

Re: POTS Kotaro custom (Ned trying...)

 March 08, 2021, 01:41:56 AM View in topic context
#15
 Posted by FeLo_Llop  in POTS Kotaro custom (Ned trying...) (Started by Nedflandeurse March 06, 2021, 02:43:57 PM
 Board: Projects

Merci beaucoup pour c'est tres jolie sprites :)!!

Thanks a lot for these awesome sprites!
    

Re: Akko sprite project

 March 08, 2021, 01:34:58 AM View in topic context
#16
 Posted by Shimmering Brony  in Akko sprite project (Started by Shimmering Brony January 04, 2021, 02:03:14 PM
 Board: Sprite Projects

    

Re: MUGEN Video thread

 March 08, 2021, 01:23:54 AM View in topic context
#17
 Posted by GF202020  in MUGEN Video thread (Started by c001357 September 27, 2008, 11:24:14 AM
 Board: M.U.G.E.N Discussion

    

Re: KarmaCharmeleon's WIP thread: Ash Crimson

 March 08, 2021, 01:18:04 AM View in topic context
#18
 Posted by NDSilva  in KarmaCharmeleon's WIP thread: Ash Crimson (Started by KarmaCharmeleon April 21, 2019, 02:40:00 AM
 Board: Projects

One more pal for Ash:



Lumine (Mega Man X8)

    

Re: How to install PotS Style hyper portrait to a char

 March 08, 2021, 01:14:06 AM View in topic context
#19
 Posted by ヒカリ ♡  in How to install PotS Style hyper portrait to a char (Started by TheDragon March 05, 2021, 07:52:21 AM
 Board: M.U.G.E.N Development Help

The hyper port is a helper that you spawn at the beginning of your super move. Look at existing PotS chars, copy and paste the code, change the hyper port sprite to your own, and it's done.
    

Re: Misty Maze by Mr. I

 March 08, 2021, 12:34:59 AM View in topic context
#20
 Posted by Yagoshi300  in Misty Maze by Mr. I (Started by Yagoshi300 March 07, 2021, 06:44:31 PM
 Board: Requests