Topic: Developing FF4kster: a comprehensive editor for FF4

[chillyfeez]

Hmmm... have you tried changing them to, say:
07 06 FF
09 08 FF
0B 0A FF

Just curious...
I'm wondering if this might be sprite arrangement data for PC enemies, which could be cool - you might be able to force a fight with a "weakened" or "casting" PC enemy...

[Pinkpuff]

What about enemy PCs that change stance during the fight? Such as Kain for example...

[Pinkpuff]

Excuse the double post, but I just uploaded another update. The problem with Boast has been fixed, and now Cry and Steal parameters have been added.

Enjoy!!

[chillyfeez]

What about enemy PCs that change stance during the fight? Such as Kain for example...

Well, with the exception of Edward, I think they all change stance, but in a way that fits the action performed. What I suspect Displacer may have found is the data that dictates the PC enemy's inactive stance.

Actually, while researching monster and summon sprite arrangement, I did come across a block that controls the party's sprite arrangement. I couldn't think of anything really useful to do with it, so I never bothered to mention it. I've got the offset saved in a notepad file somewhere...

[Pinkpuff]

Updated yet again! This time autobattles are working again (I think!), including Golbez scripts.

[Displacer]

I'll give those numbers a try, soon as I fine my way back to where they are loaded. This stuff is so convoluted it's easy to get lost

[Displacer]

OK chillyfeez, here's what I get with those numbers:

[chillyfeez]

Yep, the parry stance - so that's definitely enemy PC sprite arrangement. Only I bet making that change would make every enemy PC appear in parry stance...
So this arrangement is somehow called by those "mystery bits?" That's weird. That it would potentially be a variable indicates some abandoned plan by the battle programmers, I'd suspect.

[Displacer]

Yea there's a whole ton of sets of data based off those 3 bits. I'm guessing they're all graphics related but since some of the data are actually pointers to other data then it's going to take awhile to sort them all out. Figures, I hate dealing with graphics code but eh, at least it will clear up some of the "unknowns".

So, for the record the PC enemy sprite arrangement data is stored in 2 parts. A set of pointers starting at 0D/FD6D which points to the actual data starting at 0D/FD89 and it looks like there are 14 in all

[chillyfeez]

Huh... That's certainly more than the standard amount of PC battles, and more than the amont of battle stances. Pretty nifty find there.

[Displacer]

Thing is, it uses an offset to load these so I'm betting one of the other sets of data are used to pick a particular stance for each character, meaning there can be more than one for any particular character. I'll track down which data set it is offsetting into to get the stance data.

[Grimoire LD]

Good work on cracking the use of the three mystery bits there! That they are used to get a character to use proper animation is very interesting and seems that from the picture you've shown you can also make them use other animations.

Great updates to the editor here! Let me see if I can see if everything is working right...

Hmm, now Boast doesn't appear to do anything.

Ah, that's why. Boast for some reason reads an 80 base which places it outside of the User's Data. At base it reads 97 instead of 17. where it should if it's dealing with the User and not the Target (or in this case because its looking directly at the Character's data the use would instead place it in the Next character's data)

Something rather screwy is going on with Cry.

Oh, that's why. Alright, here's what's wrong with this...

The description of it is a little vague...

"Set Target's X to half its X"

It should read something more akin to...

"Subtract Target's X from half of User's Y"

Also again, I wasn't clear with the Store bytes, so changing those two alone wouldn't change anything but the foe's Steal Evade value. Here is what you need to add to that...

0x1EB16 (without header) 9D 2F 20   STA $202F,x[$7E:22AF]   A:0069   X:0280   Y:0000   P:envMxdizC - Store A in Monster's Steal Prevention.

And that should fix that.

Steal as far as I can tell worked flawlessly, taking the new parameters into consideration.

Now the Autobattles look flawless! It only means that if you used the editor with the improper functions you'd just have to change them to their proper functions, but everything looks A-Okay!

[LordGarmonde]

Thank you for the warm welcome. I'm sorry it took so long to reply; I was very wrong about my workload this week. Anyway here's what I have so far.

You might try, by the way: find where in RAM the game loads the current world map data (might be known, I'm not sure), set a breakpoint to one of the tiles that changes with an event, then set and clear the event flag to observe the changes. Hope that helps!

Good call! The ram offset is known; I found it in Yousei's text file:

   $7F5C71        Beginning of Map data

With that and comparing a snapshot of the RAM before and after I found where the map data is changed for Mist. Looking at the 1.0 ROM what starts as:

$7F92D2:   23 23 23 23 23
$7F93D2   50 16 16 16 16
$7F93D2   03 04 02 03 13

Becomes:

$7F92D2:   13 13 13 13 13
$7F93D2   12 13 13 13 14
$7F93D2   13 13 13 13 13

(Ram Addresses found using Geiger’s SNES9x debugger with Snes9X1.51.ep10r2)

So tracing that back through Assembly I found:

4A/C52D:   AD8112     LDA $1281
4A/C530:   2940       AND #$40
---------------------------------------------
4A/C53A:   A913       LDA #$13
4A/C53C:   9FD25C7F   STA $7F5CD2,X
4A/C540:   9FD35C7F   STA $7F5CD3,X
4A/C544:   9FD45C7F   STA $7F5CD4,X
4A/C548:   9FD55C7F   STA $7F5CD5,X
4A/C54C:   9FD65C7F   STA $7F5CD6,X
---------------------------------------------
4A/C555:   A912       LDA #$12
4A/C557:   9FD25C7F   STA $7F5CD2,X
4A/C55B:   A913       LDA #$13
4A/C55D:   9FD35C7F   STA $7F5CD3,X
4A/C561:   9FD45C7F   STA $7F5CD4,X
4A/C565:   9FD55C7F   STA $7F5CD5,X
4A/C569:   A914       LDA #$14
4A/C56B:   9FD65C7F   STA $7F5CD6,X
---------------------------------------------
4A/C574:   A913       LDA #$13
4A/C576:   9FD25C7F   STA $7F5CD2,X
4A/C57A:   9FD35C7F   STA $7F5CD3,X
4A/C57E:   9FD45C7F   STA $7F5CD4,X
4A/C582:   9FD55C7F   STA $7F5CD5,X
4A/C586:   9FD65C7F   STA $7F5CD6,X

(Disassembled from 1.0 ROM using DisPel)

I checked in the ram to confirm that setting Flag 14 had an associated change from 00 --> 40 and that is then matched against. It appears that the map routine overall works as it would for the world as first seen exiting Baron and then this modification subroutine is called to change the map when and where appropriate. Not far below this set of code is what appears to change the graphics associated with the hole to the underground. I further tested this by hijacking the function call for the modification sub routine and then adding my own. Basically what I did was to change:

--- Main Code ---
((Some Code))
Set Map
Call Map Modification Subroutine
((More Code))

to:

--- Main Code ---
((Some Code))
Set Map
Call My Subroutine
((More Code))

--- My Subroutine ---
Map Modification Subroutine
My Changes
((Return to Main))

From my tinkering this was the safest way; I had many crashes when I was messing around. I ended up using ASMDev (http://www.romhacking.net/utilities/395/) but I had to change the code line by line. Does anyone have a suggestion as to where I could get a good assembler to go with? Ideally, at least given the way I think & program, I would dump the ROM - edit it (so far Notepad++ is working well) and then reassemble. Any helpful hints in this regard would be welcome. It also seems that you all seem to be using a different program for working with the Assembly code (that itself may be the answer for me). If you let me know what you've been using to generate code such as:

0x1EB16 (without header) 9D 2F 20   STA $202F,x[$7E:22AF]   A:0069   X:0280   Y:0000   P:envMxdizC - Store A in Monster's Steal Prevention.

That's what I have as far as Mist and Assembly. I do also have a follow up on FF4kster. 1st off: awesome! I love the new features. :) One thing I did notice, and this is not new for me at least was that in editing the NPC table for the hospital in Toria it shows up as an empty list. The event script appears correct and references characters 0 - 3, but there are no characters listed on the NPC list. I was very excited when I got my first response which included:

One caveat about the tools you're using: yousei's uses only version 1.0, and FF4Kster is really only fully compatible with v1.1 (specifically, it won't properly modify battle commands and level up data for v1.0, possibly more). Best workaround for this is to make map edits with yousei's, then patch the changes into a 1.1 ROM for use with pretty much any other editing tool.

I thought for sure that was my problem; but a test with a clean copy of the 1.1 ROM killed that hope. It's a very minor thing; but just something I noticed and wanted to bring up. I have a suspicion (complete speculation here) that given the accuracy of the rest of the NPC lists that the hospital at Toria is just some exception to the rule; I don't know but it seems that way to me.

That's it from me for now. The next thing I plan to toy around with is pulling equipment off of someone when they leave your party. I'm thinking of perhaps dumping them in the inventory associated with the Fat Chocobo. We shall see. 

[chillyfeez]

Hi again, LordGarmonde. So if I'm reading this right, then you have successfully modified how the world map changes with certain event flags? Cool, nice work!

As far as ASM tools go, ASMdev is the best I've found, and it's not great, just the best of the very few tools out there. I've really only written battle command code, which appears in fairly short blocks of code and tends to use the same opcodes over and over again, so once I got the hang of doing it with ASMdev, I actually switched to just writing assembly in notepad and using this site to help translate it all into code. It's a very long and tedious process that I oddly find very amusing. Anyway, that's my long way of saying that there doesn't seem to be anything better than what you've already found.

Regarding disassemblers, what I've been doing (and based on the outputs Grimoire LD has posted, I'm pretty sure what he's using too) is Geiger's SNES9x Debugger. What's nice about using Geiger's to disassemble is that - because it's emulating the ROM at the same time - it "understands" the context of the disassembly (for instance, knows which 16-bit flags are set at the time). Also, you can disassemble an op at a time in real time in order to see how the registers and accumulator change as the code is executed.

One thing I did notice, and this is not new for me at least was that in editing the NPC table for the hospital in Troia it shows up as an empty list. The event script appears correct and references characters 0 - 3, but there are no characters listed on the NPC list.

I puzzled over this one for a while. If I remember correctly, the Troia hospital uses an NPC set from another location (somewhere else in Troia, I think). If you choose to edit map properties with FF4Kster, and view the Troia Hospital, I think you'll find your answer.

[Pinkpuff]

I do also have a follow up on FF4kster. 1st off: awesome! I love the new features. :) One thing I did notice, and this is not new for me at least was that in editing the NPC table for the hospital in Toria it shows up as an empty list. The event script appears correct and references characters 0 - 3, but there are no characters listed on the NPC list. I was very excited when I got my first response which included:

Thanks! Glad you're enjoying it! And yeah, the NPC sets of some of the maps are messed up; that's not an issue with the editor, that's actually how they're stored in the ROM. There are a lot of things about this game that are coded/stored strangely, some of which are easier to hide from the user than others.

Anyway now that the autobattle editor is finished and seems to be working correctly, I thought I'd give people a heads up as to my plan of attack for the near future:

• Fix the remaining bugs in the commands
• Begin tackling the "tile editor" which will allow editing of the map tiles and tilesets.
  
  • Get the palettes and graphics reading and displaying correctly
  • Figure out info for tile properties (solidity, warps, triggers, etc) and create editor components for them
• Create a map editor
  
  • Most of the info for this can be reverse engineered from the output of FF4Tools
  • The remaining info is I think already posted (stuff relating to the overworlds and such)

Of course I still have school stuff left to work on, exams coming up in a couple of weeks, and so that combined with the fact that this is another fairly hefty component means that progress will likely be slow and not all that visible. Hopefully though it will be well worth the wait because having that functionality integrated into FF4kster instead of having to use external programs will greatly improve efficiency of rom hacking.