Hey, I was wondering if you could give me a hand tracking down another bug that has me stumped because I can't replicate it and I can't seem to figure out how it could even be happening. Someone mentioned something similar to this during beta testing, they said it only occurred in VBA-M and stopped when they went to VBA, but this user said they are using normal VBA.
Here is a clip of it happening in their LP series. It seems as though on that floor, when they talk to a trainer, they are warped back to the last warp they entered from before the battle starts, but I can't find anything that should be calling any sort of warping code in the TalkToTrainer routines. Any ideas where to look? At this point I'm pretty sure it's too late to get a save-state of the bug, since they've already recorded another episode or two since then.
Te queria preguntar algo, te acuerdas que hace 1 año masomenos te pregunté como podria hacer para cambiar los niveles de los starters que te regalan en Yellow? Pues bien, me dijiste de buscar la rutina "GivePokemon". Recien hace unos días la identifiqué con el GBASM Editor y leyendo el Red diassembly a la vez. Intenté cambiar SOLO el nivel de Charmander y no pasó nada. Intenté lo mismo con Lapras, pero tampoco no se aplicaron los cambios. Segun tu, qué podria estar haciendo mal?
I thought you said when a TM called it, that address held the item number instead of list number, so if that was the case a TM would never accidentally be read as MOVE_LIST. But that was probably just another misunderstanding from earlier when we were confused. I'll try again to put the other stuff in instead.
As of right now, the TMs no longer seem to be crashing when I load that save state in the updated rom, and Move IDs higher than HM01's ID load correctly. And just to check, it appears that Pokémon names above that value load correctly as well.
Great. I apparently don't have room to add that tiny piece of code there even after removing the old hacky thing.
cp HM_01 ; are we dealing with a TM or HM?
jr c, .skipHM
ld hl, wExtraFlags
That's what I was adding between lines 1506 and 1507, and then I made the start of GetName look like:
GetName:: ; 376b (0:376b)
; [wd0b5] = which name
; [wNameListType] = which list
; [wPredefBank] = bank of list
; returns pointer to name in de
bit 5, [hl]
res 5, [hl]
jr z, .noTM
cp HM_01 ;it's TM/HM
.noTM ; Return here if not an item
Guess I'll have to work around it again. I hate how crowded bank 0 gets. The code looks like it would work if I could just fit it in, anyway.
Ah right, whoops. Yeah checking a would work but resetting it there would be pointless lol.
Just to clarify what you were telling me about the problem, I'd need to go to the item menu routine we found earlier and set it there based on the Item ID, or would I be able to just set it during the ItemUseTMHM routine and not have to worry about checking the item ID beforehand.
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.