I think I can alter the listbox itself to change what the type-ahead does. I don't really want to put the hex to the right because it breaks the convention.
I put in the R999 changes to Shishi. From what fdc uploaded, I took the two that seemed the most current/correct (there were three sets of the same two files), and imported them into the project... however, that only got me some of the functionality. I had to do a few things myself to get things to the same point. Not sure why that is but it seems to work now, so future Shishi versions should have those features (Quick reimport with Ctrl+R; frame numbers don't change when changing sprites).
I also did something... interesting with FFTorgASM. I've been importing some of my MHA code into the FFTP project... Now why would I do that? I present... an epic tale of patching ASM!
Here's a hack I'm going to have in my XML file. This is a bit different from a previous hack because it checks item type instead of item number... but what's interesting is the way it looks in the XML:
<Patch name="Require Materia Blade -> Require Item Type X (Default Lance)">
Require Materia Blade -> Require Item Type X (Default 0x0F = Lance)
(Weapon type list removed for space)
<Location file="SCUS_942_21" offset="4CE24" mode="ASM">
li t0, 0x0f
move v1, a1
sll t1, v1, 1
addu t1, t1, v1
sll t1, t1, 2
lui at, 0x8006
addu at, at, t1
lbu v0, 0x2ebd(at)
lbu t3, 0x0184(s1)
subu t1, v0, t0
sltiu t1, t1, 1
sll t1, t1, 2
or t3, t3, t1
sb t3, 0x0184(s1)
<Variable name="X" file="SCUS_942_21" offset="4CE24" default="0F" />
Heh heh. As for the pseudoinstructions here (li and move), so far I'm only allowing them if they map one-to-one to an instruction, but I may put in support for multi-instruction ones. You can also safely assume variables are patched in after the code itself, so you can write code and then just overwrite it with the variable, instead of trying to fool with the <Variable> and <Location> tags so they match up exactly, as I do here.