UsagiZ,welcome back my friendHey everyone - thanks for sticking around and keeping an eye on this project, despite no updates for all this time.
Don't really know what else to say other than I really appreciate it, and sorry to keep you waiting, honestly.
I haven't stopped working on 2++, but I haven't had the time or motivation to post about it in the midst of some serious life stuff.
That being said, I'm back for now with some pretty major updates, and some discoveries:
I managed to find the location of the hardcoded file size limits - finally! Despite previously being able to modify reserved space in the .afs files, there was still a cap on how much data you could actually add. Once your imported data surpassed this limit, the game would just overwrite it with hardcoded stuff from the .xbe. - and if you imported animations, for instance, your character would just float, glitchily, into the air when trying to access that data that has been overwritten.
This is the location of the size limit for the comon.mot
The 0x00001300 indicates that the comon.mot file can only be up to 0x130000 bytes.
For 2++ I changed this to 0x00001400 which gives me 10,000 (hex) extra bytes to add in new animations, no replacing old ones necessary, just tacking the new stuff onto the end of the file - which really opens the doors for changing the feel of this game with revised animations, finally!
Though, if need be, I think the game will be ok with possibly up to 0x150000 for this specific file.
-I also figured out the comon.mot size limit location for Doa3.1 - which was simple after finding 2++'s
Weirdly, the limit for both games is 130000 despite DOA3.1 having more stun animations than DOA2U.I also found the location of the character.mot file size limits, which weren't global, as I suspected.
Each of those groups of 4 are one character's limit (including the 00001200 at the top right that isn't highlighted)
They are in the same hardcoded order as the characters in 2U.
Zack - Tina - JannLee - Ein - Ryu - Kasumi - Genfu - Helena - Leon - Bass - Leifang - Ayane - Hitomi - Tengu - Bayman
I was previously unable to give Bass his DOA3 ground throws, and similarly, unable to give Tina's. After changing the limit, I was able to add those all in - which significantly buffs both of them.
I haven't yet looked in to DOA3.1's character mot limit - but I suspect they should be formatted similarly - and I'll look into it when I get the chance.I attempted to see how large I could make the limits of the character.mot by making Tina.mot 0x160000 bytes.
It worked, however, I kept running into a freeze with certain character matchups, and when I fought against Ryu, specifically, his model would be missing parts, as if Tina's character.mot was overwriting parts of Ryu's mesh, or possibly -- and this is just a guess, causing ram issues.
Sadly this most likely means, despite being able to change the size limits, you will run into issues if you make them too large. So I settled with making Tina's character.mot 0x148000 - wich was previously only 0x120000 - which gives me plenty of space to add stuff without causing other issues as far as I'm currently aware.I found where the xbe stores catch throw information. - I had previously been making pseudo offensive holds by using auto-strings - stringing a throw into a hold during the later frames.
After finding this data, I was able to make proper catch throws, the way 2U/3 handles them.
Each entry is 0x4 bytes, first two for which character, and second two for which move-def slot to treat as a catch throw.
The highlighted bit indicates:
01 00 = Tina
19 01 = in Tina's character.bin
Obviously there isn't any room to simply write new catch throws at the end of this section, so I had to find the pointer that points to this bit of data and repoint to a blank or unused area - in my case, the DOA2U Xbox Live text section.
This section always terminates with FF 00 FF FF
Highlighted is:
01 00 = Tina
38 01 = in Tina's character.bin
This section terminates with FF 00 FF FF2U's Stage Select List:
Each entry in DOA2U is 0x18 bytes long
This image indicates this slot selects stage 1F, uses name 38, has Icon A for standard resolution, Icon 20 for Widescreen.
They always have the stage repeated 3 times (1F 1F 1F).
I was able to replace random with THE MIYAMA in 2++. I tried adding a stage after random, but for some reason that causes a freeze - even if I repoint the data to a place with more free space, so I'd guess all new stages need to be placed before random.
I was also able to test adding more selectable stages by changing that 15 05 on the line before the first stage (1f 1f 1f)
I believe the 15 was for number of single stages, and the 05 for tag stages - if I recall correctly.
DOA3's stage select entries are 0x10 bytes each, so each line is its own stage.
That last entry (00 FF FF FF 7D) is random - I changed this to (00 49 49 49 7D) and replaced the random icon in the loadfile.afs to be able to select Genra's stage in any mode where you can pick stages.
Here are the assets I made to give Hellfire an icon and selectable name
For DOA3, you can make the first and last entry in the stage bytes different values to allow alt stages, similar to the beach stage.
Hover on the icon, hit down or up to select alt versions - this way you can select different levels of the stage directly.
For example, change 3F 3F 3F into 3F 43 4C to make all levels of Azuchi selectable on stage select with up and down for each level.
35 35 35 to 35 35 3C to make DOATEC HK lower level selectable, etc.
I haven' t done extensive testing, so I'm not sure that always works as intended.
3's also got some unused stages.
32 32 32 DOA3's version of the Tatami stage from DOA4, endless checkerboard.
33 33 33 DOA3's test wall stage
39 39 39 unused Azuchi section (Hitomi practice scene from intro)
-----------------------------------
There are some things I never clarified in the character.bin that I should quickly explain:
This is the structure of a standard Hit Property, as seen in the default.xbe and also the character.bins
For this example, we'll use mid kick sitdown stun from doa3 (counter hit 3K, typically)
[B3 20] [49] [08] [14] [06 06] [00 00] [00 00] [00] [FF] [00 00 00]
B3 20 = first two bytes = which anim-def this property calls on/uses in the anim_cm.bin
49 = byte three = status after completion. [49] = standing, [03] = crouching, [06]/[07] = on ground face up/down, etc.
08 = byte four = hit-type [08] = stun, [09] = normal/air hit, [07] = guard, [0F] = down attack
14 = byte five = frames before you can hold. can be used to make a stun you can't hold escape. This value is usually FF for instant hold escape.
@Gultigargar
06 06 = byte six and seven are always 06 06 or 00 00, never tested anything else
00 00 = eight and nine, unsure if this is grouped this way, but byte nine is sometimes B6, which lets the property switch stance if hit by a stance dependent move.
00 00 = ten and eleven, are rotation in degrees. Rotates foe on hit. Usually see 15 00 here for slight rotation
00 = byte twelve, unsure what that does
FF = byte thirteen, juggle property, [FF] for grounded properties.
00 00 00 = byte fourteen, fifteen and sixteen = unknown. Never seen anything other than 00 00 00 here.
I made some progress with Niki's moveset - I'd say maybe 80% complete if I had to give it a number.
I still need to edit some of her throws and holds, and I'm always open to suggestions.
I used Alice's voice from the Bloody Roar series, since the quotes are generic enough to fit.
How do we feel about Niki having some of Zack's moves? I think some of the animations maybe don't quite fit, but she's sort of a goofy character like Zack, at least in DOA4 and DOAX2 - so I think it might be passable?
This has been pretty difficult, not going to lie lol - but I think it's turned out ok so far.I'm cobbling together a demo release of 2++.
I know y'all have been waiting, so I'm trying to iron out some issues before compiling stuff.
I wanted to do a proper demo release, but I don't know if that's even necessary?
I'll include command lists and such, since Sparring's command lists will no longer be accurate.
I'd love to hear what you'd like to be included, if anything?
Or should I just compile all the current files, and go?
Eventually I want to include a frame data spreadsheet for each character, but I guess that's not a priority for now.
Anyway, thanks again - and I hope you all have been well. More updates to come soon.
I'd like to make a script for de-compiling bin/mot data. Can't find these old games anywhere. If this is even allowed, can anyone share all the bin/mot files for doa2u/doa3/doa3.1/doa3.2/doa4 and maybe also the "xbe" files(they contain embedded bin/mot data).
The function for size limits is identical with the one from doao. In doao i expanded the size allocated for xpr/cat/bin/mot files from 17mb to 55mb(I was porting doa4 models and animation at the time, and the files were huge compared to doau). But xbox ram is only 64 mb, so you do the math.Hey everyone - thanks for sticking around and keeping an eye on this project, despite no updates for all this time.
Don't really know what else to say other than I really appreciate it, and sorry to keep you waiting, honestly.
I haven't stopped working on 2++, but I haven't had the time or motivation to post about it in the midst of some serious life stuff.
That being said, I'm back for now with some pretty major updates, and some discoveries:
I managed to find the location of the hardcoded file size limits - finally! Despite previously being able to modify reserved space in the .afs files, there was still a cap on how much data you could actually add. Once your imported data surpassed this limit, the game would just overwrite it with hardcoded stuff from the .xbe. - and if you imported animations, for instance, your character would just float, glitchily, into the air when trying to access that data that has been overwritten.
This is the location of the size limit for the comon.mot
The 0x00001300 indicates that the comon.mot file can only be up to 0x130000 bytes.
For 2++ I changed this to 0x00001400 which gives me 10,000 (hex) extra bytes to add in new animations, no replacing old ones necessary, just tacking the new stuff onto the end of the file - which really opens the doors for changing the feel of this game with revised animations, finally!
Though, if need be, I think the game will be ok with possibly up to 0x150000 for this specific file.
-I also figured out the comon.mot size limit location for Doa3.1 - which was simple after finding 2++'s
Weirdly, the limit for both games is 130000 despite DOA3.1 having more stun animations than DOA2U.I also found the location of the character.mot file size limits, which weren't global, as I suspected.
Each of those groups of 4 are one character's limit (including the 00001200 at the top right that isn't highlighted)
They are in the same hardcoded order as the characters in 2U.
Zack - Tina - JannLee - Ein - Ryu - Kasumi - Genfu - Helena - Leon - Bass - Leifang - Ayane - Hitomi - Tengu - Bayman
I was previously unable to give Bass his DOA3 ground throws, and similarly, unable to give Tina's. After changing the limit, I was able to add those all in - which significantly buffs both of them.
I haven't yet looked in to DOA3.1's character mot limit - but I suspect they should be formatted similarly - and I'll look into it when I get the chance.I attempted to see how large I could make the limits of the character.mot by making Tina.mot 0x160000 bytes.
It worked, however, I kept running into a freeze with certain character matchups, and when I fought against Ryu, specifically, his model would be missing parts, as if Tina's character.mot was overwriting parts of Ryu's mesh, or possibly -- and this is just a guess, causing ram issues.
Sadly this most likely means, despite being able to change the size limits, you will run into issues if you make them too large. So I settled with making Tina's character.mot 0x148000 - wich was previously only 0x120000 - which gives me plenty of space to add stuff without causing other issues as far as I'm currently aware.I found where the xbe stores catch throw information. - I had previously been making pseudo offensive holds by using auto-strings - stringing a throw into a hold during the later frames.
After finding this data, I was able to make proper catch throws, the way 2U/3 handles them.
Each entry is 0x4 bytes, first two for which character, and second two for which move-def slot to treat as a catch throw.
The highlighted bit indicates:
01 00 = Tina
19 01 = in Tina's character.bin
Obviously there isn't any room to simply write new catch throws at the end of this section, so I had to find the pointer that points to this bit of data and repoint to a blank or unused area - in my case, the DOA2U Xbox Live text section.
This section always terminates with FF 00 FF FF
Highlighted is:
01 00 = Tina
38 01 = in Tina's character.bin
This section terminates with FF 00 FF FF2U's Stage Select List:
Each entry in DOA2U is 0x18 bytes long
This image indicates this slot selects stage 1F, uses name 38, has Icon A for standard resolution, Icon 20 for Widescreen.
They always have the stage repeated 3 times (1F 1F 1F).
I was able to replace random with THE MIYAMA in 2++. I tried adding a stage after random, but for some reason that causes a freeze - even if I repoint the data to a place with more free space, so I'd guess all new stages need to be placed before random.
I was also able to test adding more selectable stages by changing that 15 05 on the line before the first stage (1f 1f 1f)
I believe the 15 was for number of single stages, and the 05 for tag stages - if I recall correctly.
DOA3's stage select entries are 0x10 bytes each, so each line is its own stage.
That last entry (00 FF FF FF 7D) is random - I changed this to (00 49 49 49 7D) and replaced the random icon in the loadfile.afs to be able to select Genra's stage in any mode where you can pick stages.
Here are the assets I made to give Hellfire an icon and selectable name
For DOA3, you can make the first and last entry in the stage bytes different values to allow alt stages, similar to the beach stage.
Hover on the icon, hit down or up to select alt versions - this way you can select different levels of the stage directly.
For example, change 3F 3F 3F into 3F 43 4C to make all levels of Azuchi selectable on stage select with up and down for each level.
35 35 35 to 35 35 3C to make DOATEC HK lower level selectable, etc.
I haven' t done extensive testing, so I'm not sure that always works as intended.
3's also got some unused stages.
32 32 32 DOA3's version of the Tatami stage from DOA4, endless checkerboard.
33 33 33 DOA3's test wall stage
39 39 39 unused Azuchi section (Hitomi practice scene from intro)
-----------------------------------
There are some things I never clarified in the character.bin that I should quickly explain:
This is the structure of a standard Hit Property, as seen in the default.xbe and also the character.bins
For this example, we'll use mid kick sitdown stun from doa3 (counter hit 3K, typically)
[B3 20] [49] [08] [14] [06 06] [00 00] [00 00] [00] [FF] [00 00 00]
B3 20 = first two bytes = which anim-def this property calls on/uses in the anim_cm.bin
49 = byte three = status after completion. [49] = standing, [03] = crouching, [06]/[07] = on ground face up/down, etc.
08 = byte four = hit-type [08] = stun, [09] = normal/air hit, [07] = guard, [0F] = down attack
14 = byte five = frames before you can hold. can be used to make a stun you can't hold escape. This value is usually FF for instant hold escape.
@Gultigargar
06 06 = byte six and seven are always 06 06 or 00 00, never tested anything else
00 00 = eight and nine, unsure if this is grouped this way, but byte nine is sometimes B6, which lets the property switch stance if hit by a stance dependent move.
00 00 = ten and eleven, are rotation in degrees. Rotates foe on hit. Usually see 15 00 here for slight rotation
00 = byte twelve, unsure what that does
FF = byte thirteen, juggle property, [FF] for grounded properties.
00 00 00 = byte fourteen, fifteen and sixteen = unknown. Never seen anything other than 00 00 00 here.
I made some progress with Niki's moveset - I'd say maybe 80% complete if I had to give it a number.
I still need to edit some of her throws and holds, and I'm always open to suggestions.
I used Alice's voice from the Bloody Roar series, since the quotes are generic enough to fit.
How do we feel about Niki having some of Zack's moves? I think some of the animations maybe don't quite fit, but she's sort of a goofy character like Zack, at least in DOA4 and DOAX2 - so I think it might be passable?
This has been pretty difficult, not going to lie lol - but I think it's turned out ok so far.I'm cobbling together a demo release of 2++.
I know y'all have been waiting, so I'm trying to iron out some issues before compiling stuff.
I wanted to do a proper demo release, but I don't know if that's even necessary?
I'll include command lists and such, since Sparring's command lists will no longer be accurate.
I'd love to hear what you'd like to be included, if anything?
Or should I just compile all the current files, and go?
Eventually I want to include a frame data spreadsheet for each character, but I guess that's not a priority for now.
Anyway, thanks again - and I hope you all have been well. More updates to come soon.
#-------------------------------------------------------------------------------
# Name: doa2u en/jp maximum limits extender of xpr/bin/cat/mot
#-------------------------------------------------------------------------------
#defaults: xpr=0x200000(~2mb), bin=0x18000(~95kb), cat=0xc0000(~750kb), mot=0x168000(~1.5mb)
#set sizes in bytes; (1kbb = 1024bytes)
xpr_size=0x200000
cat_size=0xc0000
bin_size=0x18000
mot_size=0x168000
doa2_xbe_path="C:\doa_folder\doa2.xbe"
test_only = False# will read and print the values, without patching
##------------------------------------------------------------------------------
xpr_offsets=[0xC8524,0xC855A,0xC8598,0xC85AE]
bin_offsets=[0xC8530,0xC8566,0xC85A2,0xC85C4]
cat_offsets=[0xC853C,0xC8572,0xC85B8,0xC85DF]
sum_offsets=[0xC854e,0xC8589,0xC858e,0xC8517]#mots are calculated in here
import os,struct
def main():
with open(doa2_xbe_path, 'r+b') as f:
for i in range(4):
patch(xpr_offsets[i], xpr_size, f)
patch(bin_offsets[i], bin_size, f)
patch(cat_offsets[i], cat_size, f)
patch(sum_offsets[i], (i+1)*(xpr_size+bin_size+cat_size+mot_size), f)
def patch(poffset, psize, pf):
pf.seek(poffset)
oldval = struct.unpack("<L", pf.read(4))[0]
print(hex(poffset),'\t0x%6x\t'%oldval, hex(psize), '!!!!!!' if oldval!=psize else '')
if not test_only:
pf.seek(poffset)
pf.write(struct.pack('<L', psize))
if __name__ == '__main__':
main()
Those values are always following a throw and related to it: 6B = distance of "throwbox" to trigger opponent's hurtboxes. 6B aka 107 in decimal (increase it and you'll get more reach).[00 00 01 00 6B 00] Unknown data, for now
I'm curious too ! I really wanna play Niki, she looks awesomeHey @usagiZ ,any news about the project?