Final Fantasy Crystal Chronicles GCN Hacking

[Skullcrush04]

Hello. I have been trying to find the item/weapon table in FFCC. I tried searching for the Copper Sword's damage value (15, or 0F in hex) in the extracted main.dol file and got 2813 results. I tried looking for the damage of the next sword in line (20, or 14 in hex) in the results list and found nothing. I don't know if it's in another part of the rom, but I need some help to find it. Any help would be appreciated.

[FAST6191]

That is rarely going to do much for you for many reasons. It is not impossible it yields something and can even suggest it if you can do it quickly but... yeah.
Four of the big reasons are compression (there are others but http://www.amnoid.de/gc/ , https://ece.uwaterloo.ca/~ece611/LempelZiv.pdf being my usual primer on compression), it may not be in the main.dol file (probably a whole bunch of other files available to store data in, though stats tables being in the main binary is very much a thing many games do), obfuscation (in compression it is generally noted that the minimum size might be 2 bytes, any less and you are not saving space, so a value of 0 for length actually means copy 2 bytes, and that corresponding increases the maximum amount you might copy, same idea here is every weapon has a minimum of 50 damage then now you have 50 more potential value to the max damage) and if data representation works differently for this game.

Data representation then being the big one.
Two main ways older games did it, modern ones might treat it as more of an abstract affair where each weapon is unique and is defined with something not so far off XML or something*.
Anyway the two big ways are each weapon (or party character, enemy, potion, vehicle...) would be... actually if you want to imagine it all as a big spreadsheet (every weapon gets its own line of each stat) then one way takes each stat in a column and puts that one after the other, one takes each item as an individual unique thing all to itself in row by row and puts those end to end (byte 0 of each entry is atk, byte 2 def, byte 4 magic...). You were searching for the column approach when there is a whole other world.

You can try to infer things from memory searching, file searching, save editing and more (equip, unequip, discard... things that modify various values). However it tends to be 10 times easier if you dip into basic tracing. I don't know what Dolphin has for this these days ( https://www.romhacking.net/documents/361/ is old and for the GBA but the principle is the same whether you are on a commodore 64 right up to whatever PC game was released yesterday, give or take security on modern computers making it marginally more annoying).
With tracing you get to follow data back up the chain to where it comes from, and learn whatever was done to it along the way (as well as probably being able to create the equivalent of https://www.dragonflycave.com/mechanics/gen-i-capturing for your game of choice, or at least the full listing of stats far quicker than the ones on gamefaqs that might maybe use a cheat to be able to get any weapon and hand transcribe it, nothing stopping you from using cheats to gain things either).
My general approach pending a better idea for the game is find the enemy's health (see basic cheat making https://web.archive.org/web/20080309104350/http://etk.scener.org/?op=tutorial ), set a break on write to that, attack the enemy and see what changed it, part of that will be the atk/damage value. Now you know where the atk/damage value for the character presumably is (maybe you are lucky and it includes the weapon separately) you can repeat with a new break on write and fiddle with the equipped weapon in the relevant screen, the location of the weapon's value now being known and repeat a few more times until you are staring at the location in a file of it, and presumably everything else for it is all going to be similar (again might be each stat right after the other, and even in the columns approach it still tends to be column following column right next to each other or near enough in memory).

*modern game with 7 stats, 9 elemental damage effects, 100 potential specialist traits... adds up in space quickly when you also want thousands of weapons such that is easier to say <atk=3>,<acc=5>,<mag=10>,<scope=0><rate=2.56><reload=3><cost=4000><firedmg=10> and not have to worry about listings for the however many other possibilities there are).

[Skullcrush04]

By tracing, do you mean pointers? I could never get pointers to work for me, even with a Cheat Engine tutorial https://www.youtube.com/watch?v=jDnBTHymjSk

[FAST6191]

Pointers would be involved at some level in that (they literally point the way to things after all), however it might not be quite the same (technically speaking pointer is pointer but the mindsets and ideas involved are subtly different) as pointer codes if the cheat engines covered that.

No for tracing... might as well cover the basic idea.

As far as memory is concerned in the standard computer security model there is reading, writing and executing as things you can do in memory. It is also pretty good here.
In a debugger you then get the options to set breakpoints, these will literally halt the emulation (or execution in those rare cases of hardware debugging) to say whoa that thing you told me to look for just happened. Log/watch points also exist and will note it all down to a big list instead for your later perusal, which can be useful rather than pressing next 5000 times or for a rare different take on a commonly accessed area).
Anyway break on read (bpr), break on write (bpw) and break on execute (bpe but sometimes other things in different setups) are the big three. The sometimes seen "run to line" is just a specialist version of break on execute.
You find an area of memory you care about (cheat searching usually) and you then figure which of those will be useful for your setup -- losing health, reading to see if something can accomplished, and then when you find some instructions from one of the previous two doing something the break on execute options. If you are lucky the first thing tickling the area you care about will be what you care about, if not then you now know a step back along the chain so you work backwards from there until you hit a dead end and set a new break on that area to repeat it until you are where you want.

Better debuggers will allow you to refine further (only break when value is between/less than/not/greater than/... blah and blah)

Necessarily this involves knowing something of assembly programming. For many assembly is the final boss in ROM hacking, and the hardest of any actually used areas of programming (you get esoteric languages but nobody uses them for real). This is not wrong; a mastery of assembly is indeed a skill to be proud of but for this sort of thing you can get away with a lot less.
I generally note there being three types of instructions
1) Maths. Computers do maths after all, indeed are good at very little but that. Tend to be highly specific (this instruction is for adding unsigned numbers, this for signed, this for single precision floats, this for 8 bit values, this for 16, this for double precision... and when you make one of those each for adding, subtracting, multiplication, division, shifting, boolean logic, trigonometry... you get the however many hundreds or thousands of instructions the big scary instruction lists are, however they tend to be composed mostly of those for each data type.
2) Housekeeping. Marketing aside the number of bits your register (small sections of super fast memory) can store/usefully use determines the bit of your CPU so when it says 32 bits they mean it. You tend not to have many registers either (the NES has 3 in general use, few more for some other aspects, modern PCs and ARM stuff and such tend to be more, though rarely going to be more than about 60 and most rather less than that with 16 being a more normal number). Mov is probably the most important instruction here as it is the one in most CPUs (though powerpc can try to be different) that copies (note note moves as it tends to leave the original alone) data from one register to another, that and any instructions that grab data from general memory or put it back in. Others tend to be things that reset states that 3) will have done, or push and pop which push contents of a register to the stack and pop it back in afterwards if you need the register for something else).
3) Program flow. Adding up everything in a line is great fun but kind of limiting. The real fun in computing (and games are a prime example) are when choices get made. Jumps (generally frowned upon), branches, interrupts, halts... this is it, though usually falls under the idea of loops in general computer programming parlance (and loops are a thing here too, just not always referred to as the IF ELSE, While, For and all the other things you get in intro to programming for C, Python, Java... whatever. You will tend to meet a dedicated register in this called PC in most CPUs aka program counter that notes where the current instruction is. SP (stack pointer) and return address (when you jump/branch somewhere to do something it helps to jump back afterwards, this is that and as there is only one it is why you are generally told not to call a function within a function in normal programming).
Different CPUs call these different things and the old at the time and now positively ancient powerpc of the gamecube (and wii, and wii u) is noted as having a few tweaks over most other things that others know of but still going to be the same underlying principles.

CPUs writing memory was deemed a waste of time when they could instead be crunching numbers so sometimes there is DMA (direct memory access) that is something separate you can use to copy contents from one location to another.
Similarly most things don't tend to have the whole disc viewable in memory (earlier cartridge based consoles... slightly different matter though not without its quirks) and thus will tend to have a method to grab data from a disc (or cartridge on later cartridge based consoles) which is why you have the perks of file names, sizes, directories and more where those doing SNES stuff just have one file containing everything.

Anyway when you are limited to 32 bit runs of data, maybe only a few of said 32 bit registers, a few instructions that only do very basic operations and very little in the way of high level abstract things then what might be a line of text, a line of normal code, a 20 symbol (including numbers) maths equation or something gets quite long. This is why CPUs got faster and faster as many things done quickly can make big things happen quickly.

So you take that general idea and work backwards through code, you need not understand every quirk with timing and what a given instruction can handle in terms of input data, nor need you be able to recall the entire instruction list from memory (cool party trick if you can but we have the written word for a reason).
You then want more superficial stuff like this gets added to this (which is what I care about) and then used to do that. Work backwards until you find your data or something you can more usefully search for in the entire iso.

[Skullcrush04]

I'm trying the break point method, but I feel like I'm going in a maze. On the last two logs, which address is the next break point?

Str RAM Address
8021F28F

03:18:087 Core\PowerPC\BreakPoints.cpp:308 N[MI]: MBP 8009f3b0 ( --- ) Write16 6 at 8021f28e ( --- )
03:49:689 Core\PowerPC\BreakPoints.cpp:308 N[MI]: MBP 8009f3b0 ( --- ) Write16 6 at 8021f28e ( --- )

06:17:529 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 8009f3b0  --- (8021fe48 00000000 00000000 00000006 80954b40 00000101 0000c200 0000c208 80887898 8102de58) LR=8009f3a0
06:17:529 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 8009f3b0  --- (8021fe48 00000000 00000000 00000006 80954b40 00000101 0000c200 0000c208 80887898 8102de58) LR=8009f3a0
August 17, 2021, 08:16:28 AM - (Auto Merged - Double Posts are not allowed before 7 days.)
So I learned I should have been using "Write to Log" rather than "Write to Log and Break", as the latter seems to cut off some info. Now I have

Str RAM Address
8021F28F

00:09:747 Core\PowerPC\BreakPoints.cpp:308 N[MI]: MBP 8009f3b0 ( --- ) Write16 6 at 8021f28e ( --- )
00:09:747 Core\PowerPC\BreakPoints.cpp:308 N[MI]: MBP 8009f5ec ( --- ) Write16 6 at 8021f28e ( --- )
00:09:747 Core\PowerPC\BreakPoints.cpp:308 N[MI]: MBP 8009f700 ( --- ) Write16 15 at 8021f28e ( --- )
00:09:747 Core\PowerPC\BreakPoints.cpp:308 N[MI]: MBP 8009fa98 ( --- ) Write16 15 at 8021f28e ( --- )

01:06:743 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 8009f700  --- (80954b40 00000240 00000021 8021f338 80954b40 00000000 00000000 00000000 80887898 8102de58) LR=8009f6b4
01:06:743 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 8009f700  --- (80954b40 00000240 00000021 8021f338 80954b40 00000000 00000000 00000000 80887898 8102de58) LR=8009f6b4
01:27:473 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 8009f700  --- (80954b40 00000048 0000000f 8021f338 80954b40 00000000 00000000 00000000 80887898 8102de58) LR=8009f6b4
01:27:473 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 8009f700  --- (80954b40 00000048 0000000f 8021f338 80954b40 00000000 00000000 00000000 80887898 8102de58) LR=8009f6b4

The bold ones are the Weapon Damage for the two swords I switched between. The number before appears to be an offset, because I went to 80954b40 and found the weapon values:

80954B8F --- Copper Sword Strength
80954D87 --- Excalibur Strength

Using the values around the Copper Sword, I located it in the ISO file as well:

29D09FFA-29D09FFB: Weapon Model
29D09FFC: Item Type
29D09FFD: Item Usability
29D09FFE-29D09FFF: Weapon Damage
29D0A003: Focus Attack

Thank you for your help. You were right about my first method being bad for yielding results; the next sword's damage value is 72(48hex) bytes away.

[FAST6191]

Nice one. Most don't take to debugging that well when new to it; recursively searching the ROM is maybe not the more surefire method (compression/decryption/modification maybe getting in the way) but it is quick and if it works...

[Skullcrush04]

I don't mean to be rude, but what do you know about Romhacking a button to perform a function? I want to put the Defend command on the Z button so I don't have to scroll to the Defend command with L/R and then press A.

[FAST6191]

I don't know how that would rank as rude but OK.

Had a discussion on it a couple of days back
http://www.romhacking.net/forum/index.php?topic=33258.0

Activating something normally activated from a menu is a slight twist on what is normally done but well within reason (the game already checks a controller, and you are doing an action already done by the game).

For GC hardware you want chapter 9 of http://hitmen.c02.at/files/yagcd/yagcd/frames.html

Technically you don't have any OS level stuff for the gamecube, even with the various hacks, however if you are running it on a Wii ( https://wiibrew.org/wiki/ should have something) then you might have something on the various means of running GC games from non standard means -- simple CIOS probably not going to cut it so go for one of the other two options here.

You might have another way as well for this, and you will probably be doing the basics to start with anyway.

For a game like Final Fantasy CC then I imagine defend command/mode is a state. Maybe not in the same memory area as poisoned, paralysed or whatever else (though I would not be entirely shocked if it was) but still going to be a state/flag/variable the game sets. Make a button activator cheat to turn it on and tie that to a simple z press rather than combos normally preferred and yeah.
You can find it the same way you would find flags with a normal cheat search, though if you want to take your new found debugging skills and follow whatever reads the controller state/controller state's debounced area and what in turn responds to A or start or whatever is necessary to activate the menu option once highlighted then that is the quicker way.

You would also have the secondary problem of this game being for the GBA controller method which means you might need another activator for it when in multiplayer/GBA control mode. Though I am now curious to see if it is worth doing a controller hack for multiplayer FFCC gamecube version (most these days tending to opt for the DS efforts or something else).

[Skullcrush04]

I found some values, but none seem to work quite right...

802C7DA3 goes from FF to 15 to 16 on Defend, then 18 to FF on release. Locking the value at 15, 16, or 18 only makes the character continuously do only one of the three parts of the block animation.

802C81E3 goes from 0 to 8 on Defend, then to 0 on release. Locking the value only makes the character continuously start and stop the first part of the block animation.

Locking any of the values still allows my character to move during the animations, which shouldn't be happening.

Only thing I can concretely say is that the Z button's value is 10 in hex, but it's read by many addresses.
August 18, 2021, 09:44:40 AM - (Auto Merged - Double Posts are not allowed before 7 days.)
Characters States might be a no-go. The tribes have different Defense states. Clavats and Lilties are shared. Yukes and Selkies are both different.
August 18, 2021, 10:09:05 AM - (Auto Merged - Double Posts are not allowed before 7 days.)
This is the path I took to find some functions for state changes, but I don't know how to test them. I may have hit a wall here. I've been at this all night...

Defend?: 802C81E3 00>08 00

27:23:467 Core\PowerPC\BreakPoints.cpp:308 N[MI]: MBP 80126bd8 ( --- ) Write32 8 at 802c81e0 ( --- )
27:25:336 Core\PowerPC\BreakPoints.cpp:308 N[MI]: MBP 80126bd8 ( --- ) Write32 0 at 802c81e0 ( --- )

29:19:646 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 80126bd8  --- (00000000 00000008 00000000 801e0000 80243100 80ac3050 00000010 00000000 00000010 80123870) LR=80126bd8
29:23:014 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 80126bd8  --- (00000000 00000000 00000000 801e0000 401a82b8 00000000 00000000 00000000 00000010 80123870) LR=80126bd8
29:36:729 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 80126bd8  --- (00000000 00000007 00000000 801e0000 80243100 80ac3050 00000010 00000000 00000010 80123870) LR=80126bd8
29:37:032 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 80126bd8  --- (00000000 00000006 80372b4c 80372b48 8021de80 8021f270 00000001 00000000 00000000 801198d4) LR=80126bd8
29:42:073 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 80126bd8  --- (00000000 00000000 00000000 801e0000 401a8068 00000000 00000000 00000000 00000010 80123870) LR=80126bd8
August 18, 2021, 06:48:30 PM - (Auto Merged - Double Posts are not allowed before 7 days.)
At the very least, setting 8021F495 to "1" moves the command scroll to "Defend".
August 18, 2021, 11:58:34 PM - (Auto Merged - Double Posts are not allowed before 7 days.)
Each character seems to have their own scroll wheel for commands:
Character 1: 8021f495
Character 2: 802200c5
Character 3: 80220cf5
Character 4: 80221925
Character 5: 80222555
Character 6: 80223185
Character 7: 80223db5
Character 8: 802249e5

Using this, I made a raw crude cheat code for Dolphin that snaps all 8 characters' command wheels to "Defend" when the Z button is pressed (You still need to press the A Button since it ONLY moves the Command Wheel. Obviously, this can't be used in multiplayer. It also activates outside of combat areas, so I don't know what side effects that has besides characters starting dungeons on "Defend" rather than attack, so use at your own risk.

882432cd 00000010
0021f495 00000001
002200c5 00000001
00220cf5 00000001
00221925 00000001
00222555 00000001
00223185 00000001
00223db5 00000001
002249e5 00000001

[FAST6191]

Forcing a menu option is a reasonable half measure.

Curious that such things are done by class/tribe as well, would not necessarily have thought it that sort of game but menu coding is an interesting field for a reason (see also why so many exploits happen with them). Edit. Forgot to also say. You can reasonably assume whomever is to be using the cheats is reasonably aware if it is going to be a per tribe thing. Make sure to note it in a comment in the cheats shared and all good really.

I would wonder if then there are multiple parts of the defend setup (just as you can have gold in multiple places and have to edit them all to dodge anti cheat then nothing to say games can't use more than one flag), though might be easier at this point now you know something directly changed by it

If this was the NES and nowadays the GBA then you might have something like http://fceux.com/web/help/CodeDataLogger.html to play with. Here you would probably idle a bit in game (should take care of music and idle animations), idle in the menu (same thing) and then activate defend mode. Anything new called at this point would be logged. Not so useful for a cheat unless you are going to overwrite some game code (discs tend to see code copied to RAM to run and thus in the realm of cheat approaches) but if you have the location of the controller read then tacking another command on those to activate the defend state (compare to see if z is pressed, activate what I presume is a function and have it load back it) is not so bad -- hardest part of that tends to be finding a decent place to tack on code to as you don't always have space.

[Skullcrush04]

Bit of a longshot, I've been trying tofind some text pointers in the ROM file, but I can't find them. Using Dolphin Memory Engine I found one in RAM: 8096D150 at 8096A114. When I search for 8096D150 in the ROM in HxD, I get nothing. Even bytes around the table don't reveal anything. Is there a way to convert RAM to ROM?

[FAST6191]

So you found text but no pointers matching them?

Stuff in RAM can convert to things in ROM, especially on systems where the ROM is mapped to RAM somewhere (which most things on optical drives are not). However that tends to be another tracing session more than a shortcut (watch that one you found as the text for it is loaded up/as that pointer is loaded up in anticipation of the text). Once you find it then it might be obvious -- shifts, bits needing blanking, simple addition, some kind of relative effort... but some of the things I have seen in various games over the years.

Step one. Check it is actually a pointer and not some kind of autolength effort (would not necessarily expect it on the gamecube but would not shock me terribly either; we are still in the vaguely modern coding languages and approaches era by this point) or fixed length (still commonly seen to this day in menus and simpler games where you can afford to do that sort of thing). This is done the same way most new text hackers slam into pointers; start writing past the effective limit and see what happens to both that line and the one that follows it when it loads up.
Do also check it is not some kind of length value approach; usually seen at the start of the text sections themselves but can be before or after.


Generally analysis of the file and surrounding files reveals what I want... I say knowing I have one that stumped me as my next "when I finally have some free time" project that is going to want me to play debugger. Still see what is immediately before and after the text in the text file, what is in the same directory as the text file or the one immediately up, or anything obviously named. Comparing between regions can be good, languages as well in the case of European multi5 stuff (even better if there are two slightly different takes on the same language; by this point many companies independently translated at least English for both US and UK audiences, Spanish and French possibly as well but we will leave comments on the quality of efforts there for another day). I usually check to see if there is some kind of end of line value and take a list of all those (better hex editors tend to have a find all option you can copy/export, forget which free one did it but probably tiny hexer out of my usual selection of free hex editors* to match hex workshop or 010 editor), or make a list of what I expect to them based on reading the text/what I see in the game. With said list in a spreadsheet you can take the differences between them, between a list of potential pointers and compare the two (end of line might not be start of the next one so 1 or 2 bytes out is to be expected, 10-10000 bytes tends to be offset pointers such as it counts from the start of the text section and the amount it is out is a fixed distance difference/difference between expected and actual tends to mean relative pointers**).


*bit of hurry to be grabbing links but tiny hexer (main website long since defunct so will have to be a download site), xvi32, icy hexplorer are the big three and I will usually include hxd in that because it is nice for general use.

**relative pointers tending to be take current location, add value found here, this is final pointer, as each pointer is usually going to be a fixed size in bytes long then it will in turn make the expected vs actual say 4 bytes at first, then 8, then 12, then 16.... out or some other fixed value for longer pointers or pointers that also carry some formatting data in the middle there.

As far as RAM to ROM then generally for a filesystem based system I might expect the pointers in the file (or binary somewhere) to be a more file level affair, and then be converted into RAM later (easier in both cases of dynamic memory allocation and ability to edit files without having to call up programming to do a full rebuild as you tweaked a word). Exception tending to be for text strings located in the binary (or something that functions as a binary) where it will have memory level approaches. As text files are not typically going to be huge for games like this (or indeed almost any game - 8096D150 is 32 bits long after all which means it can address some 4 gigs of data, no text file is going to be more than a few megs) then you might find something by blanking the early part of the pointer and hoping that works, or indeed searching for the latter part. If you have multiple pointers (I don't know what you mean by bytes around table here, but presumably you are hoping it is going to be like normal pointers in files where the game maybe loaded up all the pointers for that section and is now skipping between them, instead you have something like this is the current text location and will change when something else wants to be loaded) then you can also try a relative search approach similar to the spreadsheet thing above, or relative search in general, where the difference between say 3 or 4 pointers is searched for to see if any differences in successive I guess 32 bit sections are this.

[Skullcrush04]

The item text is in \files\dvd\cft\c_system.cfd file in the extracted rom, but no pointers. I don't see anything in the folder that is named similarly. Is there a way to use this to find pointers?
September 13, 2021, 09:25:17 PM - (Auto Merged - Double Posts are not allowed before 7 days.)
I also found this text in the Memory Viewer just above the RAM's text pointer table: ecflat_data.cpp
I've tried searching for that in the ROM in HxD, but it doesn't show up, either. I'm really at a total loss as to how to find this Pointer Table in ROM. I'm starting to think it's impossible.

[FAST6191]

It is not going to be impossible; if it exists it will make itself apparent when loading the text (or thing leading up to loading the text).

Anyway so in the c_system.cfd file is nothing that could be pointers? That being it is all text from start to finish (not even anything that might be a length value in the middle of the text), or what is not text is clearly markup or all 00/FF, or that for the amount of text there is then nothing that could hold enough pointers* or something that could not realistically be pointers?
Rare but it happens.
Usually at this point I would look in the same directory at the other files there. Sometimes when the text (or archive) then it is easier to have the file lengths/locations aka pointers in a smaller separate file and that way they can pull things from the smaller, separate file rather than having to maybe have three runs at a file on the (first go to see how long the pointers are, second to get the pointers, third to get the data) or other complicated things (no need to have the pointers in the binary and make a new binary any time you change a text string length).
File names in these scenarios will be either the same name but different extension, or if there are underscores in the name (maybe other files are numbered as well) then whatever is before the underscore will be the pointers, usually smaller as well.


*can be nice to compare files at this point based on size. Large text file with what would presumably be a lot of sections/lines/pointers needed will tend to have a longer pointer section length than a short one with only a few. Could still get confused for a markup/formatting section but that is a different matter and hopefully obvious as well.

Anyway sounds like you already know about tracing from the earlier stuff. If you know where the text is loaded into memory for further use, and possibly where at least one/the current text value pointer is located then anything that reads from those or feeds into the new value. You get to follow that back from when it appears on screen (might be a room/scene before just in case it loads it ahead of time) to where the read for that particular location is generated, possibly then repeated until you find out where something in the ROM figured in that.

"ecflat_data.cpp"
cpp is the extension used by many writing C++ code, which would have been popular/viable on the gamecube. If it does not appear in the ISO then it might be compressed. I would not necessarily read much into it at this point; could be something left over from development, or what was in RAM on the computer when the compiler needed something random.

[Skullcrush04]

My grasp on tracing is very shaky. A lot of breakpoints just continuously spew results, and I can't do anything with them. How would I use Monkey-Moore to do a relative search to find pointers? I can find the text itself in the ROM just fine.
September 14, 2021, 01:47:29 PM - (Auto Merged - Double Posts are not allowed before 7 days.)
These are the first entries in the RAM's pointer table: 8096CF40, 8096CF41, 8096CF4A, 8096CF4B, 8096CF54, 8096CF5D.
8096CF5D is the letter "a" in "a copper sword"; the others seem to be dummy text. Still don't know if that can help me find the pointer list in ROM...
September 14, 2021, 05:41:55 PM - (Auto Merged - Double Posts are not allowed before 7 days.)
I found something that writes the "a" in "acopper sword"
21:40:049 Core\PowerPC\BreakPoints.cpp:308 N[MI]: MBP 80097950 ( --- ) Write32 8096cf5d at 8096a014 ( --- )

These are the first few entries I get when I do an instruction breakpoint on 80097950
24:36:984 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 80097950  --- (80372a88 8096a000 00005115 8096cf40 00000000 0000058c 00000001 00000000 00000004 801b5bc8) LR=8009793c
24:36:984 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 80097950  --- (80372a88 8096a000 0000511f 8096cf40 00000000 0000058c 00000001 00000000 00000004 801b5bc8) LR=8009793c
24:36:985 Core\PowerPC\PowerPC.cpp:621 N[MI]: BP 80097950  --- (80372a88 8096a000 0000512e 8096cf40 00000000 0000058c 00000001 00000000 00000004 801b5bc8) LR=8009793c
I feel like the bold entries might be something, but I could be wrong. I know 8096a000 is the start of the pointer table, but only in RAM, not ROM. 8096cf40 is the start of the text in RAM. I've searched and experimented with the other numbers and can't find anything. I need help interpreting this data. I'm feeling pretty hopeless at this point; I've been stuck at this pointer thing for days...
September 15, 2021, 07:24:30 PM - (Auto Merged - Double Posts are not allowed before 7 days.)
Is there some way to find the pointers from the ROM's text? Here are the first few words in the list in ROM:
29C86A31 29C86A3B 29C86A44 29C86A4D 29C86A4F
29C86A4D is "a", 29C86A4F is the start of "copper sword"

In c_system.cfd, their addresses are:
00000051 0000005B 00000064 0000006D 0000006F
0000006D is "a", 0000006F is the start of "copper sword"

Will any of this help finding the ROM's text pointers? Is there a formula or method I'm missing? I really don't know what to do from here. 

[Skullcrush04]

Tried manually finding the table in the Main.dol file and found nothing. The only other thing I found out was that there is a separate text file in the GBA folder for text on the Game Boy; I figured the table would be in Main to read from either? I still have no method of locating the table.
September 25, 2021, 07:05:15 AM - (Auto Merged - Double Posts are not allowed before 7 days.)
I'm looking at the PAL version, and they definitely translate some words differently (Such as "Dragoon Spear" in USA is instead "Dragoon's Spear" in PAL), so there are length differences. I just don't know how to make use of this since the text starts at different addresses between ROMs.

[Skullcrush04]

So, I found out that the text pointers in are most likely generated dynamically based on where the null bytes are in the text blocks, but now I have a new problem: I've found out that the new weapons I made can't be added to the Command List like other weapons. I can only equip them in the Equip menu. I have no idea where to even begin finding such info... Anyone have any ideas?

[FAST6191]

Adding things to games that was not there before tends to be tricky and most encourage just editing what is there if you can.

Still it is possible.

Menus tend to have a hard limit, or last pointer they read sometimes. This means you can have say 9 weapons where there were 8 but if it is only hardcoded to read 0 through 7 if doing the usual computer number counting (starting at 0) then you are going to have fun here. Back to tracing really here and following the menu code around to figure out how it knows where to loop back or stop moving (position on screen of cursor tends to be a good one, though loading a different sound is also one, can follow a button press on through the code as well if you want, and the usual view last new executed function if your debugger affords you such options) unless you get exceptionally lucky and it is some kind of double pointer affair (start of pointer table indicates end of pointer table and you can then push it off a bit to add more), linked list (possible, especially something that gets as creative as auto pointers) or similar to that.

Games themselves, especially one that has all these classes, probably also has a "can use this item" code somewhere. You tend to also have to edit those too.

[Skullcrush04]

Weirdly enough, the "can use this" bytes are in the weapon data entries themselves, but it only lets me equip them, not put them in the command list.

My real problem is I don't have something solid to start tracing. I found weapons with Strength and attack stats, I found enemies with their resistance stats (Thanks, player's guide), and I found text with, well, the text. I found bytes in RAM that track cursor position, but it's only for the menu entries on screen, not the entire menu. Even worse, some breakpoints just infinitely list data, making it impossible to use them to locate anything relevant.

[Skullcrush04]

I still don't know how to figure out this Command List issue. I'm pretty severely depressed right now. I'm starting to realize that all my efforts over the past few months might be for nothing.