Let's Play Majora's Mask Super Wrong

The Something Awful Forums > Discussion > Video Games > Let's Play! > Let's Play Majora's Mask Super Wrong

ManxomeBromide: Jan 29, 2009; old school

First: What. :psyduck:

Second: The Walrus and the Carpenter were luring the oysters to their deaths.
Third: I actually never played Majora's Mask, though I have picked up the basics of the structure and such via osmosis over the years. How confused am I going to be?
Third-and-a-half: Going by what we've seen so far, pretty confused, but it's an entertaining train-wreck nevertheless.

# ¿ Oct 16, 2015 07:28

Adbot: ADBOT LOVES YOU

# ¿ May 21, 2024 05:25

ManxomeBromide: Jan 29, 2009; old school

I neglected to mention this at the time, but I did a replay of Mega Man 2 recently and I actually got to use the glitch that came up earlier in this LP, so thank you, LP Majora's Mask, for improving my Mega Man 2 game.

Spoiler, if we're still doing that: Metal Blade is so overpowered and so cheap using the glitch made no real difference except on one stage.

# ¿ Nov 16, 2015 05:45

ManxomeBromide: Jan 29, 2009; old school

Reverse Bottle Adventure has been boggling me ever since I first saw it in the OoT Super Wrong run. I finally sat down and tried to replicate what kind of logic error produces this kind of crazy effect.

It turns out it's super-elegant. I built a little reverse-bottle simulator in C to fiddle with stuff, and found values that look very reasonable for similar (occasionally literal) bugs.

Let's take a set of items...

code:

enum { NOTHING, KOKIRI_SWORD, MASTER_SWORD, KOKIRI_TUNIC, KOKIRI_BOOTS,
       EMPTY_BOTTLE, RED_POTION, BLUE_POTION, POE_BOTTLE, FISH, BUGS,
       NUM_ITEMS };

Each of these is a byte value; NOTHING is 0, KOKIRI_SWORD is 1, and so on. These are constants in the code, but they might not actually live in a table anywhere explicitly; it might just be that any time you needed to talk about an empty bottle you'd just see the number 5 in the code. (Well, in the real code, an empty bottle is 20, but this is a stripped-down example.)

The inventory itself is an array of bytes too. For our simplified example, the slots might just be bomb count, bombchu count, and number of bottles. The only way I can make sense of the bottle adventures is if the B and C buttons are themselves "inventory slots" that can contain arbitrary items.

Now, when you use something on the C button, you have to update not just that item on the C button, but also the version of it that is actually in the inventory. I am postulating three "shadow" inventory slots right after the C button items which have, not items, but an index into the inventory slot index. So the full inventory looks something like this:

code:

enum { B_BUTTON,
       C_LEFT, C_DOWN, C_RIGHT,
       C_LEFT_BACKER, C_DOWN_BACKER, C_RIGHT_BACKER,
       BOMB_COUNT, BOMBCHU_COUNT,
       BOTTLE_1, BOTTLE_2, BOTTLE_3, BOTTLE_4,
       NUM_INV_SLOTS };

So normally, if you get your first bottle, there's be a command in the code like:

code:

inventory[BOTTLE_1] = EMPTY_BOTTLE;

Also, once you equipped it to, say, C-Down, you'd write EMPTY_BOTTLE to the C_DOWN slot and BOTTLE_1 to the C_DOWN_BACKER slot. Those three values hold indexes into the inventory array itself, not an item descriptor.

Okay, so far so good. But when you mess with bottles, you need to go update stuff back in the inventory. I think they must have done something like this for setting bottle contents:

code:

void set_bottle(int button_pressed, int bottle_contents)
{
    inventory[button_pressed] = bottle_contents;
    inventory[inventory[button_pressed+3]] = bottle_contents;
}

Because we list the button-backers in order, we can do math to find it as long as the button pressed was a C button. But look what happens if the button_pressed argument is B_BUTTON here. There isn't a backer slot for the B button because it was never intended to hold objects whose state needed to generically reflected in the inventory. It ends up one short and reads the item value in C-Right as if it were an inventory index. That's the core visible behavior of bottle adventure and it falls right out of that second line.

Then I decided to have some fun with it and do various Super Wrong things with my simulated inventory. It seems to check out:

pre:

Initial conditions:
B: Kokiri Sword; C Left: Nothing; C Down: Bottle of bugs; C Right: Bottle of fish
0 bombs, 0 bombchus
Bottles: Nothing, Bottle of bugs, Bottle of fish, Nothing

After emptying bottle on C-Down:
B: Kokiri Sword; C Left: Nothing; C Down: Empty bottle; C Right: Bottle of fish
0 bombs, 0 bombchus
Bottles: Nothing, Empty bottle, Bottle of fish, Nothing

Got bugs on B:
B: Bottle of bugs; C Left: Nothing; C Down: Empty bottle; C Right: Bottle of fish
0 bombs, 0 bombchus
Bottles: Nothing, Empty bottle, Bottle of fish, Nothing

After emptying bugs with fish on C-Right:
B: Empty bottle; C Left: Nothing; C Down: Empty bottle; C Right: Bottle of fish
0 bombs, 0 bombchus
Bottles: Empty bottle, Empty bottle, Bottle of fish, Nothing

Catching a poe on C-Right:
B: Empty bottle; C Left: Nothing; C Down: Empty bottle; C Right: Bottled Poe
0 bombs, 0 bombchus
Bottles: Empty bottle, Empty bottle, Bottled Poe, Nothing

Catching bugs with poe on C-Right:
B: Bottle of bugs; C Left: Nothing; C Down: Empty bottle; C Right: Bottled Poe
0 bombs, 10 bombchus
Bottles: Empty bottle, Empty bottle, Bottled Poe, Nothing

Looking good! But this suggests something else.

What happens if you manage to get something with ammunition, like, say, Deku Nuts, on B? When it updates the new ammunition count when you fire one, it seems like it should produce an RBA-like effect. Is this possible? Or are bottles special here?

# ¿ Nov 23, 2015 09:28

ManxomeBromide: Jan 29, 2009; old school

Suspicious Dish posted:

Ammo values are not stored as part of your inventory slot. It's stored in a separate value, and the code for each weapon simply hardcodes that pointer address. The code for the bottle drop update is the only place with the offset bug.

Thinking about it a bit more, that does make sense. Bottles are unique in that (a) there are more than one of them and they are functionally identical and (b) they can take on a variety of values. Meanwhile, if you're firing a Deku Nut, you can just say "hey, I fired a Deku Nut. I think I'll go update inventory[DEKU_NUTS]." There's no equivalent to "Well, one of my four empty bottles got bugs in it, and I have to put them in the correct slot."

# ¿ Nov 23, 2015 09:54

ManxomeBromide: Jan 29, 2009; old school

That was a Hell of a ride. I'm glad I got to come along for it.

This will make my eventual attempt to play Majora's Mask for real a lot more surreal.

# ¿ Dec 10, 2015 06:08

ManxomeBromide: Jan 29, 2009; old school

icesoldier posted:

Gonna try throwing another word substitution in there and voting "I say".

I like "I say".

# ¿ Dec 18, 2015 09:16

Adbot: ADBOT LOVES YOU

# ¿ May 21, 2024 05:25

ManxomeBromide: Jan 29, 2009; old school

The discussion of familiarity with motion in different games struck home pretty hard for me; I grew up on Mega Man and I definitely have trouble in Super Mario or 3D Zeldas.

I do have to say though that your Zora handling is actually really great; seeing you blaze around and corner with Zora form is something that makes me want to play Majora's Mask more than really anything else I see about it.

# ¿ Feb 24, 2016 10:57

The Something Awful Forums > Discussion > Video Games > Let's Play! > Let's Play Majora's Mask Super Wrong