Breakable Tools - Need Help - Printable Version +- FF6 Hacking (https://www.ff6hacking.com/forums) +-- Forum: Discussion Forums (https://www.ff6hacking.com/forums/forum-5.html) +--- Forum: Magitek Research Facility (https://www.ff6hacking.com/forums/forum-9.html) +--- Thread: Breakable Tools - Need Help (/thread-4124.html) |
RE: Breakable Tools - Need Help - Gi Nattak - 07-06-2021 I can confirm the same results as well, bugged items still added to the inventory on the 13th non-break usage. RE: Breakable Tools - Need Help - C-Dude - 07-06-2021 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 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. Sir Newton Fig Wrote:So here's the problem as far as I can tell 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. Bropedio Wrote: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 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. RE: Breakable Tools - Need Help - SirNewtonFig - 07-07-2021 ^ I just noticed that C-Dude's post about the fix to this issue got merged into his previous post, so I'm just gonna drop this little note in here to make sure @PowerPanda gets alerted about it. RE: Breakable Tools - Need Help - PowerPanda - 07-07-2021 Thank you so, so, sooooo much. One question. The Multi-Steal fix conflicts with other changes that I have made in C2/399E to C2/3A0E. Is it just the custom function that I need, which in the readme is C2/6565? RE: Breakable Tools - Need Help - Bropedio - 07-07-2021 As far as I know, the multisteal patch is not necessary to fix the bug you were encountering. All the multisteal patch does is allow multiple steals per turn. There *are* some underlying issues with reserve items that can cause issues, but I don't think those underlying issues are addressed with the multisteal patch. I'm not familiar with your tool patch, but some potential issues to test might be: 1. Edgar uses Tool, it breaks. Edgar dies, is revived, then uses an Item. 2. Edgar has thief knife equipped, breaks a Tool, then counters (and steals an item) before Tool is returned to inventory. Again, I'm not familiar with how your Tools patch works, but if it's using the reserve item byte `32F4`, these situations may cause the Tool to be lost. RE: Breakable Tools - Need Help - Subtraction - 07-07-2021 I know it's not the point of this thread, but there's no way this is correct: Code: JSR $4B5A $4B5A sets the accumulator to a random number from 0–255. ANDing that with 42 doesn't give you a 1/42 chance. It gives you a 1/8 chance. 2A has 3 bits that are 1. ANDing sets all bits in the accumulator to except those 3. If the accumulator is now 0, the branch will be taken. The chance of those 3 bits being 0 is 1/2^3 = 1/8. ANDing like this only works when the denominator is a power of 2. If you actually want a 1/42 chance, you need to do this: Code: LDA #$2A RE: Breakable Tools - Need Help - SirNewtonFig - 07-07-2021 (07-07-2021, 10:31 AM)Bropedio Wrote: As far as I know, the multisteal patch is not necessary to fix the bug you were encountering. All the multisteal patch does is allow multiple steals per turn. There *are* some underlying issues with reserve items that can cause issues, but I don't think those underlying issues are addressed with the multisteal patch. I'm not familiar with your tool patch, but some potential issues to test might be: The breakable tools functionality in DP uses the routine at `$4D89` for the Tools command to put the Tool on reserve when the command is entered. Then, during the execution of the tool action, it does a series of checks to determine if the tool breaks. If it does, it dummies out the item ID for the reserve item. Unless there are measures added in other places to flush the reserve item to the add item buffer (e.g. if character dies, before proccing Steal on a counterattack, others?), it seems to me it would indeed be susceptible to reserve item interference as you describe. Maybe a `JSR $62C7` flush somewhere in the neighborhood of `$C2/06E4` would be an apt fix to the case of a reserve item getting clobbered by getting KOd? Not sure what the best fix would be for a Mug counter though. Seems like you're familiar with some fixes to these issues already though, Bro – what's your recommendation here? That all said, according to the documentation, DP also makes it possible to Steal both the common and rare steal from each enemy, so the Multi-Steal fix, if not already in use, should be relevant. Otherwise, if Locke is dual-wielding and Mugs something, triggering two successful Steals will clobber one of the steal attempts (and potentially display the wrong message for one of them). @PowerPanda, if you would like to share your modified `$C2/399E`, maybe we can help you figure out how to splice the Multi Steal adjustments into it? RE: Breakable Tools - Need Help - PowerPanda - 07-07-2021 So, instead of using the Multi-Steal Fix, I'm using Assassin's "Recapture the Glory", which treats each steal attempt with dual weapons as a separate attempt, with each one getting weapon special effects, counter-effects, etc. Because of my changes to Steal, plus the way Recapture the Glory handles things, I actually didn't (previously) see a need for the Multi-Steal fix. I am still hesitant to change the Steal special effect itself, since it is working exactly as I want it to. My steal changes are all in-line, and are as follows. I'm sorry it's not commented code, and that it's straight hex. Quote:;Presented with the original value, and the value to change it to underneath, marked with "->" And once again, thank you everyone for the help. I'm burned out on hacking, but I need to get this bug fixed before I can go into hibernation. EDIT: Attaching "Recapture the Glory" RE: Breakable Tools - Need Help - C-Dude - 07-07-2021 I'll annotate the raw hex so that the assembly programmers can work with it. Code: Vanilla Other than keeping the common item from being overwritten, I can't quite follow what your code is going for here. I'm going to look at Imzogelmo's multisteal fix and see if the two can be blended, though. RE: Breakable Tools - Need Help - Bropedio - 07-07-2021 Code: hirom This is the patch I have in BNW to address the reserve item issue. I'm not sure whether it would work with DP right out of the box, but it might (assuming you update the freespace address). Edit: On second thought, this will definitely not work out of the box for DP, since it uses BNW's "free turn" handling on successful steal. But the code could be tweaked pretty easily to adjust back to vanilla. |