Yeah, It just crashes you right to the desktop. Not sure if it's the way it's selected or what.
Also, which of these 3 are selectable:
Bow
Arrow
Bow and Arrow (which kinda makes th 2 above obsolete don't it?)
More testing is required.
If this is fixed in 142, lock this thread.
Yea... the Bow is broken, but I might also add that I am using the "Choosing Items Minish Cap/Oracle Games style" quest rule, but one of the beta testers for my quest reported that when he tried to use the bow and arrow, Link swung his sword instead.
Was he pressing the correct button? (An absurd proposition, but still...)
P.S: I'm not really able to verify this...
EDIT: OKay, now I know what's wrong.
So what WAS wrong? I hope to be a dev someday, but I need to learn C++.
Since you asked:
* On the subscreen, you used the "Bow & Arrow" subscreen item instead of the "Bow" and "Arrow" items. Now, the tile and name of the Bow & Arrow subscreen item differs from the Arrow subscreen item.
* The problem is, the subscreen display routine can't see what the currently selected subscreen item is - it can only see what the currently selected equipment item is. (For both items, the equipment item is "Arrow", "Silver Arrow", or "Golden Arrow"😉 This variable is used in many places and is called "Bwpn".
* So, the subscreen cursor routine must pass this information onto the subscreen display routine. It does this by checking if the subscreen item is "Bow & Arrow" instead of just "Arrow" and, if so, adds the hexadecimal number 0xF000 (decimal: 61440) to Bwpn. (This is, if anything, a kludge, owing to the overloading of a variable's tasks)
* The problem is that Bwpn is used in a number of locations, among them here:
if (DrunkrBbtn()) { btnwpn=getItemFamily(itemsbuf,Bwpn); dowpn = Bwpn; }
else if (DrunkrAbtn()) { btnwpn=getItemFamily(itemsbuf,Awpn); dowpn = Awpn; }
This is from Link.cpp, and is used to find which weapon to activate when Link presses the A or B button. The problem is that, if certain conditions are true, Bwpn and/or Awpn are 61440 larger than what they ought to be.
* The solution (or so I think) is to remove the 0xF000 by applying
bitwise AND in all cases where it's required:
//&0xFFF removes the "bow & arrows" bitmask if (DrunkrBbtn()) { btnwpn=getItemFamily(itemsbuf,Bwpn&0xFFF); dowpn = Bwpn&0xFFF; }
else if (DrunkrAbtn()) { btnwpn=getItemFamily(itemsbuf,Awpn&0xFFF); dowpn = Awpn&0xFFF; }