Breakable Tools - Need Help

Dang, you're right.  Even with my code change it still causes the problem; Mimic must have been resetting the count.

Okay, that's the extent of what I can come up with for the problem.  Seibaby suggested in Discord that the 'add back to inventory' routine has some bugs in it, addressed in a Multisteal fix patch and a 'cast without breaking' item patch (I know about the former, I've never seen or heard of the latter).  That would be the next place to look.


EDIT: Interesting note... I was wondering about what Gi said... before I fixed the pointer, it was breaking tools 100% of the time but not causing item index bleed.
So..

Code:

SEP #$10       ;  Set 8-bit X and Y
TYX
LDA #$FF
STA $32F4,X    ;  null item index to add to inventory. This means the item will stay deducted from your inventory.
LDA $3018,X

I tried removing this part by making it branch over, and it stopped the item index bleed, but... introduced a separate problem.
With two tool users, the tool does not get added back to the inventory in time.  Which means if you input too fast, you lose a tool when it didn't break... even if it's an unbreakable tool.
Getting closer to the source of the problem, but not close enough.

---

Well, the solution has been found.  Thank Sir Newton Fig for breaking down what was going wrong and pointing to Bropedio, who already had a fix for the problem.

So here's the problem as far as I can tell

There's a buffer at $2E72 that the game stores some item data in for the purpose of adding items to inventory. There's also a list at $602D that is used for gaining items during battle. There's a routine that copies the 5 bytes at $2E72 to the appropriate slot in the queue at $602D ($64DA is the index into this queue). Each time a tool doesn't break, it's still incrementing the queue of items to be received. Eventually, it overflows, and Weird Shit Happens.

That said, there's also $64DB, which keeps track of the items that have been added back to your inventory. It gets incremented to match $64DA after that piece of bookkeeping gets done. Hypothetically, one could hack this thing to make the queue circular so that it doesn't go past its bounds.

I'm assuming this is what Bropedio did in BNW to make weapon switching not add a bunch of Healing Shivs to the inventory or whatever.

I assume that this Tool bug is also going to have implications on weapon switching, Stealing, and Metamorphing, and that cracking Rods will also help escalate it, though I haven't confirmed any of this.

(actually, scratch that bit about weapon switching at the end there, forgot it doesn't use the item queue in vanilla, that's a BNW thing)

So the problem is actually a vanilla bug that has nothing to do with the code you have.  The buffer of 'item to add back into the inventory' wasn't cleared enough by Vanilla, which causes it to overflow before it is supposed to and add garbage items.

There are two different buffer position markers, 64DA and 64DB. 64DA tracks the buffer position to add the next item to, and 64DB tracks the buffer position to start at when copying to inventory on each turn
Usually, it's something like this:

1. 64DA and 64DB both point to 0.
2. Steal from enemy, store in slot 0. Now 64DA points to 1
3. On next turn, start at 64DB (0) and copy to inventory until you see 0xFF (empty buffer slot)
4. Now 64DA and 64DB both point to slot 1

But since vanilla forgets to clear 0x41-0x50 in the buffer, at some point step 3 will behave unexpectedly
It will see a non-0xFF value in the buffer, and will keep copying until it reaches another 0xFF, which is likely to be at the slot it started, which will be at least 1 behind 64DA
Since 64DA is ahead, the items it writes from then on will never be seen by 64DB ,since it's stuck on a 0xFF
The bug will resolve if another 16 items are added to the buffer between those points in time, as 64DA will finally catch up to 64DB.
This presumes that the other item-on-reserve issue has been fixed already -- that one happens in C2, and is related to reserve items being overwritten under some conditions (at $32F4,X)

Here's the solution.  From the original version of your tool break code (NOT the code block that I shared with you)

(1) Apply Imzogelmo's Multisteal fix, which I've attached to this post.
(2) Go to $C112D5 in a hex editor and change the value from E0 40 00 to E0 50 00

And that's it.  Give it a try; as far as I could tell this was the only change necessary to make the code work.  Presto, Divergent Paths' "sketch bug" be squashed, thank you Sir Newton Fig and Bropedio.