-
Posts
1,227 -
Joined
-
Last visited
Everything posted by RobotMonkeyHead
-
Agreed. --- Wario's 4 linkable ground throws demo. There are also 4 air throws very similar in style that can be linked to the ground throws that aren't shown here. Suggestions welcome.
-
I like the ideas so far. Is there an existing Wario that anyone knows of that has Wario-Man sprites in it? Or an existing Walouigie that is a similar style to this Wario? Laharl, for the coins, what about one of those time blocks that make a bunch of coins appear for a limited time (ticker sound effect) and then make it so when Wario get's a coin he throws it at the opponent. So you sort of have to run around the screen "collecting" all the coins that appear and throwing them at the opponent? He also does have a bite sprite, and I'm absolutely going to program that projectile eating special. Also made some wheelie sprites for the bike today.
-
Minor palette trouble.
RobotMonkeyHead replied to RobotMonkeyHead's question in [ MUGEN CODING HELP ]
Damn that's crazy, I think I got it tho. Thanks again for the help Tex, it's very much appreciated. -
Spent pretty much the last 3 days processing Wario's sprites. I was able to get him down to a 64 color palette, and reloaded all of his sprites 1 by 1 twice (messed up the first time!) and now he's Mostly separated. I tried my ass off to get complete color separation, but alas my monkey style Gimp fu was not strong enough. I think the closest I got was applying a .33 radius gaussian blur which didn't obscure the sprites, but localized the colors so they weren't Exact matches depending on what they were surrounded by. Still no success. He's close to separated tho, and his entire sheet from spriter's resource has been filtered and converted to that 64 color pal, so once the hypers are done and all the sprites are added, the color separation should be easier. Anyway, now that all the sprites are accessible and uniform, on to actually coding the hypers.
-
Where could one find a copy of that?
-
This can be placed in any state, as long as that state gets entered at some point. State -2 is probably best, because it's guaranteed to run. [state 0] type = VictoryQuote trigger1 = p2name = "Wonderwoman" ; <- not their displayname, but their name from their .def file. value = 5 ; <- provided it's victoryquote5 you want said.
-
Looking for help coding stage zoom. 2 issues.
RobotMonkeyHead replied to RobotMonkeyHead's question in [ MUGEN CODING HELP ]
Yea recoding it would only take about 20 minutes. I'd still run into the same problem tho I think... Unless I move the entire thing down, so the boundhigh is 0 either way, and then just have the bound low set just below the zoffset so the players kind of pull the camera down. That actually might just work. -
I realize I've put up a few of these topics lately, but I do look around for tutorials and things before I ask. I'm just wondering how to apply a different existing palette to a group of sprites and actually have it stay after saving, closing and reopening. It applies fine, it's just if I save it and close and reopen the old palette is back on the group of images.
-
I like the garlic breath thing... I'm not quite sure how to make it work tho. He already has a move to knock opponents dizzy at close range. Maybe a belch and a slowly traveling projectile cloud, sort of like Gen-An's poison? The bike is actually one of his specials already. It's only 2 sprites tho, I was considering making a few more sprites, a side skid and a wheelie, but that's pretty low on the priority list right now. I want to get his hypers done first. For the sub I was thinking it might be cool to fill the stage with water momentarily (just a full screen overlay of light aquamarine tone with some bubbles, and let him drive around in the sub for a bit and shoot at the opponents till they deal enough damage to the sub. Still not sure about it tho. I think I'm just trying to figure something out for it cause I have the sprite :) I don't know about the game cube thing either... One thing that would certainly be possible for a hyper would be to use one of the bosses, either blooms day, shake king or large fry, and have Wario sort of summon them. Their sprites are on that site too...
-
Nice, this looks sick. Downloading for sure. Thank you DuckSS.
-
Here's something I've found very helpful. This Gimp script exports every layer as a separate file, while allowing you to use text, the layer names, the file name or any combination of the three as the exported file names. Just download it, and drop it into the folder named "Scripts" inside your Gimp folder, and restart Gimp. There should now be an option under File > called "Layers". https://github.com/s...port-layers.scm There are a lot of ways to use it. Some ways I commonly use are to break GIFS down into individual frames (you can process a huge gif in a few minutes this way), or to process large amounts of a characters sprites at once. Here's the step by step (day by day, a fresh start over, a different hand to play): ___/ FOR GIFS 1) Open up the GIF in Gimp. It should be in indexed color mode. 2) Set your foreground color to ff00ff magenta. 3) Open the Colormap dialogue window to view the palette. Right click on the palette, and click "Add color from FG". 4) Right click on the palette in the Colormap dialog again and click "Rearrange Colormap". A window will open where you can drag each color do a different position by clicking and holding while you move it. 5) Move magenta up to the first slot and click OK. 6) Optional: go to "Layer > Stack > Reverse Layer Order" to put the frames in their original order. 7) Name each layer a number. Top layer "01", second layer "02" etc... 8) Go to "File > Layers", select an output directory, set Filename format to "WhateverYouWant~l.png", minus the quotes of course, and click ok. ___/ FOR A BUNCH OF CHARACTER SPRITES 1) Open up a character in FF3. 2) Click Sprites > Save Image... > Select "All" or "Group" > Choose a folder (helpful to create a new folder before hand inside the char folder). Enter the characters name and hit ok. 3) Once you've saved all the characters sprites in a folder, go through and delete the ones that don't use the characters palette. (only necessary if you saved all of them) 4) Open the first sprite in Gimp. The palette should be intact. Then click File > Open as Layers... and highlight all but the first sprite, and click ok. 5) Smile. You now have all of the characters sprites (that use their main palette) open in Gimp, with the layers named as the Group / Index, ready for export. 6) Make whatever changes you want. When you're done doing whatever you wanted to do, File > Layers, and choose a destination file to export your edited sprites to. 7) Open up FF3 and open the character, and go into the sprites section. 8) How you loading the new sprites into the character depends on what you want to do. When loading many sprites, pay close attention to the file names, because when FF3 saves them it doesn't upt 0's before single digit numbers so the file order can be a bit weird. 8a) If you want to replace existing sprites in a group or groups you'll have to do it one at a time to preserve the x, y axis. You basically just click "Add New Image for Sprite from a File..." (the second icon) for each frame, and select the new sprite. 8b) If you're adding in a new group, say a new attack you've created from existing sprites, just click "Add One or More Sprites..." (the first icon), highlight all of them and click ok. Now all you have to do is name the groups and indexes, set the alignments how you want them and you're good to go
-
Here's what I've got to work with in terms of sprites. Plus the frankensprites that were already in his file. I've already processed / paletted all of his sprites from that site, so anything there that wasn't originally in the character is accessible now as well. If there isn't some with his mouth open, I can easily make them. I like that idea. As for his hypers, now would be a perfect time for suggestions. I just finished processing all those sheets so I could use the sprites to create some new ones. I want to do something with the snowball (roll across the screen, then drop from above and explode probably), and something with the fire (self immolate, then run around back and forth a few times, center out on the screen and burst into flames probably) and I also was thinking of having him drop that submarine on the opponent from the top of the screen. That's about all I've got so far tho, any more ideas from you would be more than welcome.
-
Looking for help coding stage zoom. 2 issues.
RobotMonkeyHead replied to RobotMonkeyHead's question in [ MUGEN CODING HELP ]
It's all good friend, like I said I really appreciate the help either way. Thanks for trying. -
Looking for help coding stage zoom. 2 issues.
RobotMonkeyHead replied to RobotMonkeyHead's question in [ MUGEN CODING HELP ]
I appreciate the help LightFlare, but the problem remains. I might have done a bad job at explaining what I'm trying to do. Basically I don't want the camera to scoll vertically at all when it's zoomed out all the way. When it's zoomed in all the way, however, I want it to be able to scroll up -120. That's what seems to be impossible. It seems like I'm stuck with a set amount of vertical scrolling, no matter what the zoom is. That means if I have it set so the stage can zoom out all the way, showing the entire bg sprite, I have to have the vertical scrolling (boundhigh) set to 0, otherwise the magenta will show when they hit the top. What that also means tho, is that when it's zoomed in it won't follow them up when they jump. because the boundhigh is zero. See what I'm saying? I'm hoping there's some kind of work around for that. The xscale and yscale are both 1.5 so the stage is actually 360 high, not 240. There's plenty of room for it. Try opening it up and setting the boundhigh to -120, and use KFM to like quadruple jump up into the magenta. Tensionhigh pretty much just replaces what floortension and verticalfollow were doing before. On another note, I did figure out that "jittering camera" issue, so it's just the one to go. -
Looking for help coding stage zoom. 2 issues.
RobotMonkeyHead posted a question in [ MUGEN CODING HELP ]
_____/ First Issue I've run into something I can't figure out regarding zoom, while trying to update my stage edits to 1.1: It seems like I can only do one of two things, where I would really like to do both. The problem seems to be the boundhigh. If it's set to zero, you get the first situation. If it's set to about -120 or so you get the second situation. First, I can get the stage to zoom out all the way so that the top of the stage sprite lines up with the top of the screen. But if I do this, when it's zoomed in, the camera won't scroll up to follow the characters when they jump, even tho the floortension and vertical follow are set right. xor Second, when the characters super jump I can get the camera to follow them to the top of the stage, but when it zooms out all the way, it still follows the characters just as much (absolutely) vertically as it did when zoomed in all the way, so if they super jump when it's zoomed out it exposes the purple background of the stage. Does anyone know how I can get this stage to be able to zoom out all the way, so the top of the stage sprite is the top of the screen, but when it's zoomed in, still have the camera follow the characters up to the top of the stage when they jump? Here's a download link if you feel like testing it out, and some screenshots for the problem. Any help would be greatly appreciated. _____/ Second Issue The second problem is that when player 2 is all the way to the left, and still holding the left directional, and then player 1 walks away from them toward the other edge of the screen you get this weird jittering effect at some distances. Messing around with the bounds helped in one instance, but I can't seem to get a reliable setting for it. Does anybody happen to know what's causing that? -
Nice, thanks for the gameboy. Yea I might just have to switch all my stuff over to drop box at some point in the near future. I already had to change the name of my Hwoarang edit to Who Rang RMH.zip
-
Exactly what I was looking for. Thanks Staubhold.
-
Does anyone happen to know where I can find the default states and animations for things like "shocked" "burnt" "frozen" "slipping" etc?
-
For a little extra cheese they could have spelled her name Mona Liza. Named after a Da Vinci, and hooked up with Raph.
-
Na, that's not your fault, I'll look into it today and see if I can fish out what you're talking about. Thanks. Glad you like so far. Now that the throws are finished, I'll be starting on the hypers very soon, so that's going to get bulldozed, paved, and rebuilt from the ground up resembling its original form, like almost everything else.
-
4 air throws implemented, all similar in style to the ground throws that share their same button combination. ____/ AIR THROWS ___/ GROUND THROWS 1) Spin pile driver x+y 1) Spin x+y 2) Air roll y+z 2) Roll y+z 3) Air slam b+c 3) Slam b+c 4) Air toss a+b 4) Toss a+b The throw chaining works in the same 4 throw pattern, whether you start in the air or on the ground. Each throw can be chained only to the next number in the sequence above. spin > roll > slam > toss, beginning with any one you want. You could think of their order as a circle on the button pad. 1 -> 2 (X ) (Y ) (Z ) (A ) (B ) (C ) 4 <- 3 The air pile driver and air roll can also be chained into the next ground counterparts in the sequence. e.g pile-driver > roll > slam > toss or air roll > slam > toss. Throws are chained by pressing their command right before the previous throw terminates. 20 tic window, to be exact. Pressing them to early means you do not get another chance to press them at the right time, so mashing is not an option. Pressing other buttons accidentally doesn't forfeit your chance to press the right ones. Obviously starting with spin does the most damage, but there are other advantages worth considering. If you miss the link on a spin it has no juggle potential, unlike a roll or a toss, which also might make them worth ending on. Slam leaves the opponent very close which makes it a suitable ender in some circumstances. It's also very quick which can make it a decent stand-alone. It's also possible with a more difficult command "up, down, x+y" to chain the pile-driver into the ground spin resulting in a 5 throw chain, rather than 4 (spinning pile-driver > spin > roll > slam > toss) for a little extra mayhem. --- SPRI YAR ZON, did those fixes work out ok for you?
-
Great, no prob! Just for the sake of your own learning, here's a quick explanation of it. The issue with restarting the attack state from within itself is two fold. 1st you loose the ability to end the state by a time check. 2nd, normally you don't have control while in the attack state (ctrl = 0) so any command checks inside the state won't work. Unless of course you have control on (ctrl =1) in which case you'll be able to walk, or jump or do basically anything else right in the middle of the attack. So what you need to do is have ctrl = 0 in the attack state itself, and then check for the command from outside of it, in the cmd file (state -1). From there, instead of restarting the whole attack state, all you have to do is restart its animation, because the hitdef is re-triggered every time the animation is on a certain frame (1,3,5,7,9). This allows you to check for the overall time of the move from within the attack state itself, while only being able to press that certain button to re-trigger the attack as many times a possible within a given time frame.