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
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
(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))