Crystal_

What comes to my mind is to take the routine that calls it with the TM, and add something like

ld hl, wExtraFlags
set 4, [hl]

before the call to the routine, then I could replace the existing check for which list it is with something like

ld a, [wExtraFlags]
bit 4, a
res 4, a
jr z, .noTM

or something. Not sure if there is a better way that's just the first thing to come to mind while brainstorming.

Hmm, ok. Well, I guess we'll have to come up with a new way to keep moves from loading TM names while not messing that up.

Not sure what would be causing it to have the wrong value in that save state, but at least we know what to debug it would seem. I'm temporarily unable to do much because I'm going to dinner with family, but I'll try to get on that when I'm back at my computer. I really appreciate all the help.

The version of the hack you got from the link should be identical to the release. So the bug you identified is one I accidentally added a few hours ago. I'll revert that back, and I guess we can go on looking for something else, though who knows where it could be. I'm wondering if maybe it is somewhere in the start_submenus area, since I had to tweak that a while back when I was editing the Town Map to use the Gen 2 format instead of Gen 1, so I had to make sure it re-loaded the map when you exited, otherwise it would load the map with garbled Town Map tiles because it had no reason to reload the tileset. I'm pretty sure that was all done while I was already using github though so we should be able to track down commits if it was related to that.

Welcome to my life lol.

And yeah, that's what confuses me. It looked fine originally, but people have been reporting this bug since Beta 1. I've just never been able to duplicate it and couldn't find any reason why it would happen. And the copy of the rom he sent still contains the original version of the code, because I didn't change it to what is on github until after Beta 2 was released, while trying to fix the issue.

But that looks like the code I had originally should have worked, but clearly it didn't. Because the issue you found was with a commit I made after Beta 2 was released, trying to fix this issue (incorrectly) and the issue has been around since Beta 1, when I originally added that change to prevent move names from being loaded incorrectly.

So originally, I had this:


Which at least looks like it should have made the check while not loading the wrong ID into register a before the jump. However, people still claimed to get that error just like they do now.

Not sure why I wrote "compare to move list" in the comment when I was actually checking the item list, but probably because at the time I was just worried about getting move names to stop loading as TM names.

Here is the commit where I changed it from what I originally was using and made it what it is now. Mind you, the bug showed up both places.

https://github.com/TheFakeMateo/RedPlusPlus/commit/b86dd2ff310087ee735f5cbcc5cef29a454545aa

I originally had it done differently, and I changed it to that to try and clean it up, so I can see where the issue is coming in now. It still has the wrong ID in register a so of course it crashes.

Like I just said, without that, the check for TM/HM IDs applies to every list type, and it makes a lot of the new moves I added load incorrect names.

And if it's broken, shouldn't it like, you know, not correctly load TM names at all? I'm confused.

Did I check for the wrong value or something? Without that, moves with high IDs load their name as TM so-and-so instead of the proper name, because that HM check is only supposed to apply to item lists, but it applies to every list instead.

I'm also beginning to think it might save some headaches to just do it the Gen 2 way and actually list TM names as normal item names, so there are less additional checks to cause problems.

This is what I ended up doing: https://github.com/TheFakeMateo/RedPlusPlus/commit/a7e3a88219e1d859ce07ad2e103d15be7a8b6f92

It seems to work properly. Instead of trying to hardcode an address, I just looked at what came immediately after the space it uses as a buffer and set it based on that. Don't want to cause myself further headaches down the road if/when something shifts. So far it seems to be fixed, just like you were noticing. I really appreciate the help. Thanks man.

I was thinking that it would be related to GetName or one of the associated routines at first, which is why I made this commit: https://github.com/TheFakeMateo/RedPlusPlus/commit/b86dd2ff310087ee735f5cbcc5cef29a454545aa

Thinking that maybe the weird way I'd done that at first was sometimes causing issues, but even after applying that fix, the crashes happened exactly the same, so clearly that wasn't the actual issue, but it probably needed doing anyway just to be cleaner.

Yeah, I figured that would be the case, but wasn't sure if maybe it was caused by something else that you might have just already run into and known about. Something like "oh it's because you expanded this" or "this unrelated area has a hard-coded size" or something that would cause problems in a hack but work in vanilla.

I can see if he can give me a save state, but like you say all I can do is blindly use TMs and hope for a crash which so far hasn't seemed to happen for me.

Any idea what could be causing the issues people are having with TMs? I haven't altered the TM routines at all, but people are claiming that "using a bunch of TMs makes the game crash". However, when I try it with a pack full of TMs, I can't replicate it to debug and I'm not noticing anything in any of the TM routines that should be causing it. Not sure if you've run into anything like that to have any advice or not, but thought it was worth bringing up just in case.

The thing is, I don't want the player to turn that early because it doesn't feel official. I want him to turn once the trainer walks up to him, so I would rather figure out what I need to do in order to have it work this way. I tried editing the part that stops you from walking while a trainer is walking up so that it disables all buttons, then spammed A when I encountered that trainer, and I faced him as I was supposed to, so I think that has it worked out now.

Hmm, on second thought, I think I see an issue with it myself. Since it doesn't appear to lock the buttons until it calls the FaceEnemyTrainer routine, you could still conceivably press something while they are walking up.

I would need to go up a little bit and change CheckFightingMapTrainers and have it lock the A button as well, since it currently only locks the directional buttons.

This seems to fix the issue in question, by preventing you from pressing anything until after you have already turned to face them. But I wanted a second opinion in case you noticed any unintended side-effects this might cause.

https://github.com/TheFakeMateo/RedPlusPlus/commit/76503688ec8ffbd7de0414b989043388574cf9d3