4 values? So you at least get one hit box. Also if you find the data you have to convert the data. Where the Capcom play system is done in a 12:7 ratio instead of a normal 4:3(thats why screen shots come out as 384x224 instead of 320x240). The hit boxes won’t be an easy copy paste job.
You could always base your game off of Hunter and not Savior. I know I’d prefer that. 
I have a feeling that’s not exactly what you want to occur, however.
good you guys making a new VS game.
Actually it’s not something as simple as that even. Those four values seem to be additional pointers, themselves pointing at the actual quartet of coordinates for each box. Oh and if I’m right about it, it gets worse as it seems each of those four boxes are in a separate data bank, meaning having to wade through four for each change. I don’t know why Capcom did this.
As for the resolution, already figured a way around that. Mugen’s latest version can support odd resolutions, including 384x224. The 1.1 version in particular will allow you to scale the graphics display to whatever you need it to be, so while the gameplay will be intact the resolution will give the proper 640x448 viewing.
It’d work in a worst case scenario. There isn’t much I’d have to change in my structure for the gameplay to still work.
Its your game so take this for whats its worth. Add as much defensive universal properties as possible(like GG series). It goes a long way as far as balancing the game.
That seems right two attack boxes and two hitboxes (one for mid and one for low). Shouldn’t there be at least a fifth showcasing a box for throws? and a sixth showcasing collision to the ground?
Keep it like old school Capcom work in 384x224 to keep it it as close to the original unless mugen can’t stretch the images to work in other resolutions.
Also on characters have you thought of Amingo’s Dark forces yet? You better not be do universal dark forces.
It looks like the pointer and 4 boxes I found relate only to regular hit boxes, not attack collision boxes. This means in turn too that VS has 4 boxes at most times. When you jump in turn the highest and lowest boxes get set to 0, so this does make sense. And yep, I’m keeping it 384x224 (well, 768x448, x2 res for smoother scaling and rotation where used). There will be an option for people to play it in 640x448 though for people wanting it in that resolution: the gameplay will be left unaffected.
As for Amingo’s DF, this is what I had planned: “Photosynthesis: When standing still, you recover health that you normally can’t at a slow rate, and recover regular recoverable health at 1.05 the normal rate.”
KFM: Address FF848C-FF848F seems to hold a 4-byte pointer to the offsensive hitbox table address. If you replace it with a valid value from from another character, offensive hitbox size/placement and attack properties become mixed up. There are a bunch of other similar pointers nearby that seem to point to nearby addresses, so it’s possible these point to the vulnerability and push box tables. I’m still trying to work out the specifics of these, I’ll let you know if/when I get them worked out.
EDIT: FF8480-FF8483, FF8484-FF8487, and FF8488-FF848B are definitely vulnerability box table pointers, I screwed with each one’s value and it lead to Morrigan’s hitting Felicia with her standing light punch from a full screen-width away, and creating a hitspark at the top-center of the screen. In all likelyhood, these are Head, Body, and Foot in that order, but I’ll have to do some more investigating.
EDIT2: FF8490-93 is a pointer for the push box table. Messed with it’s value and now Morrigan can’t jump over Felicia.\
EDIT3: FF8497 is a pointer for the specific box to be read from the push box table. Each specific box is defined by 4 2-byte values. For example, if FF8497 is currently 01, and the character’s push box pointer at FF8490 is A2B30 (Felicia), then the current push box will be defined by the 4 2-byte values starting at A2B38.
EDIT4: The preceding 3 bytes (FF8494, FF8495, and FF8496) each seem to function similarly with the aforementioned vulnerability box pointers, albeit they don’t actually determine the currently active vulnerability boxes, so much as refer to them. They’re read when the opponent does an input that can result in a throw, so they’re most likely just there to check if the opponent is invincible or not (if all 3 vulnerability boxes are 00, they’re invincible).
Felineki, what are these values in relation to exactly? Raw data, the debugger, artmoney? As far as the data itself, I’d wager there’s a second pointer for offensive hitboxes right next to the first, since these games have a track record of having two offensive hitbox banks next to one another. FF8490-93 seems to be the offset value for the following address. Quite possibly too there might be a preceding offset value before FF8480 relating to those boxes. It makes sense for them to be 2-byte as well, since it’s a signed interger for each coordinate that can be higher than 128, hm…
Now how to read these values…
Bumping for new news:
-Thanks to being able to view the hitboxes…well hey you can figure out the rest from there. Work’s going to be a lot smoother. Huge thanks again to Felineki, Aokmaniac13, Xenozip, and MC for it.
-I’ve gotten a few PMs on things to fix once things are together, and I’m going to start considering them once the game’s completed: like I said I want to get it working exactly first then play all over the place with it. So please don’t take offense if I didn’t respond there, just been busy putting the core together.
-Rewiring the system to behave less like mugen and more like a full game is going well too: case in point, a fully function continue system. I’m hoping during tomorrow since I’ve got the day off from work to tackle the remaining round aspects (cornerpush, recoverable life, the “lives” system) the rest of the way and then get really into the character assembling aspects of it all.
All for now, more as things get developed.
Virtualization and Protection Tools at Molebox.com
There are programs that let you lock up folders and files into a single executable.
And yeah no one takes PC games like say, the first versions of Melty Blood, seriously. Which is why it died out and never got arcade/console releases or popularity or into EVO or anything like that.
So, since it’s now possible to get hitbox data for VS, are you going to be pulling the hitbox data for Pyron, Phobos, and Donovan from VH or VH2?
youd be suprised!
I’m excited about this project and very much interested to check it out! But on a slightly unrelated note:
Now you have access to the hitbox data, could you maybe, possibly, pretty please, also provide the hitbox data for the VS at some point? I bet players besides me are also dieing to find out.
No game really can be, and any modifiable engine finds itself in the same case, even crap like Fighter Maker. People want to unpack it and modify it, that’s their choice. The base version will be identifiable as it is, and won’t be that easy to just screw around with: it’s not programmed like regular mugen. Adding a new character in will break it, and screwing around with it will probably have the same results. And if they gut it for their own games well good for them, there’s nothing stopping them just like their isn’t stopping someone from releasing “SF3: 4rd Strike” or some kof hackjob with boobies.
I’ve been around long enough to consider that well before now.
VS2/VH2. Since Dee’s a mixture of Donovan and Demitri to a T, I can use both of those to handle him as well. Dee’s sprites however like the Chaos Tower stage will be interesting to get, though the stage much moreso, so both of them are going to be dealt with last. Donovan will retain his option however to choose how you set his sword into the ground (VH or VS2).
Speaking of Pyron, using some old resources I have around for a bit of a cosmetic tweak, he should be getting [media=youtube]1DZAIFQH4fM&feature=related[/media]
Rogueyoshi linked to the best source, but the LUA’s constantly being updated and tracked by Xenozip in this thread if you want to keep up to date on it for other titles too…seems he’s going to try and do the whole CPS-2 range.
Sexy Tony Jay voice is sexy.
I’ve been working on a means to try and include Marionette in the game in a sense, though still fighting with a proper means to “clone” P2 over. I’ve tossed a suggestion at elecbyte to introduce a “ChangeChar” sctrl to simplify this by a truckload. It’ll also have the added positive effect of making Rival and final boss fights possible. If anyone’s interested in the proposal, I’ve posted it here. Not sure how much elecbyte listens to support for such a thing but a little added bit might give them reason to consider it.
As for Oboro Bish and Dee as final bosses depending on condition, it’s completely doable with how the KO system is set up even without that. Double KO, the life system, and Time Over are all set up now finally too, just a few more cosmetic bits to add and some bug checking/situation checking and that’ll be good to go.
As it stands the following major core elements for gameplay still exist to deal with: recoverable life, cornerpush, and power bar handling. The vs screen still needs the rest of its elements worked in too for showing what the next match is, and a game over screen added in. I’m plotting out a training menu too. Team modes you might as well consider as not happening until Elecbyte allows me to turn off the actual Team setting, since I can still make Simul viably work as a 1vs1 system. Once that happens expect some serious looking at Survival while I’m at it.
Slow and steady as she goes.
Here’s to hoping for your success.
…you bastard (remembers when I had cvs2: remix thread and you trashed it to hell :lol: ).
:razz: