The 100 Mega Shock!

It looks more ergonomic for the game (maybe also some VC games / arcade style games) than the Pro Pad or the Gamepad but I don't feel like spending money on it. For the price it might make a good simple pad for 4-button / 6-button games because it works over USB on the PC and PS3 as well.

Who said that? They said it would be a Pokemon with a ラ in it's name.

Yeah I hear Harada was on record saying "no fat chicks"

Well in this case Braxien's design for gameplay is supposed to be agile and ranged, so it makes more sense to use the smaller design that actually has legs for acrobatics.

Are you using WinMUGEN or Mugen 1.0/1.1? The AILevel feature does not exist in WinMUGEN

he's afraid of vore edits

lmao good job you can pause the game and go to gamefaqs now

you can possibly get by if you set the taskbar to auto-hide or move it to the left/right of your screen to add a little bit of extra vertical space

a series of d&d campaigns where the dm is very bad at thinking of ways to start them

they sure are making a lot of pokemon games for the super nintendo these days

Not much to show on the character this week as I've spent most of the time correcting the velocities and implementing more accurate behavior for jumping/dashing friction, air gethits and proper velocities during air combos. What I have also been working on is a small program to automatically process sprites like these and make them look better - specifically replacing the black outlines with darker shades of the closest color, adding outlines around small details like the eyes, and adding smoothing between two shades of the same color. At the moment it's a very early prototype - all the color values are hardcoded, it's buggy and has no real GUI to speak off, so it's not much use to anyone else as of now. An example using the standing stance: For testing purposes, I probably can't fit two AA shades in each palette entry with the level of color separation going on, and the outlines probably need darker entries instead of using the next shadow color.

Are you sure you aren't experiencing keyboard ghosting instead? I don't remeber what the default keyboard layout is or what you've changed the controls to but for example I can't hit Z & X simultaenously with the down or right arrows on my laptop.

It's all custom animatiom, just the original meshes from the 3DS.

It's an unserious character, since i have 700 3D models and i'm going to use them.

Hi im back again with a brand new character https://www.youtube.com/watch?v=uQykwn2M4kw As you can see in the video it's based on the first Marvel Vs Capcom aiming towards a fair amount of accuracy that I could scrape from the game. Currently it doesn't have half the special moves or AI logic for any of them coded so it can't do much more than just rush forward and do chain combos. Hey weren't you making that MvC2 Mewtwo- Yeah but it wasn't shaping up so well and I don't have the time to clean up sprites all day instead of just rendering a model in high-res. Maybe I'll look back into it now the SSB4 3D model exists. Images:

lmao, the first SRW with Gundam AGE and it's not even featured on the promotional art in favor of the obscure SD Gundam OVA from 1990

its some guy who enjoys pretending to be a nintendo employee and sending dmca takedown requests to mediafire

sorry guys i told my uncle jason at nintendo about mugen

nobody thought of spinning attacks before now

I recommend having two states - your attack state and a seperate state for landing instead of using the default 'jump land' state. Set your first state's physics to 'N' - this means that Mugen's default jumping physics - gravity and automatically changing to State 52 when the character is touching the floor - don't apply and give us much more control over how the move should behave, especially in terms of the recovery state when they hit the ground. In your first state, have a VelSet trigger at the point where you character leaps or jumps up with a negative Y and a positive X value (if it's moving forwards while jumping). After the jump occurs, use a VelAdd controller which only triggers after the initial VelSet, and make it add a small amount to the Y velocity on each frame - this slows down their rate of ascent and eventually cases them to begin falling, like gravity. Depending on how the attack should look you may want to also decrease the X velocity or reset it to 0 at a certain point, like how a shoryuken stops travelling forward once the character begins to turn around. Also remember to use a StateTypeSet controller to turn StateType = A (for air) once your character leaves the ground. To make a falling character go into a landing state, use a ChangeState controller with the trigger "trigger1 = Pos Y + Vel Y >= 0" and also the same trigger you used to check if the character has left the ground so that they don't immediately try to 'land' before jumping In your second state, the landing, add a VelSet trigger at time = 0 to set their Y velocity to 0 so they don't continue to fall through the floor. You may also want to set the X velocity to 0 or let the standard physics have the character slide forward a bit then slow down with friction. Also use a PosSet controller to trigger at time = 0 that sets y = 0, just to make sure the character hasn't fallen slightly too far and ends up 'underground'. Afterwards, do the ususal thing to go back to state 0 at the end of their landing animation or whatever.

Lower the hit time on the fireball, 20 is quite high. Making a ground fireball knock opponents off their feet looks a little wierd too. SImilarily, any other infinites usually mean you have attacks that are either too fast, keep the opponent in hitstun for too long or don't put enough distance between you and your opponent after being hit to stop you from repeating the move (or any combination of the above)

Those are bad examples because "infinite priority" is a bullshit concept because it's not a hard and fast rule for every move in every game. Many games have situations where charactersr red hitboxes extend some amount outwards past the blue ones, so you dont get trades all day long - priority is still set by how fast the attack is and the specifics of where their red/blue boxes are placed in respect of the attacking limbs. In a real KOF like 99 or 2002, K's attacks have hitboxes that are nothing like those examples. The most times I've ever seen the blue boxes covering red is for light and fast normals, even then it's rarer in some games than others (all the time in Marvel for LP and LK, sometimes in KOF [even then it varies from 94 to XI], very rarely in Alpha 2 and Vampire Savior). What I would recommend is simplying your hitboxes a lot more, you can easily get away with one hitbox on its head and not necessarily cover the entire snout so you can't be so easily poked at range. Attacks should rarely need more than 1 or 2 red boxes in a farily simple arc but remember to put a decent blue box around the limb that is attacking so that the other player can reasonably counter. Keep that they are supposed to represent the space that attack is travelling through in the time it takes to show each sprite on screen, not the exact pixels you see in each one. You can check out a lot of this stuff using the FBA-RR or MAME-RR emulators and special scripts to show hitboxes in many Capcom & SNK games. Or just find good conversions to play in Mugen e: thanks for prempting me while i spent so long downloading kof roms matt

something like a headbutt is really simple because you just need to do one custom state and BindToTarget before the hitdef appears

we need to advance the tech out of the stone age

gotta get it past the hack checks first