[DOA2++] Moveset Editing Project

usagiZ

Well-Known Member
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
89sG8Oe.jpg


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
EZC1h4o.jpg


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.
ZmftCaY.jpg

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.
SjpsF6e.jpg

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 = :4::6::T: 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.
sIgEDpB.jpg


This section always terminates with FF 00 FF FF
ifmPKgb.gif
vlEoi94.jpg

Highlighted is:
01 00 = Tina
38 01 = :4::6::T: in Tina's character.bin

This section terminates with FF 00 FF FF
2U's Stage Select List:
0IHpjUF.jpg

Each entry in DOA2U is 0x18 bytes long
P9h5eVr.jpg

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.
o2vs1le.jpg
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.

ZD4Sk4n.jpg

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
RzrmllM.jpg
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.
 

CoYoTe

Active Member
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
89sG8Oe.jpg


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
EZC1h4o.jpg


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.
ZmftCaY.jpg

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.
SjpsF6e.jpg

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 = :4::6::T: 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.
sIgEDpB.jpg


This section always terminates with FF 00 FF FF
ifmPKgb.gif
vlEoi94.jpg

Highlighted is:
01 00 = Tina
38 01 = :4::6::T: in Tina's character.bin

This section terminates with FF 00 FF FF
2U's Stage Select List:
0IHpjUF.jpg

Each entry in DOA2U is 0x18 bytes long
P9h5eVr.jpg

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.
o2vs1le.jpg
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.

ZD4Sk4n.jpg

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
RzrmllM.jpg
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.
UsagiZ,welcome back my friend
I've read your post and I'm very amazed.
Btw if you post your costumes in my DOA2 costume thread It will be great
However it's good that you are back.
 

Gultigargar

Well-Known Member
Very nice and informative, thank you for sharing.

Oh, so *that's* where the unholdable stun frames were. Knew about those sections, just didn't know what that particular byte was. Nice.
 
Last edited:

Derock

Well-Known Member
Niki looks awesome! You can mess around by giving her some of Zack's holds and throws, or some old throws from 1, if any. But anyways, great job and welcome back!
 

CursedFaith

New Member
I saw your Niki video and she looks amazing ! I'd love to try her out whenever the demo comes out. Great work ^-^
 
Last edited:

CursedFaith

New Member
I have a question : if everything goes as planned, do you think the demo will be released before the end of summer ? Sorry, I know these types of questions can be very annoying but I'm an annoying person so I can't hold it back ><
 

Forlorn Penguin

Well-Known Member
Premium Donor
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
89sG8Oe.jpg


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
EZC1h4o.jpg


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.
ZmftCaY.jpg

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.
SjpsF6e.jpg

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 = :4::6::T: 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.
sIgEDpB.jpg


This section always terminates with FF 00 FF FF
ifmPKgb.gif
vlEoi94.jpg

Highlighted is:
01 00 = Tina
38 01 = :4::6::T: in Tina's character.bin

This section terminates with FF 00 FF FF
2U's Stage Select List:
0IHpjUF.jpg

Each entry in DOA2U is 0x18 bytes long
P9h5eVr.jpg

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.
o2vs1le.jpg
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.

ZD4Sk4n.jpg

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
RzrmllM.jpg
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.
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.

The game is allocating space for 4 virtual players. Here is the python script for changing size limits for xpr/bin/cat/mot files. I think you can understand how it works from looking at the code.
Python:
#-------------------------------------------------------------------------------
# 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()
 
Last edited:

Sindor

New Member
[00 00 01 00 6B 00] Unknown data, for now
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).
Others values I still don't know yet.
 

usagiZ

Well-Known Member
Hey everyone, it's been a while -- my usual greeting these days
Anyway, I'm making a serious effort to get a demo together, since it looks like most of the freezing issues I'd been having are most likely caused by my costume edits -- so, I'll probably release the future demo with the original costumes, and include an optional costume pack.

Here's a combo video to show the mod's progress:

I've revised some of her throws, and added in some combo throws to make her seem more unique:
If you're familiar with DOA's Animations, you'll probably recognize a few of these.
4T.gif

4T-44T.gif
214T-Revision.gif
1T-Revision.gif
7H-Revision.gif

7H-ComboHold.gif
@mopafo3971
Thanks for posting your info on the file size limit, and basically all the other work you've done for doa modding so far.


Anyway, I'll be posting a little more very soon.
Also posting my costume tutorial stuff as soon as I figure out which topic/thread to post it in :/

Thanks again for sticking around!
 
ALL DOA6 DOA5 DOA4 DOA3 DOA2U DOAD
Top