-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discrepancy between hard-coded file & in-memory patching #220
Comments
If the texture problem is from mdata, try running with -avsverbose to see if it's even opening the correct file (the 0x61 -> 0x6F patch should change mdata.ifs to mdato.ifs?) |
This doesn't sound like a mem patch issue, more like you missed a patch that is needed to make Omni work, as pointed out above. If you can narrow it down to a single patch & can prove that it's not being applied (such as via the memory overlay or under a debugger) feel free to respond back. |
The patch is the aforementioned As for the in-memory version of that patch, it appears that it is being applied: After stepping over the More confirmation of the altered filename in-game, despite the still present visual issues.
With the pre-patched file, it opens
However, with the in-memory patch applied it still opens the original file instead:
Curiously, further down the log it does open Looking in IDA, ...and as far as I can tell, spice2x is definitely applying the patches correctly; it's just an issue of timing. I can't think of any good ways of addressing this as it's already too late as soon as Oh well. At least it's good to know that static patches in a file don't necessarily translate 1:1 when expressed as memory patches. Unfortunately, altering that one patch doesn't work either, as the offset of the copy exceeds the file size. |
Thank you for looking into this deeper. Maybe it's time to split it off as a hook DLL+layeredfs? Spicetools patching, mempatch-hook and layeredfs have been around for many years now and they don't seem to be in a rush to move from the "use bm2dx_omni.dll with mystery patches and pollute your game data folder" model... while other projects seem to have embraced all of the tool upgrades since 2013. Bonus: |
Exact same issue happening with people now creating Epolis' omnimix and mdata.ifs. Hard-patching the DLL does work, memory patching doesn't. |
Here's a potential workaround that attempts to use LdrRegisterDllNotification to apply changes a bit earlier. It was introduced in Vista, so I left the original code to apply patches after loading the game DLL alone. Tested by building with Docker and comparing behaviour against the latest 24-10-12 binaries while using the same patches and configuration. Confirmed the Omnimix texture issue is no longer present. Also lightly tested with a couple of 32-bit IIDX games to ensure it works there as well, although I'm not aware of any patches that exhibit the same issue. log.txt (24-10-12)
log.txt (with patch)
|
I've merged aixxe's patch above, will do a release soon. One tricky situation that we need to explain is that for patches that were previously no-op can now be working - for example, if someone does not actually have omnimix installed but has Omnimix patch checked, the game would have booted previously, but now it will crash. |
Game and version
beatmania IIDX 30 RESIDENT - LDJ-003-2023090500
Version of spice2x
1.0-V-2024-08-24T00:53:46
Laptop
Replicated on both desktop & laptop
Describe the issue
After isolating the differences between the original
bm2dx.dll
and thebm2dx_omni.dll
from Omnimix v1.30.1 into a spice2x patch, I've noticed some texture issues in music select when playing certain songs (e.g. Scripted Connection⇒ long mix)Attached log.txt file, if available
log_file.txt
log_memory.txt
The text was updated successfully, but these errors were encountered: