Although it was a fairly smooth few hours of gameplay, a number of issues did pop up that required some fixing off-stream. I’ll be documenting those fixes in this article, and I feel this Omnified game is definitely going to be very enjoyable and playable following these fixes. What I’m doing here will more or less be a process template for future Omnified hackings: initial Omnification articles will be written while I’m hacking the game, with a follow up post-playtest article published containing any critical fixes.<\/p>\n\n\n\n
I’ll be going over all critical problems encountered with a link to the original article the particular hack in question was written in and then how I went about fixing it. Any other changes or fixes to the game in the future will get an individual article if notable enough!<\/p>\n\n\n\n
I. Shifting Character Modules Issue<\/h2>\n\n\n\n
In the first hacking Dark Souls III article<\/a> on data structure analysis, we charted out the contents of the player’s root structure, including how we can find the SprjChrDataModule<\/strong> (which contains the player’s vitals) and the SprjChrPhysicsModule<\/strong><\/strong> (which contains the player’s coordinates) inside of it. The player hook was further updated in the follow-up article<\/a> I wrote on Dark Soul III’s Apocalypse implementation.<\/p>\n\n\n\n We found that the these data and physics modules could be found at offsets 0x23D8 <\/strong>and 0x2428<\/strong> respectively. It was assumed, at the time of writing, that these offsets were static and wouldn’t change — this is a reasonable assumption to make. However, during the stream, I noticed that the location of these modules inside the root structure would randomly shift around. Sometimes the physics module would be found at 0x2408<\/strong>, sometimes it would be found at 0x2218<\/strong>, etc.<\/p>\n\n\n\n Anyway, adding support for all the various places the modules could<\/em> show up would be foolish, as there’s no guarantee there wouldn’t be any more places to add support for later on; it clearly isn’t how the data types were designed to be interacted with.<\/p>\n\n\n\n What I did was look for code that was accessing the various modules inside<\/em> the root structure, and tried to determine how the game code itself went about finding these modules. Eventually I stumbled on code that revealed the use of a module collection<\/em> pointer, also found on the root structure, and located at the offset 0x1F90<\/strong>. This pointer points to the starting address of all the modules for that character, and the collection pointer is indeed static.<\/p>\n\n\n\n I realized that this pointer was our golden ticket right away, as I previously saw a similar practice being followed in Sekiro’s code, which shares many similarities with Dark Souls III.<\/p>\n\n\n\n Armed with a more reliable way to map our player data, the player hook has been updated to the following code:<\/p>\n\n\n\n In the Dark Souls III Abomnification implementation article<\/a>, we found a place we thought suitable in memory to hold creatures’ morphing scale IDs. Specifically, we chose the offset 0x39C<\/strong> inside the SprjCharPhysicsModule<\/strong> to be the home for the creature’s ID.<\/p>\n\n\n\n While this seemed to be OK at the time, it was found to actually be unreliable during the playtest. A new and easier to find place was designated as the home for the morph scale ID: offset 0x1194<\/strong> in the PlayerIns<\/strong> and EnemyIns<\/strong> root structures.<\/p>\n\n\n\n There were also difficulties in retrieving the EnemyIns<\/strong> structure while executing inside our Abomnification application code (where our custom scaling occurs). We previously identified a reliable way for retrieving it to be by dereferencing the r12<\/strong> register and looking at offset 0x58.<\/strong> However, this caused a number of Abomnifications to fail, and it was discovered we needed to also add support for looking at the 0x68<\/strong> offset as well, as the EnemyIns<\/strong> could also appear there.<\/p>\n\n\n\n Here is the updated code for the Abomnification initiation point hook using the new morph scale index location.<\/p>\n\n\n\n The initiation point now grabs the EnemyIns<\/strong> structure from the physics module, and uses the new offset instead. This new one works great!<\/p>\n\n\n\n Here is the updated code for the Abomnification application hook:<\/p>\n\n\n\n Another issue with the Abomnification system that I observed was that most humanoid NPCs were failing to morph at all, as well as more complicated armors worn by them. This was no good! Everything needs to be Abomnified!<\/p>\n\n\n\n I determined that our current Abomnification application hook was successfully applying scaling to all incoming rendering requests. That meant that there was another function in code purposed to handle the rendering of humanoid NPC models and their outfits. I located this code by putting on an outfit that had a nice wavy cloak, and then repeating the steps I followed in the Abomnification implementation article for Dark Souls III<\/a> to find the original Abomnification application hook location.<\/p>\n\n\n\n Eventually I found a matrix multiplication routine at “DarkSoulsIII.exe”+C2FBCE<\/strong>, and implemented another Abomnification application hook there, basically identical to the original one.<\/p>\n\n\n\n After wiring it up (and enabling it to work on the player character temporarily) I was super <\/em>thrilled to see that the player’s cloak was actually morphing! This was a big deal because, although I’d been able to get more and more parts of the models morphing with each game I’ve done, I’ve never been able to get long wavy cloaks and dresses in FromSoftware games to morph.<\/p>\n\n\n\n Unfortunately, the hook has no effect (from what I’ve seen) on enemy dresses. Cloaks and complicated armor do appear to be working now however. As well as faces and weapons, which were not previously. All in all, I think we’re good here. Game is way more streamable now for me.<\/p>\n\n\n\n Here is the new Abomnification application hook for human NPC body types:<\/p>\n\n\n\n Like Sekiro, Dark Souls III has a sensitive movement system that experiences a type of “resonance” when manipulated from the outside, resulting in enemies phasing out of existence if boosted a bit.<\/p>\n\n\n\n 99% of movement anomalies appear to have been resolved by tuning some of the Predator system’s external parameters to the following values:<\/p>\n\n\n\n For an explanation as to what these parameters mean, and what the significance of the new values might be, you’ll need to consult the Predator general overview article, which is unfortunately not available yet! I’ll put a link here when it is.<\/p>\n\n\n\n Alright! With these fixes, the game is damn well ready for showtime. Hacking Dark Souls III and getting it Omnified (and writing about it all on this site) has been a great experience, and with this fixes the game is ready to play. Really looking forward to it. And I hope to see you there! I’ll be streaming it most days on my stream at: https:\/\/twitch.tv\/omni<\/a>. <\/p>\n\n\n\n![\"After](\"https:\/\/badecho.com\/wp-content\/uploads\/2020\/10\/playtestFixesShifting.png\")
Player Hook With Shifting Module Support<\/h3>\n\n\n
\n\/\/ Gets the player's root, coordinates, and vitals structs.\n\/\/ rcx: Address of player's root struct.\ndefine(omniPlayerHook, "DarkSoulsIII.exe" + C1A78C)\n\nassert(omniPlayerHook, 48 8B 01 FF 90 C0 02 00 00)\nalloc(getPlayer,$1000, omniPlayerHook)\nalloc(player,8)\nalloc(playerCoords,8)\nalloc(playerVitals,8)\n\nregistersymbol(omniPlayerHook)\nregistersymbol(player)\nregistersymbol(playerCoords)\nregistersymbol(playerVitals)\n\ngetPlayer:\n push rbx\n push rcx\n push rdx\n mov rbx,player\n mov [rbx],rcx \n mov rdx,[rcx+1F90]\n mov rcx,rdx\n mov rdx,[rcx+68]\n mov rbx,playerCoords\n mov [rbx],rdx\n mov rdx,[rcx+18]\n mov rbx,playerVitals\n mov [rbx],rdx\n pop rdx\n pop rcx\n pop rbx\ngetPlayerOriginalCode:\n mov rax,[rcx]\n call qword ptr [rax+000002C0]\n jmp getPlayerReturn\n\n\nomniPlayerHook:\n jmp getPlayer\n nop 4\ngetPlayerReturn:\n<\/pre>\n\n\n
II. Unreliable Morphing Scale ID Location<\/h2>\n\n\n\n
Updated Abomnification Initiation Hook<\/h3>\n\n\n
\n\/\/ Initiates the Abomnification system, generating new scaling parameters\n\/\/ for a creature. \n\/\/ rbx: Target physics module.\ndefine(omnifyAbomnificationHook,"DarkSoulsIII.exe"+9D2360)\n\nassert(omnifyAbomnificationHook,66 0F 7F B3 80 00 00 00)\nalloc(initiateAbomnification,$1000,omnifyAbomnificationHook)\n\nregistersymbol(omnifyAbomnificationHook)\n\ninitiateAbomnification:\n pushf\n \/\/ Ensure that the player coordinates pointer has been initialized.\n push rax\n mov rax,playerCoords\n cmp [rax],0\n pop rax\n je initiateAbomnificationOriginalCode\n \/\/ Ensure that the we aren't about the Abomnify the player.\n push rax\n mov rax,playerCoords\n cmp rbx,[rax]\n pop rax\n je initiateAbomnificationOriginalCode\n \/\/ Load the address to the morph scale ID and then call the Abomnification\n \/\/ system.\n push rax\n push rcx\n \/\/ The root structure can be found here on the physics\n \/\/ module.\n mov rcx,[rbx+8]\n lea rax,[rcx+1194]\n pop rcx\n push rax\n call executeAbomnification\n pop rax\ninitiateAbomnificationOriginalCode:\n popf\n movdqa [rbx+00000080],xmm6\n jmp initiateAbomnificationReturn\n\nomnifyAbomnificationHook:\n jmp initiateAbomnification\n nop 3\ninitiateAbomnificationReturn:\n<\/pre>\n\n\n
Updated Abomnification Application Hook<\/h3>\n\n\n
\n\/\/ Applies the Abomnification system.\n\/\/ [rax]: Width matrix values \n\/\/ [rax+10]: Height matrix values\n\/\/ [rax+20]: Depth matrix values\ndefine(omnifyApplyAbomnificationHook, "DarkSoulsIII.exe" + D279FC)\n\nassert(omnifyApplyAbomnificationHook, 0F 28 00 4B 8D 14 76)\nalloc(applyAbomnification,$1000, omnifyApplyAbomnificationHook)\nalloc(abomnifyPlayer,8)\nalloc(disableAbomnify,8)\nalloc(skipTypeCheck,8)\n\nregistersymbol(omnifyApplyAbomnificationHook)\nregistersymbol(abomnifyPlayer)\nregistersymbol(disableAbomnify)\nregistersymbol(skipTypeCheck)\n\napplyAbomnification:\n pushf\n cmp [disableAbomnify],1\n je applyAbomnificationOriginalCode\n \/\/ Ensure that the player root structure pointer has been initialized.\n push rax\n mov rax,player\n cmp [rax],0\n pop rax\n je applyAbomnificationOriginalCode\n \/\/ Backing up a few registers we'll be using to perform calculations\n \/\/ on the original matrix values with updated scaling parameters.\n sub rsp,10\n movdqu [rsp],xmm0\n sub rsp,10\n movdqu [rsp],xmm1\n push rbx\n push rcx\n \/\/ We take a look at the address stored at the place we expect to\n \/\/ find the enemy root structure, and see if it is a valid pointer.\n mov rbx,[r12+58]\n lea rcx,[rbx]\n call checkBadPointer\n cmp ecx,0\n je checkAbomnifyType\n \/\/ The root structure sometimes appears at 0x68 instead.\n mov rbx,[r12+68]\n lea rcx,[rbx]\n call checkBadPointer\n cmp ecx,0\n jne applyAbomnificationExit\n \/\/ We do another check to ensure that it isn't a humanoid model.\n \/\/ Human scaling is done in the applyAbomnificationHuman hook.\ncheckAbomnifyType:\n cmp [skipTypeCheck],1\n je checkAbomnifyPlayer\n push rax\n mov rax,[rbx] \n cmp ax,0x3EB8\n pop rax\n jne applyAbomnificationExit\n \/\/ We then further check to see if the root structure address differs\n \/\/ from the player's own root structure.\ncheckAbomnifyPlayer:\n cmp [abomnifyPlayer],1\n je loadScaleData\n mov rcx,player\n cmp rbx,[rcx]\n je applyAbomnificationExit \nloadScaleData:\n \/\/ Now that we know our data is good, we want to check if a morph scale\n \/\/ ID has actually been assigned yet by the Abomnification system.\n mov rcx,[rbx+1194]\n cmp rcx,0\n je applyAbomnificationExit\n \/\/ This should never happen, but we want to ensure we aren't going to access\n \/\/ memory beyond the allocated bounds of our sandbox region.\n cmp ecx,#999\n ja applyAbomnificationExit\n \/\/ Each creature has morph scale data that takes up a total of 48 bytes.\n \/\/ So we want to multiply the size of each section by our ID to get the\n \/\/ offset to apply to our base morphScaleData, which will give us the\n \/\/ location to our creature-specific morph scale data.\n push rax\n push rdx\n mov rax,rcx\n mov rcx,#48\n mul rcx\n mov ecx,eax\n pop rdx\n pop rax\n mov rbx,morphScaleData\n add rbx,rcx\napplyAbomnificationScaleAdjustment:\n \/\/ We want to then do one final check to ensure that some sort of morph\n \/\/ scale data has actually been initialized for the creature.\n lea rcx,[rbx+4]\n call checkBadPointer\n cmp ecx,0\n jne applyAbomnificationExit\n mov rcx,[rbx+4]\n cmp rcx,0\n je applyAbomnificationExit\n \/\/ We load the scaling parameter for the creature's width, and then multiply\n \/\/ the live width matrix values by it.\n movss xmm0,[rbx+4]\n shufps xmm0,xmm0,0\n movdqu xmm1,[rax]\n mulps xmm1,xmm0\n movdqu [rax],xmm1\n \/\/ We load the scaling parameter for the creature's height, and then multiply\n \/\/ the live height matrix values by it.\n movss xmm0,[rbx+8]\n shufps xmm0,xmm0,0\n movdqu xmm1,[rax+10]\n mulps xmm1,xmm0\n movdqu [rax+10],xmm1\n \/\/ We load the scaling parameter for the creature's depth, and then multiply\n \/\/ the live depth matrix values by it.\n movss xmm0,[rbx+C]\n shufps xmm0,xmm0,0\n movdqu xmm1,[rax+20]\n mulps xmm1,xmm0\n movdqu [rax+20],xmm1 \napplyAbomnificationExit:\n \/\/ Restore backed up values.\n pop rcx\n pop rbx\n movdqu xmm1,[rsp]\n add rsp,10\n movdqu xmm0,[rsp]\n add rsp,10\napplyAbomnificationOriginalCode:\n popf\n movaps xmm0,[rax]\n lea rdx,[r14+r14*2]\n jmp applyAbomnificationReturn\n\n\nomnifyApplyAbomnificationHook:\n jmp applyAbomnification\n nop 2\napplyAbomnificationReturn:\n<\/pre>\n\n\n
III. Humanoid Bodies and Armor Not Morphing<\/h2>\n\n\n\n
Humanoid\/Clothing Abomnification Application Hook<\/h3>\n\n\n
\n\/\/ Applies the Abomnification for humans. \ndefine(omnifyApplyAbomnificationHumanHook, "DarkSoulsIII.exe" + C2FBCE)\n\nassert(omnifyApplyAbomnificationHumanHook, 0F 28 00 4B 8D 0C 76)\nalloc(applyAbomnificationHuman,$1000, omnifyApplyAbomnificationHumanHook)\nalloc(disableAbomnifyHuman,8)\n\nregistersymbol(omnifyApplyAbomnificationHumanHook)\nregistersymbol(disableAbomnifyHuman)\n\napplyAbomnificationHuman:\n pushf \n cmp [disableAbomnifyHuman],1\n je applyAbomnificationHumanOriginalCode\n \/\/ Ensure that the player root structure pointer has been initialized.\n push rax\n mov rax,player\n cmp [rax],0\n pop rax\n je applyAbomnificationHumanOriginalCode\n \/\/ Backing up a few registers we'll be using to perform calculations\n \/\/ on the original matrix values with updated scaling parameters.\n sub rsp,10\n movdqu [rsp],xmm0\n sub rsp,10\n movdqu [rsp],xmm1\n push rbx\n push rcx\n \/\/ We take a look at the address stored at the place we expect to\n \/\/ find the enemy root structure, and see if it is a valid pointer.\n mov rbx,[rsp+162]\n lea rcx,[rbx]\n call checkBadPointer\n cmp ecx,0\n jne applyAbomnificationHumanExit \n \/\/ We then further check to see if the root structure address differs\n \/\/ from the player's own root structure.\n cmp [abomnifyPlayer],1\n je loadScaleHumanData\n mov rcx,player\n cmp rbx,[rcx]\n je applyAbomnificationHumanExit \nloadScaleHumanData:\n \/\/ Now that we know our data is good, we want to check if a morph scale\n \/\/ ID has actually been assigned yet by the Abomnification system.\n mov rcx,[rbx+1194]\n cmp rcx,0\n je applyAbomnificationHumanExit\n \/\/ This should never happen, but we want to ensure we aren't going to access\n \/\/ memory beyond the allocated bounds of our sandbox region.\n cmp ecx,#999\n ja applyAbomnificationHumanExit\n \/\/ Each creature has morph scale data that takes up a total of 48 bytes.\n \/\/ So we want to multiply the size of each section by our ID to get the\n \/\/ offset to apply to our base morphScaleData, which will give us the\n \/\/ location to our creature-specific morph scale data.\n push rax\n push rdx\n mov rax,rcx\n mov rcx,#48\n mul rcx\n mov ecx,eax\n pop rdx\n pop rax\n mov rbx,morphScaleData\n add rbx,rcx\napplyAbomnificationHumanScaleAdjustment:\n \/\/ We want to then do one final check to ensure that some sort of morph\n \/\/ scale data has actually been initialized for the creature.\n lea rcx,[rbx+4]\n call checkBadPointer\n cmp ecx,0\n jne applyAbomnificationHumanExit\n mov rcx,[rbx+4]\n cmp rcx,0\n je applyAbomnificationHumanExit\n \/\/ We load the scaling parameter for the creature's width, and then multiply\n \/\/ the live width matrix values by it.\n movss xmm0,[rbx+4]\n shufps xmm0,xmm0,0\n movdqu xmm1,[rax]\n mulps xmm1,xmm0\n movdqu [rax],xmm1\n \/\/ We load the scaling parameter for the creature's height, and then multiply\n \/\/ the live height matrix values by it.\n movss xmm0,[rbx+8]\n shufps xmm0,xmm0,0\n movdqu xmm1,[rax+10]\n mulps xmm1,xmm0\n movdqu [rax+10],xmm1\n \/\/ We load the scaling parameter for the creature's depth, and then multiply\n \/\/ the live depth matrix values by it.\n movss xmm0,[rbx+C]\n shufps xmm0,xmm0,0\n movdqu xmm1,[rax+20]\n mulps xmm1,xmm0\n movdqu [rax+20],xmm1 \napplyAbomnificationHumanExit:\n \/\/ Restore backed up values.\n pop rcx\n pop rbx\n movdqu xmm1,[rsp]\n add rsp,10\n movdqu xmm0,[rsp]\n add rsp,10\napplyAbomnificationHumanOriginalCode:\n popf\n movaps xmm0,[rax]\n lea rcx,[r14+r14*2]\n jmp applyAbomnificationHumanReturn\n\n\nomnifyApplyAbomnificationHumanHook:\n jmp applyAbomnificationHuman\n nop 2\napplyAbomnificationHumanReturn:\n<\/pre>\n\n\n
IV. Predator Parameter Optimization<\/h2>\n\n\n\n
Ready to Get This Game On<\/h2>\n\n\n\n