and thank you for answering my numerous questions.
re: the 4th and 5th byte breakdowns:
great! that'll help in completing the patch, and they've also been worked into the commented disassembly on my website.
"11: The item can only be used in only one ally."
to be sure: only one at a time, or is the targeting cursor unmovable? also, i assume these values are in hex? (they almost always are, but since i lack the game to test, i ask some normally silly questions.)
The items can be used by the W-Item command are those that have an ID from 00 to 45 (In hexadecimal).
also very good news. this should stop the patch from ballooning too much. though i am still curious as to whether FF7's data allows changing the type of a given item, or if the types are firmly fixed by Item ID range.
as for the (Item ID == null) check i planned to add to or displace the (Item count == 0) check, i'm now leaning the latter. Square's Morph/Steal add item code does not use count in determining emptiness. and it's possible that if an item slot doesn't have all bytes reset when its contents are used up, i might falsely assume something still inhabits it. a theoretical issue when adding to an otherwise full list, for instance.
re your link: also helpful. a few things:
1) r1 looks like it'll be safe to use. both for reading data to put in the fourth and fifth bytes of the item list, and as a general temporary register. however, i'd like to see whether and how 0x000bb9b8 uses the register, to be sure.
2) what branches to or calls 000e14a0 or 000e14a4? it doesn't matter much with your fix going elsewhere, but it's got me curious how that code is reached.
000df4dc: 1040000b beq r2,r0,0x000df50c
000df4e0: 00000000 nop ← This is where I relocate the code. The following code is similar to where it was originally. It seems that the Square programmer was wrong to place it.
what are you putting in the NOP slot? are you aware of CPU pipelining, and that the instruction after 000df4dc will get run even when that branch is taken? also, from what i've read, having jumps/branches in that "branch delay slot" (i.e. where the NOP originally is) is a no-no, that produces unpredictable or nonsensical behavior.
or phrased differently: do you want whatever's being put at 000df4e0 to run all the time, or just conditionally? i'm too unfamiliar with 000df4dc and Function 000df2c8 in general to know what the goal is here.