Gi Nattak - 7/21/2021 10:02 PM
ah, no it
shouldn't, the monsters will appear normal in-game. it's just that FF3SE-M will relocate the monster graphics, so FF3usME won't be able to display them correctly any more.
AyameMitsuno1999 - 7/21/2021 10:05 PM
So it possibly FF3usMe will update to see monsters expansion from FF3SE-M?!
CDude - 7/21/2021 10:10 PM
FF3usME is not longer being actively developed and it was never open-sourced, so it's unlikely that it'll ever be set up in a way that can display those additional monster graphics. Somebody recommended setting up several versions of a ROM with expanded monsters, so that they could determine screen positions for formations with the actual graphics and then hand-transfer that data into their master file. I'd say that's the approach to take.
Divine Whiz - 7/21/2021 10:53 PM
honestly me is fine for what it is
yes it could have some updates but i think it does its job
Serity - 7/21/2021 10:55 PM
animation script editor, and the ability to custom load rom offsets from file~
CDude - 7/21/2021 10:56 PM
Yeah, something that would let the user define offsets would be enormous, but somebody would have to crack USME open, disassemble it, and then reassemble it in order to add something like that.
Serity - 7/21/2021 11:00 PM
could at least make a script that makes an ips patch for ff3usme lol
CDude - 7/21/2021 11:01 PM
LOL patching the utility is a funny idea. This is FF3USME, Bob's Hack version! That might work if we knew where those address definitions were in the program.
Serity - 7/21/2021 11:03 PM
C46AC0 is spell data, at 3D02F in the program is
C0 6A 04
:d
CDude - 7/21/2021 11:04 PM
And that's the only address that has that value?
Serity - 7/21/2021 11:05 PM
of course lol but i cant promise it'll work offhand
i spent a whole 2 seconds glancing at it
in fact it might be probable that that's not actually data
:d
it was just a thought anyways
CDude - 7/21/2021 11:10 PM
It's an interesting thought. I don't have time to play with it right now (and it's a scary prospect, because it wouldn't be crashing in the safety of an emulator), but if that approach works [a little-endian search for the file pointer] then that would be huge, especially with expanded monster graphics.
Serity - 7/21/2021 11:12 PM
4298bb: mov edx, 0x46cc0
, on a headered from it's at 46CC0 hmm
(and also
429914: mov edx, 0x46cc0
)
428496: mov edx, 0x47cc0
4288b4: mov ecx, 0x47cc0
shop data?
426d83: mov edx, 0x47ac0
426f96: mov edx, 0x47ac0
(478C0, character names)
428570: mov eax, 0xefda0
428980: mov eax, 0xefda0
rare item names (the offsets i'm listing (on the left before the : ) are off by 0x400C00 vs the actual file for... whatever reason)
i'm assuming one is for reading and one is for writing
CDude - 7/21/2021 11:18 PM
So it handles headered and unheadered addresses separately?
Serity - 7/21/2021 11:18 PM
shortly after the char names there's a 'push 6' and shortly after the rare item names there's a 'push D (13)' so that lines up too
nah it treats everything as headered
e.g. 'read from 0xEFDA0' --> save --> 'write to 0xEFDA0' (headered)
just ctrl-f around in the hex for [offset] - 0xC00000 + 0x200, but backwards coz that's how hex stores integers
Code:
CEFCB0 = rare item descriptions unk length
- C00000 = EFCB0 [actual rom file offset]
+ 200 = EFEB0 [add header... (even if ur rom is unheadered, make sure it has extra 200 from base offset)]
backwards = B0 FE 0E [just reverse byte order, not entire thing backwards]
ctrl-f for B0 FE 0E
two values: @ .exe 279FA and @ .exe 27E04
there should only be two results :d
it actually stores the offsets as four bytes so
B0 FE 0E 00
would be safer
CDude - 7/21/2021 11:25 PM
Well, the test-by-fire would be doing it with the monster graphics and graphic pointers, and replacing them with whatever the expand destination is, then seeing if it actually displays monsters for RotDS. That's 7 pointers in the $D2 bank, one in the $E9 bank, and one in the $EC bank.
Serity - 7/21/2021 11:26 PM
gotta take the length into account tho sometimes, and idk how that flows~
like, rotds has expanded spell name lengths
magic spell names are at
E6F567
->
67 F7 26 00
. that actually shows up four times (...spell editor and... something else? dunno), but even if you adjust that, you'd still have to edit the length
Code:
427140: push ebp
427141: mov ebp, esp
427143: sub esp, 0x18
427146: cmp byte [ebx+0x41], 0x2
42714a: push esi
42714b: jnz 0x42716c
42714d: mov ecx, [ebx+0x397b4]
427153: and ecx, 0x1
427156: mov eax, 0x16bb
42715b: sub eax, ecx
42715d: mov dword [ebx+0x63ac], 0x5
427167: shl eax, 0x9
42716a: jmp 0x427189
42716c: mov edx, [ebx+0x397b4]
427172: and edx, 0x1
427175: shl edx, 0x9
427178: mov eax, 0x26f767
42717d: mov dword [ebx+0x63ac], 0x7
427187: sub eax, edx
427189: mov esi, [edi]
(ignore the left offsets) this is probably a difference between japanese version and english version for spell names
altho that'd be weird if jp spell names were stored at C016BB hmm
CDude - 7/21/2021 11:30 PM
Yeah, that would be roaming into disassembling the whole editor, because you have to know how it's reading the data in order to make an adjustment like that. I was thinking more making the editor compatible with certain expansions. Although... that 0x7 coincides with spell name lengths.
Serity - 7/21/2021 11:30 PM
whatevs. getting too far into assembly is irritating
it does, and 0x5 coincides with japanese spell name lengths
0x26f767 is referred to a couple more times later on though but without a 5/7 check :d (or either of them)
anyways, it should obv be possible. the editor has to store the offsets
somewhere
CDude - 7/21/2021 11:33 PM
Well it's promising that these offsets are only showing up twice each in the raw hex of the editor.
Serity - 7/21/2021 11:33 PM
0x26f767 shows up 4 times actually :d
but most of them only twice
you can ignore the
427172: and edx, 0x1
stuff for the most part, thats just the output of a C++ disassembler (snowman)
(although that too is like an snes rom, it assumes a header of 0xC00 (rather than 0x200 so the value on the left will always be 0xC00 higher than the true position) and then windows programs start from 0x400000 (like how snes roms start from 0xC00000))