eterniti / xv2patcher Goto Github PK

So there's a bug when using skills on cast characters that change their BCS Body ID such as Become Giant.

Manually activating and cancelling the transformation will work as expected, but being forced to detransform (losing stamina, getting hit with Fu's Remote Serious Bomb) or using the reset option in Training/Photo Mode with not correctly reset the character to default size leaving them still in the changed size.

I narrowed down this bug to the code that starts at DBXV2.exe+D4230.
Specifically:

mov esi,[rcx+000000C4]
...
cmp esi,-01
jng DBXV2.exe+D4382

mov esi,[rcx+000000C4] is loading the character default Body ID into ESI (set on match load).
later cmp esi,-01 compare the value to -1 then jumps ahead if it's not greater than that effective skipping the reset code.

My fix for this was to simple change jng DBXV2.exe+D4382 to instead be

jg DBXV2.exe+D424E
xor esi,esi

the first line simply jumps ahead to the opcode right after jng DBXV2.exe+D4382 which continues the function as intended (effetely no difference whatsoever for CaCs) and the second line clears the ESI making it 0 if it's not already at least 0, then continuing the code as if 0 was always the intended Body ID.

So in all, this fix makes all cast characters load 0 as their Default Body ID which will allow them to properly revert their size when forced to detransform.

So the game has a hard limit of what it accepts as ki blast types that can be assigned on super souls.
As of 1.21.02 this limit is 11/0xB.

The patch to remove this limit is pretty simple

<Patch name="ExtendSSKiBlastTypes" type="write" search_start="0x5D0000">
	<Instruction code="83 FB XX" comment="cmp ebx,XX (XX changes each update that adds new types. currently is 0B)" />
	<Instruction code="77 0C" comment="ja DBXV2.exe+XXXXXXXX" />
	<Instruction code="85 DB" comment="test ebx,ebx" />
	<Instruction code="74 08" comment="je DBXV2.exe+XXXXXXXX" />
	<Instruction code="81 C3 37040000" comment="add ebx,00000437" />
	<Instruction code="EB 10" comment="jmp DBXV2.exe+XXXXXXXX" />
	<Instruction code="48 8D 0D XXXXXXXX" comment="" />
	<Instruction code="8B 1C B9" comment="lea rcx,[DBXV2.exe+XXXXXXXX]" />
	<Instruction code="81 C3 38040000" comment="add ebx,00000438" />
	<Write value="83 FB 00 74 0C" />>
</Patch>

I just change the first two opcodes to be a compare for 00 and to jump if equal.
This seems to retain the default race ki blast loading (When no super soul is loaded or when ki blast type is 00) and allows for any value to be accepted as a ki blast type from a super soul.

Super soul ki blasts are loaded like so:
If the value is greater than 0, add 1079 to it then load that new value from the ID2 in the CUS ki blast section.
So as an example, if a ki blast was installed to id 3090 and I wanted to assign it as a super soul ki blast type, I would just subtract 1079 from it to find the value I should use in the super soul, in this case it would be 2011.

One important note about loading a ki blast skill this way is that they need the Race Lock value in the CUS set to accept all races. The game will refuse to let the character use the custom ki blast otherwise.

The only other thing about loading custom ki blasts this way is the ki blast type name in the menu.
The names for each type are loaded from the menu_shop_text_xx.msg and the game uses the ITEMLIST_DETAILS.iggy to define what strings to load for each ki blast type. For example Gamma Beam (Blue) is ki blast type 11/0xB and the iggy assigns it to load the string with the name ITM_STR_02_031 from the msg file mentioned earlier.
So to be able to add and customize custom ki blast type names the iggy will need to be modified to load new strings.
Another user, Atsu, provided a iggy edit that can do this if you would like to look at it
https://cdn.discordapp.com/attachments/406727448307433472/1188326711826325534/ITEMLIST_DETAILS.iggy?ex=659a1e7e&is=6587a97e&hm=7f2111818666501a39afa1061cfc601f14016c8624f82a656c05b750fd9e79cb&

The modification makes it so any ki type above the vanilla value of 11 with load the message names following this example
ITM_MODBLT_xx
Where xx = the ki blast type id.
so in the above example were we wanted to use ID 2011, the msg name we would add to the menu_shop_text msg would be ITM_MODBLT_2011.
if I wanted to use the already existing Ultra Instinct Soaring Fist Ki blast added with the UI official awoken skill, that skill is conveniently right after Gamma Beam (Blue) and would be ki blast type 12/0xC and as such would use the message name
ITM_MODBLT_12 if using the above iggy.

I hope this wasn't too confusing to follow.

Hello, good evening, I hope you are doing well, thank you very much for making the patcher, and the many tools in the Eternity Tools package.

I was wondering if it is possible to patch the limit of parallel quests like how you managed to patch the limit of stages, 192 parallel quests as a max limit is not big enough in my opinion, especially when there are a lot of parallel quests out there.

I know it's possible to just install a parallel quest, play it, uninstall it and then install another parallel quest, but it would be more convenient if the parallel quest limit was increased instead.

Thank you for reading, have a wonderful day.

So the issue here is related to modding the colorable outfits of the Custom Mentors/Partners.

It's possible to edit the outfits to allow more colorable slots, or editing the outfits to be completely different which may require a different number of colorable slots.
However if a new slot is added after any of the previous colors have been edited the color selector UI will lock up upon selecting the newly added slot. this is because the value in the save was left as FFFF, a value too high for the selection menu.

The opcode loading the clothing color values is at DBXV2.exe+0x7F6CE3
A small fix I found was just checking if the value in EAX is FFFF, then doing xor, eax,eax if so.
This results in the color selector loading the first slot to use for the color option.
Ideally it would be better for it to load the default color for the slot, but this is an easier 2nd best solution for avoiding the softlock.

This is an example of how I did a fix by modifying the opcode at DBXV2.exe+0x7F6CE3 to jump to this new bit of code.
66 3D FFFF - cmp ax,FFFF
75 02 - jne
31 C0 - xor eax,eax
48 83 C4 20 - add rsp,20
5B - pop rbx
C3 - ret

Needs to be updated to current version

So the current patcher/set of tools only allows "HAIR_" and "eye_" materials to be colorable, but I found out a while back that any material that uses BCS coloring can be changed with a transformation. "SKIN_", "PAINT_X_", the NMC/FRI "SKIN_X_", even the colorable clothing materials like "CCXX_BUST_". All that's really missing is a pointer to the name of the material prefix.
like here in this example I edited the SSBE transformation code to jump to a custom set of code I wrote to color the hair purple, skin green, and eyes white before jumping back to the original code.
https://cdn.discordapp.com/attachments/406727448307433472/953480248228446238/unknown.png
And here is another example where I edited the code for the new Beast transformation to color materials with "SKIN_A_", "SKIN_B_", "SKIN_C_" to make a concept Orange Namakian transformation.
https://cdn.discordapp.com/attachments/414271278523088896/1089245871360720926/DRAGON_BALL_XENOVERSE_2_2023-03-25_12-48-29-1.mp4
The example of the code i wrote and jumped to for that 2nd example I did as so.

--start of custom part color code 1
48 8B 8B 98 04 00 00
48 8B 01
4C 8D 0D C4 00 00 00 --pointer for SKIN_A_
BA 1A 00 00 00 --color to use (0x1A)
44 8D 42 BE
FF 90 00 04 00 00 --call coloring function

--start of custom part color code 2
48 8B 8B 98 04 00 00
48 8B 01
4C 8D 0D AC 00 00 00 --pointer for SKIN_B_
BA 1F 00 00 00 --color to use (0x1F)
44 8D 42 BE
FF 90 00 04 00 00 --call coloring function

--start of custom part color code 3
48 8B 8B 98 04 00 00
48 8B 01
4C 8D 0D 94 00 00 00 --pointer for SKIN_C_
BA 0A 00 00 00 --color to use (0x0A)
44 8D 42 BE
FF 90 00 04 00 00 --call coloring function

--start of custom part color code 4
48 8B 8B 98 04 00 00
48 8B 01
4C 8D 0D 7C 00 00 00 --pointer for eye_
BA 09 00 00 00 --color to use (0x09)
44 8D 42 BE
FF 90 00 04 00 00 --call coloring function

--Jump back to main transformation code
E9 79 E5 74 FE

I'm unsure how much work it might be to do this, but it would open up some nice new options for modding even if you only include the ability for the body material types excluding clothing.

So recently I found that I can make the game load more Entry 0 EEPKs in battle and use them for character auras.
All addresses are with the latest xv2 update exe.

This section of code controls what EEPKs to load in battle from the vfx_spec.ers (normally only the ones with IDs 0,1,2,and 6) by testing again esi which is set to value 0x47.

DBXV2.exe+150602 - 85 DE - test esi,ebx
DBXV2.exe+150604 - 74 20 - je DBXV2.exe+150626
DBXV2.exe+150606 - C7 44 24 28 01000000 - mov [rsp+28],00000001
DBXV2.exe+15060E - C7 44 24 20 01000000 - mov [rsp+20],00000001
DBXV2.exe+150616 - 45 33 C9 - xor r9d,r9d
DBXV2.exe+150619 - 44 8B C7 - mov r8d,edi
DBXV2.exe+15061C - 33 D2 - xor edx,edx
DBXV2.exe+15061E - 48 8B CD - mov rcx,rbp
DBXV2.exe+150621 - E8 BAF06F00 - call DBXV2.exe+84F6E0
DBXV2.exe+150626 - FF C7 - inc edi
DBXV2.exe+150628 - D1 C3 - rol ebx,1
DBXV2.exe+15062A - 83 FF 07 - cmp edi,07
DBXV2.exe+15062D - 7C D3 - jl DBXV2.exe+150602

One method to expand this would just be to nop the instruction at DBXV2.exe+150604 which would make the game load every eepk defined in the Entry 0 section of the vfx_spec.ers.

In my experimentation I added more code past instruction at DBXV2.exe+15062D like so

mov edi,00000050
mov [rsp+28],00000001
mov [rsp+20],00000001
xor r9d,r9d
mov r8d,edi
xor edx,edx
mov rcx,rbp
call DBXV2.exe+84F6E0
inc edi
cmp edi,5B
jl DBXV2.exe+1967A5E
jmp DBXV2.exe+15062F

I set edi to 0x50 and do the normal set of instructions but without the testing against esi, only continuing to the mormal code set once edi becomes 0x5B.
What this accomplishes is loading the normal set of EEPKS in battle (0, 1, 2, and 6) in addition to EEPKS with IDs 80-89.

The second part that makes this work is giving the game the ability to use a different EEPKs for auras in the first place.
By default it is hard set to use the EEPK with ID 1 for Aura's (BTL_AURA.eepk) and the code that handles it is here

DBXV2.exe+EBEAD - 39 43 0C - cmp [rbx+0C],eax
DBXV2.exe+EBEB0 - 75 1C - jne DBXV2.exe+EBECE
DBXV2.exe+EBEB2 - B8 10000000 - mov eax,00000010
DBXV2.exe+EBEB7 - 66 89 84 24 88000000 - mov [rsp+00000088],ax
DBXV2.exe+EBEBF - 48 8B 03 - mov rax,[rbx]
DBXV2.exe+EBEC2 - 8B 48 44 - mov ecx,[rax+44]
DBXV2.exe+EBEC5 - FF C1 - inc ecx
DBXV2.exe+EBEC7 - 89 8C 24 94000000 - mov [rsp+00000094],ecx
DBXV2.exe+EBECE - 45 33 C0 - xor r8d,r8d
DBXV2.exe+EBED1 - 48 8D 54 24 40 - lea rdx,[rsp+40]
DBXV2.exe+EBED6 - 41 B9 01000000 - mov r9d,00000001
DBXV2.exe+EBEDC - 48 8B CF - mov rcx,rdi
DBXV2.exe+EBEDF - 85 F6 - test esi,esi
DBXV2.exe+EBEE1 - 74 07 - je DBXV2.exe+EBEEA

The instruction at DBXV2.exe+EBED6 setting r9d to 1 is what controls the EEPK to use for effect Ids read form the Aura_setting.aur file.
To get around and expand this I make use of a code cave and an unused int in the aura_setting.aur file.
I replace the instruction at DBXV2.exe+EBEB2 to jump to my code cave with this code

DBXV2.exe+1967A8A - 3B 43 0C - cmp eax,[rbx+0C]
DBXV2.exe+1967A8D - 74 0A - je DBXV2.exe+1967A99
DBXV2.exe+1967A8F - B8 10000000 - mov eax,00000010
DBXV2.exe+1967A94 - E9 1E4478FE - jmp DBXV2.exe+EBEB7
DBXV2.exe+1967A99 - 50 - push rax
DBXV2.exe+1967A9A - 51 - push rcx
DBXV2.exe+1967A9B - 52 - push rdx
DBXV2.exe+1967A9C - 48 31 D2 - xor rdx,rdx
DBXV2.exe+1967A9F - 8B 51 0C - mov edx,[rcx+0C]
DBXV2.exe+1967AA2 - 48 6B C0 10 - imul rax,rax,10
DBXV2.exe+1967AA6 - 48 01 D1 - add rcx,rdx
DBXV2.exe+1967AA9 - 48 01 C1 - add rcx,rax
DBXV2.exe+1967AAC - 81 79 04 00000000 - cmp [rcx+04],00000000
DBXV2.exe+1967AB3 - 75 05 - jne DBXV2.exe+1967ABA
DBXV2.exe+1967AB5 - 5A - pop rdx
DBXV2.exe+1967AB6 - 59 - pop rcx
DBXV2.exe+1967AB7 - 58 - pop rax
DBXV2.exe+1967AB8 - EB D5 - jmp DBXV2.exe+1967A8F
DBXV2.exe+1967ABA - 44 8B 49 04 - mov r9d,[rcx+04]
DBXV2.exe+1967ABE - 5A - pop rdx
DBXV2.exe+1967ABF - 59 - pop rcx
DBXV2.exe+1967AC0 - 58 - pop rax
DBXV2.exe+1967AC1 - B8 10000000 - mov eax,00000010
DBXV2.exe+1967AC6 - 66 89 84 24 88000000 - mov [rsp+00000088],ax
DBXV2.exe+1967ACE - 48 8B 03 - mov rax,[rbx]
DBXV2.exe+1967AD1 - 8B 48 44 - mov ecx,[rax+44]
DBXV2.exe+1967AD4 - FF C1 - inc ecx
DBXV2.exe+1967AD6 - 89 8C 24 94000000 - mov [rsp+00000094],ecx
DBXV2.exe+1967ADD - 45 31 C0 - xor r8d,r8d
DBXV2.exe+1967AE0 - 48 8D 54 24 40 - lea rdx,[rsp+40]
DBXV2.exe+1967AE5 - E9 F24378FE - jmp DBXV2.exe+EBEDC

So the basics of what this does is that while checking the aura_setting.aur file normally for the aura Ids, I also check the unused 4 bytes after the Aura id (genser lables this as "unknow_0") and use it as the ID for which EEPK to use for the effect IDs defined in the aura entry. If it's 0 then it will load the normal BTL_AURA.eepk, otherwise if it is any greater number then it'll load the Type 0 EEPK with that ID.

I've done some light testing and things seems to be well with no obvious bugs or errors. In my tests i use EEPKs with IDs 80-89 for this but that can be expanded or changed to be any number. i just thought an addition 10 was a good testing point.
it's also good to note that the game doesn't hang if not all of those EEPKs are defined.
I've seen every now again that users have trouble with aura mods because of the limited space available in the BTL_AURA.eepk to add effects to which grows worse each update. the devs may at some point create a BTL_AURA2.eepk if things continue, but i think giving users the ability to use far more than 1 or 2 EEPKs for aura is good.

Hello,

When attempting to use xv2patcher 3.711 with either the xinput1_3.dll or dinput8.dll on a Steam Deck, the game loads as normal without the patcher string at the bottom right of the title screen. The patch never injects even though it's running through the Proton environment as a Windows executable.

I see in main.cpp there's a lot of print statements, so if there's a way to get those logged/shown I can submit a log to help. But I also notice the Epatches have hard coded addresses that may be different now with the executable being ran through Proton?

Is it possible to get this patcher functioning through Proton so that installed x2m mods can be loaded? I can assist with any debugging you may need to proceed with.

Thanks.