Issue with the GetName Item Bug Fix

[AlmightyCoon]

When using "GetName applies to all names rather than only item names" Bug Fix, a new bug was created that crashes game.

If multiple HM/TMs, or just HMs, are the only names shown in item menu the game will crash after selecting to use one HM then canceling & attempt using another HM/TM; usually most common after withdrawing from PC & TM/HMs are near the bottom of Item Menu.

Example : Item Menu Reads HM01, HM04, Cancel, Space(from bottom of menu); the game will crash when selecting "Use" for either HM then backing out to attempt to use the same or other HM.

Item Menu can Read HM01, HM04, TM01, Cancel; or HM01, HM04, TM01, TM32; or seems to be Any Variable of HM/TM Mixes, but HMs seem to increase chance of crashing, especially after PC withdraws.

[Narishma-gb]

The crash seems to be caused by an oversight in DisplayListMenuIDLoop, during the call to GetName.

https://github.com/pret/pokered/blob/59da8c8122ebb8fcc334d4e5421e4fb333eea730/home/list_menu.asm#L142-L148

When pressing A inside a list menu, the selected entry name is copied via GetName to wNameBuffer (if it is a machine, GetMachineName does the copy). Right after that, the contents of wNameBuffer is transferred to wStringBuffer via a call to CopyToStringBuffer.

https://github.com/pret/pokered/blob/59da8c8122ebb8fcc334d4e5421e4fb333eea730/home/list_menu.asm#L160-L162

However, DisplayListMenuIDLoop does not set wNameListType before calling GetName. This is fine in most situations, because the older value is usually ITEM_NAME, set when the list menu was generated. Except when: the visible menu entries are only TM/HMs (GetItemName will not update wNameListType when requesting the name of a TM/HM), and we have previously selected one these for use, calling GetMoveName to display machine move, and setting wNameListType to MOVE_NAME).

In this case GetName, with the bug fix applied, will search for a string with an index $c4 or above, starting at 01:$4000, and will return some random data in wNameBuffer. CopyToStringBuffer having no overflow protection, will copy this data into wStringBuffer until a chance "@" encounter. Sometimes it will be an actual string with a small enough size, and the crash does not happen. Otherwise, since the two buffers are less than 500 bytes apart in WRAM, CopyToStringBuffer will soon read again the same data it's been writing, and proceed to destroy the stack.

A possible fix is to add these 2 lines in DisplayListMenuIDLoop:

.skipGettingQuantity
	ld a, [wCurItem]
	ld [wNameListIndex], a
+	ld a, ITEM_NAME
+	ld [wNameListType], a
	ld a, BANK(ItemNames)
	ld [wPredefBank], a
	call GetName
	jr .storeChosenEntry

It should stop the crash from happening, and hopefully not break anything else (we are guaranteed to have a list of items if this part of the code is reached).