Cave Story 3D inventory glitch theory

>> Technical explanation of the inventory glitch in Cave Story 3D, with some examples <<

Most of this is based on descriptions of the glitch that I read online, as well as
studying the source code of CSE2 (a Cave Story freeware decompilation -- though, note that
freeware Cave Story doesn't have this glitch). As such, there's a chance that this might
not be 100% accurate (and I'm definitely oversimplifying some of the explanations), but
it's hopefully at least pretty close to what's going on.

Also, shoutouts to Amber for answering all of my questions and helping me confirm that
all/most of this is actually accurate, without me having to get the game myself >:)

(Already intimately familiar with Cave Story modding? Feel free to skip to the
"THE INVENTORY GLITCH" section starting on line 205.)

=== THE BASICS ===

Stage data in vanilla Cave Story is divided into several files:

Map data (irrelevant for our purposes):
bk[bg].pbm       -- Basically a renamed .bmp image used as the background
Prt[tileset].pbm -- Contains the visual appearance of each of the map tiles
[tileset].pxa    -- Tile attributes (solid block, water block, etc.)
[map name].pxm   -- Tilemap (the actual layout of the stage)

NPC data (i.e. anything that's not a map tile):
Npc[name].pbm    -- NPC spritesheet
[map name].pxe   -- NPC info (location, properties, etc.)
[map name].tsc   -- TSC (Text SCript), specifying the events associated with each NPC

Cave Story 3D has all of these same files (except, the ".tsc" files were renamed to ".sjs"
files for whatever reason). Additionally, CS3D also has some other ".n3ddta" and ".n3dhdr"
files that I assume contain the 3D models for everything.
(Fun fact: From what I've been told, it's possible to take the data files from the CS3D
ROM (aside from the .n3d* ones) and stick them directly into the original freeware engine
(well, after renaming "sjs" back to "tsc", I assume).
Apparently, it actually (mostly) works and plays like what Cave Story 3D would've been
like if it wasn't 3D and used the original assets instead of 3D models.)


In particular, the thing to take away here is that the *properties* of each NPC in a
given stage are stored separately from the actual *behavior* of that NPC. The former are
loaded with the stage's .pxe file, while the latter is loaded with the stage's .sjs file.
(Some things, like enemy AI, are also hardcoded into the game engine itself.)

As an example, consider the life capsule in First Cave (which is just called "Cave" in
the data files).
Cave.pxe would contain the following info about that life capsule:
-- It is located at (6, 24)
-- It is of type 32 (Life Capsule)
-- The flag number associated with it is 304
-- The event number associated with it is 400
-- It has the following additional properties:
   * Player can press down to interact with it (doing so runs event 400 in the TSC)
   * Disappears once its flag number is set (usually happens via TSC)

Cave.sjs contains the following TSC:
    #0400
    <PRI<SOU0022<DNP0400<CMU0016
    <MSG<GIT1006
    Obtained a Life Capsule.<WAI0160<NOD<RMU<ML+0003
    Max life increased by 3.<NOD<END
In English:
#0400                      -- This is event number 400
<PRI (PRevent Interaction) -- Freeze the game and lock player controls
<SOU0022 (SOUnd)           -- Play sound #22 (some kind of click sound)
<DNP0400 (Delete NPc)      -- Delete the life capsule (also sets its flag number, 304)
<CMU0016 (Change MUsic)    -- Change the music to #16 (life capsule jingle)
<MSG (MeSsaGe)             -- Open a message box
<GIT1006 (Graphic ITem)    -- Display icon #1006 (life capsule) above the message box
Obtained a Life Capsule.   -- Text to be displayed
<WAI0160 (WAIt)            -- Wait for 160 frames
<NOD                       -- Wait for player to press jump or shoot
<RMU (Restore MUsic)       -- Resume the last song that was played
<ML+0003 (Max Life +)      -- Increase the player's max HP by 3
Max life increased by 3.   -- More text to be displayed
<NOD                       -- Wait for jump/shoot to be pressed
<END                       -- End of event (restore normal game operation)


=== TSC LOADING ===

The game contains a buffer in its memory containing a copy of the TSC that it's currently
working with. Each time a new stage is loaded, the game first copies the contents of
"Head" into that buffer, then it loads the specific TSC file for that stage after that.
The "Head" script isn't super important for understanding the inventory glitch, but if
you're curious what it is, it contains events that are common to many areas in the game.
For Cave Story 3D, it begins like this:
    #0000
    <END

    #0001
    <PRI<MSG
    Empty.<NOD<END

    #0016
    <PRI<MSG
    Do you want to save?<YNJ0000<CLR<MSG<TURDo not turn the system off or remove
    the Nintendo 3DS Game Card
    <WAI0020<FL+0431<SVP<CLR
    Game saved.<NOD<END

    #0017
    <PRI<FLJ0201:0018
    <LI+1000<SOU0020<AE+<MSG
    Life refilled.<NOD<END

    #0018
    <PRI
    <LI+1000<SOU0020<AE+<MSG
    Life and missiles refilled.<NOD<END

    #0019
    <KEY<MSG
    Do you want to rest?<YNJ0000<FAO0004<CMU0000<WAI0020<CLR
    .....<NOD<CLO
    <WAI0050
    <LI+1000<SOU0020<MYD0002<MSG
    Life refilled.<NOD<CLO<RMU<FAI0004<END

    #0030
    <PRI<FLJ0202:0032<FLJ0201:0031<FL+0201<GIT0005<AM+0005:0010
    <CMU0010Obtained the Missile Launcher.<WAI0160<NOD<RMU<CLR
    The Missile Launcher is a powerful
    weapon, but it has limited ammo.<NOD
    Collect additional ammunition
    from fallen enemies.<NOD<END
    [...more stuff that I cut out...]

TSC events are always arranged in order by increasing event number in the script files.
After loading the Head script and the stage-specific TSC file into the TSC buffer, the
game writes a "null" character (essentially a blank character) to denote the end of the
script. This character is used in several places in the script engine to tell the game not
to continue reading past that point. (Spoiler alert: With the inventory glitch, you can
sometimes get the game to read past that null character regardless...)

=== TSC PARSING ===

TSC parsing is handled in two separate areas of the game logic:
(1) When a request is made to run TSC event number X, the game makes the following
    preparations:
    (a) The game sets an internal flag to indicate to the rest of the game logic that it
        is currently running a TSC event. A few other (mostly uninteresting) internal
        game variables relating to TSC execution are reset at this point.
        In CS freeware (and a few early Nicalis ports?), the player's i-frames are also
        reset here. (This is what allows Chako skip to be possible without needing the
        Map System in these versions of Cave Story.)
    (b) The game looks for the start of the event in the TSC buffer: Starting from the
        beginning of the TSC buffer, the game scans one character at a time, looking for
        the "#" symbol. When it encounters a "#" character, it reads the next four
        characters as a number and compares that number to X.
        * If that number is equal to X, then the game stops scanning and moves the "scan
          cursor" (so to speak) to the next line. The event is now ready to be parsed and
          executed.
        * If that number is bigger than X, then we've passed where the event should have
          been in the TSC but didn't find it. In this case, the game stops scanning and
          returns an error status (leaving the scan cursor in place).
        * Otherwise (if the number is smaller than X), the game continues scanning.
        If the game at any point encounters the null character used to mark the end of the
        script, the game stops scanning and returns an error status (again, leaving the
        scan cursor in place at that null character).
    Note that this initial step doesn't actually run anything; it just places the scan
    cursor at the start of the event and leaves it like that.
(2) In a separate part of the game code, the game checks every frame to see if the
    "currently in a TSC event" flag is set. If it is, then it starts parsing and executing
    the data in the TSC buffer, starting from wherever the scan cursor left off from.

An important thing of note here is that even though step (1) can return an error status
(if it couldn't find the requested event number), the game doesn't actually bother to
do anything about it if that happens. (In fact, the error goes completely unnoticed -- the
game doesn't even care to check for it.)
This means that the game also doesn't clear the "currently in a TSC event" flag when that
happens, so step (2) will start reading from wherever the scan cursor happens to be and
execute whatever TSC it finds in the buffer at that point.
Often, this just means that the next-highest event number in the TSC buffer gets executed,
but if the initial scan errored out because it reached the null character at the end of
the script, then the game will start reading past that null character and beyond the end
of the current stage's script, which can lead to some crazy and unpredictable results.
(As we'll see below.)

=== THE INVENTORY MENU ===

The inventory has its own script associated with it, called "ArmsItem".
When the inventory is opened, the game does the following:

(1) It stores the name of the currently-loaded script, so that it can be reloaded upon
    closing the inventory
(2) It loads the contents of the ArmsItem script into the TSC buffer
(3) It enters a separate game loop that handles everything that happens within the
    inventory. Within that game loop, it runs TSC events as follows:
    * When you cursor over a weapon, it runs TSC event number (1000 + [weapon ID]).
      If there's no weapon to be selected, then it just runs event #1000 ("No weapon").
    * When you cursor over an item, it runs TSC event (5000 + [item type ID]).
      If there's no item in that spot, then it just runs event #5000...that said, it's not
      actually possible to cursor over an empty item, so you never get to see this :P
    * When you select an item, then it runs TSC event (6000 + [item type ID]).
(4) Upon closing the inventory, the game reloads the previously-loaded script, according
    to the name that it stored in step (1) and the process outlined in the previous
    section.

Note that the only thing that gets shuffled around here is the script that's loaded into
the TSC buffer -- other aspects of the current stage you're in (including the .pbm
background and map tiles, the .pxa and .pxm map data, and the .pxe NPC data) are
untouched by opening and closing the inventory.

=== THE INVENTORY GLITCH ===

The inventory glitch works by going into a map (call it Map B), opening the inventory,
then pause-exiting out and loading any save file into a different map (call it Map A).
The result is that Map A will have many NPCs that appear to behave as if you were in
Map B.
What exactly happens is the following:
(1) Upon opening the inventory, the game stores the name of Map B so that it can reload
    its TSC upon closing the inventory.
(2) After pause-exiting out and loading a save file in Map A, the game (correctly) loads
    Map A and its TSC file according to the process described previously.
    However, the game (incorrectly) loads with the inventory still open, meaning that
    moving the cursor around in the inventory will run TSC events (as described
    previously) but using Map A's TSC rather than ArmsItem's.
    (This can lead to some pretty glitchy results, especially considering that the event
    numbers being run here are all fairly high-numbered, and most stage TSCs don't use
    event numbers that high.)
(3) After closing the inventory, the game loads the "previous" script from before opening
    the inventory. Apparently, this also doesn't get reset when exiting out of the game,
    so the game is still remembering that you were in Map B before opening the inventory,
    hence it loads Map B's script.

The end result is that you are now in Map A, with Map A's map data and NPC (*.pxe) data
loaded, but with Map B's TSC events loaded.
Let's look at a few examples of how this can wreck havoc:

Example #1: Getting the (normally unobtainable) Beast Fang

The Beast Fang is hidden in an unreachable location in Yamashita Farm. We can get it
as follows:
(1) Go to the Egg Observation Room and save.
(2) Go to Yamashita Farm, open the inventory, and exit out.
(3) Reload your save file to go back to the Egg Observation Room. Open the treasure chest
    that normally contains the Missile Launcher, to get the Beast Fang instead.
Why does this work? Upon reloading the game, the game loads the data for EggR (which is
the internal name for the Egg Observation Room), including its .pxe NPC data, which
specifies that there is a chest at the upper corner of the room, and that that chest runs
event #300 upon inspecting it.
Normally, with the EggR script loaded, this gives you the missiles:
    #0300
    <PRI<FLJ0200:0001<FL+0200
    <SOU0022<CNP0300:0021:0000
    <MSG
    Opened the treasure chest.<NOD<CLR<EVE0030
(The <EVE0030 at the end jumps to event #30, which is defined in Head and gives you the
Missile Launcher.)

However, inventory-glitching in this way causes the Plant script (Yamashita Farm's TSC)
to be loaded overwriting EggR's script in the TSC buffer, which means that Plant's
event #300 is run instead of EggR's:
    #0300
    <PRI
    <FL+0410
    <DNP0300
    <MSG
    You don't see anything...<NOD<CLR<CMU0010<GIT1005<IT+0005
    How did you get the Beast Fang?
    ...<WAI0160<NOD<CLO
    <RMU<END
Voila! Now you have the Beast Fang.

Example #2: Accessing Sand Zone early

Save in the Save Point in Mimiga Village, then go to Arthur's House and inventory-exit
out. Reload into the Save Point and inspect the door. You should be taken to Sand Zone
instead of Mimiga Village.

Why does this work? Inventory-glitching in this way causes MiBox (the Save Point) to be
loaded but with the Pens1 script (Arthur's House) in the TSC buffer. The door in the
Save Point is set to run event #100 upon inspecting it. Event #100 in MiBox takes you out
to Mimiga Village:
    #0100
    <PRI<FAO0004<TRA0011:0094:0024:0034
(Translated: "Freeze the game and lock player input, then fade out the screen in
direction 4 (center), then transport the player to map #11 (Mimiga Village), at
coordinates (24, 34), and run event #94 in the Mimiga Village script when you get there".)

However, with the Pens1 script loaded, this runs Arthur's House's event #100 instead:
    #0100
    <PRI<FAO0004<TRA0010:0094:0018:0032
This takes you to map #10 (Sand Zone), at coordinates (18, 32), which is 3 blocks to the
left and 1 block above where Curly is when you first meet her.

Note that there's no way to naturally trigger this event without inventory glitching.
My guess is that this is probably a remnant of some kind of debug testing mechanism that
was eventually disabled before the release of the game. (It's present in the Pens1 script
in the original freeware CS, as well, so it's something Pixel put in rather than Nicalis.)

Example #3: No, I don't want to teleport to Egg Corridor

Save in Arthur's House, then inventory-exit out from anywhere. Upon reloading your save,
cursoring over any inventory item will cause a "Teleport to the Egg Corridor?" prompt to
pop up.

Why does this happen? When you load the save back into Arthur's House, the game loads all
of the data for the Pens1 stage, including the Pens1 TSC file. However, the game starts
you in the inventory instead of directly inside Arthur's House.
Recall from the previous section that cursoring over an item in the inventory runs TSC
event number (1000 + [weapon ID]) for weapons, or (5000 + [item ID]) for items. Since the
Pens1 script is loaded instead of ArmsItem, this tries to run that event number in
Arthur's House. However, Arthur's House doesn't have any events in the 1000-50XX range:
    [...stuff...]
    #0660
    <KEY<FLJ1020:0661<MSG<FAC0018
    Take Sue with you and
    leave this island...<NOD
    Please...<NOD<END
    #0661
    <KEY<MSG<FAC0018
    I'm sorry.
    We've ruined your island.<NOD<CLR
    We humans are evil.<NOD<END


    #0700
    <KEY<CMU0000<FAO0004<TRA0024:0700:0002:0000


    #6001
    <PRI<MSG
    Teleport to the Egg Corridor?<YNJ0000<CLO
    <KEY<CNP0300:0111:0002<HMC<WAI0060<ANP0500:0001:0000
    <WAI0100<FAO0004<FLJ0159:6011<TRA0002:0099:0005:0006
    #6002
    <PRI<MSG
    Teleport to Bushlands?<YNJ0000<CLO
    <KEY<CNP0300:0111:0002<HMC<WAI0060<ANP0500:0001:0000
    <WAI0100<FAO0004<TRA0006:0098:0004:0018
    [...stuff...]
The result is that when the game scans the TSC buffer looking for the event, it reaches
event #6001 (which is past where the event should be), and stops scanning and returns an
error status. However, as discussed previously, the game doesn't care about that and
starts executing TSC anyways, beginning at the point that the scan cursor left off
(which would be at the "6" in "#6001").
What ends up happening is that the game outputs "6001" as text to an invisible message
box, then opens an actual message box and prompts you to teleport to the Egg Corridor.
Saying yes can cause glitchy things to happen, including softlocking the game
(I'm not sure why this happens, honestly), but it seems that waiting long enough without
closing the inventory causes the teleport to succeed (though once you close the inventory,
it'll load the "previous" stage's TSC, which means Egg Corridor will now behave as if
inventory-glitched).

Example #3a: Teleporting to other places
Recall from the previous example that the teleporter prompts in Arthur's House are
numbered starting from #6001. Specifically, here they all are:
    #6001
    <PRI<MSG
    Teleport to the Egg Corridor?<YNJ0000<CLO
    <KEY<CNP0300:0111:0002<HMC<WAI0060<ANP0500:0001:0000
    <WAI0100<FAO0004<FLJ0159:6011<TRA0002:0099:0005:0006
    #6002
    <PRI<MSG
    Teleport to Bushlands?<YNJ0000<CLO
    <KEY<CNP0300:0111:0002<HMC<WAI0060<ANP0500:0001:0000
    <WAI0100<FAO0004<TRA0006:0098:0004:0018
    #6003
    <PRI<MSG
    Teleport to Sand Zone?<YNJ0000<CLO
    <KEY<CNP0300:0111:0002<HMC<WAI0060<ANP0500:0001:0000
    <WAI0100<FAO0004<TRA0010:0099:0036:0033

    #6004
    <PRI<MSG
    Teleport to the Labyrinth?<YNJ0000<CLO
    <KEY<CNP0300:0111:0002<HMC<WAI0060<ANP0500:0001:0000
    <WAI0100<FAO0004<TRA0043:0099:0010:0034

    #6005
    <PRI<MSG
    Teleport to the Plantation?<YNJ0000<CLO
    <KEY<CNP0300:0111:0002<HMC<WAI0060<ANP0500:0001:0000
    <WAI0100<FAO0004<TRA0060:0099:0009:0009

    #6011
    <KEY<TRA0049:0099:0007:0006
Also recall from previously that selecting an item in the inventory runs TSC event
(6000 + [item ID]). Thus, you can teleport anywhere you want granted that you have the
correct item in your inventory:
* For Egg Corridor (#6001), you need item ID 1 (Arthur's Key)
  (Note that this takes you to Egg Corridor? instead if it would do so normally, due to
   the <FLJ0159:6011 in the event script (If flag 159 is set, jump to event #6011).)
* For Bushlands (#6002), you need item ID 2 (Map System)
* For Sand Zone (#6003), you need item ID 3 (Santa's Key)
* For Labyrinth (#6004), you need item ID 4 (Silver Locket)
* For Plantation (teleporter room) (#6005), you need item ID 5 (Beast Fang)
* For Egg Corridor? (#6011), you need item ID 11 (Gum Base).

Unfortunately, closing the inventory after teleporting causes game to reload the TSC for
the stage you inventory-exited out of, so you likely won't be able to do anything useful.

Example #4: Getting infinite Life Capsules

Save in the Prefab House (before Hell). Enter Hell and inventory-exit out. Reload into the
Prefab House and inspect the bed for a Life Capsule. You can continue inspecting the bed
as many times as you like to keep getting Life Capsules.

Why does this work? Inventory-glitching in this way causes the Prefa2 (Prefab House) stage
to be loaded, but with the Hell1 (Blood Stained Sanctuary - B1) script in the TSC buffer.
The bed in Prefa2 is set to run event #250 when interacted with. However, Hell1 doesn't
have an event #250:
    [...stuff...]

    #0200
    <PRI<MSG<TUR
    Welcome to Hell!<NOD<END


    #0400
    <PRI<SOU0022<DNP0400
    <MSG<GIT1006
    Obtained a Life Capsule.<NOD<ML+0005
    Max life increased by 5.<NOD<END

    [...stuff...]
Similar to Example #3, this causes the script engine to start executing TSC starting from
the last position of the scan cursor (in this case, the first "0" in "0400"), which
ends up giving you a Life Capsule.
But Life Capsules normally delete themselves when you collect them. Why are you able to
repeatedly collect this one? (In other words, why does the bed not get deleted in place of
the Life Capsule?)
The answer lies in the TSC itself:
    0400                       -- Printed to an invisible message box
    <PRI (PRevent Interaction) -- Lock player input and freeze the game
    <SOU0022 (SOUnd)           -- Play sound #22 (click)
    <DNP0400 (Delete NPc)      -- Delete the NPC associated with event #400
    <MSG (MeSsaGe)             -- Open a message box
    <GIT1006 (Graphic ITem)    -- Display icon #1006 (life capsule) above the message box
    Obtained a Life Capsule.   -- Text to display
    <NOD                       -- Wait for player to press jump/shoot
    <ML+0005 (Max Life +)      -- Increase player's max HP by 5
    Max life increased by 5.   -- More text to display
    <NOD                       -- Wait for player to press jump/shoot
    <END                       -- End of event, resume normal game operation
What happens is that the <DNP0400 tries to delete the NPC tied to event #400, which in
the Hell1 stage is the Life Capsule entity. However, since we're in Prefa2, the game has
the Prefa2 NPC data loaded instead of Hell1! So it tries to delete the NPC associated with
event #400 in Prefa2, which silently fails since no such NPC exists. (Remember, the bed is
tied to event #250, not #400!)
This means that you can keep interacting with the bed and it will keep running event #400
in Hell1 and keep giving you Life Capsules as much as you want.

Example #5: Boundary Break (Obtaining Booster v2.0 early)

Strap yourselves in; this one is a bit crazy.

Save in Arthur's House while Sue et al. are present in the room. Go to Mimiga Village and
inventory-exit out. Upon reloading your save, talk to any of the characters in the room
to obtain the Booster v2.0.

Why does this work? In fact, it almost doesn't. Let's see what's going on inside the
TSC buffer when you load back into Arthur's House:
(1) The game loads the Pens1 (Arthur's House) stage data. The Head and Pens1 scripts are
    loaded into the TSC buffer, followed by a null character to denote the end of the
    script. Basically, the TSC buffer looks like this:
        #0000
        <END

        #0001
        <PRI<MSG
        Empty.<NOD<END

        #0016
        <PRI<MSG
        Do you want to save?<YNJ0000<CLR<MSG<TURDo not turn the system off or remove
        the Nintendo 3DS Game Card
        <WAI0020<FL+0431<SVP<CLR
        Game saved.<NOD<END

        [...]

        #0042
        <KEY<CMU0000<WAI0040<PRI<WAI0040<CMU0003
        <MSG<HMC
        You were never seen again...<NOD<CLR
        Want to retry?<YNJ0049<CLO
        <FAO0001<WAI0050<FLJ0431:0048<INI<END

        #0048
        <SMC<LDP<END

        #0049
        <CLO<FAO0004<ESC


        XX: head.tsc   4000 - 4099
        4000:Almond…“ï
        [end of Head, start of Pens1]
        #0090
        <MNA<CMU0002<FAI0000<END
        #0091
        <MNA<CMU0002<FAI0001<END
        #0092
        <MNA<CMU0002<FAI0002<END
        #0093
        <MNA<CMU0002<FAI0003<END
        #0094
        <MNA<FLJ0341:0095<CMU0002<FAI0004<END

        [...]

        #6005
        <PRI<MSG
        Teleport to the Plantation?<YNJ0000<CLO
        <KEY<CNP0300:0111:0002<HMC<WAI0060<ANP0500:0001:0000
        <WAI0100<FAO0004<TRA0060:0099:0009:0009

        #6011
        <KEY<TRA0049:0099:0007:0006


        [end of Pens1]
        <null character>
        [garbage data after this point]
(2) Upon closing the inventory, the game loads the TSC for the stage that was loaded prior
    to opening the inventory -- in this case, Mimiga Village. So, the game loads Head and
    Mimi into the TSC buffer, followed by a null character to mark the end of the scripts.
    Now, the key point here is that the TSC buffer is NOT cleared before this happens!
    The new scripts get loaded on top of whatever is currently in the TSC buffer. Since
    the Pens1 script is a bit longer than the Mimi script, what happens is that the Pens1
    script doesn't get fully overwritten when Mimi is loaded in:
        #0000
        <END

        [...]

        #0049
        <CLO<FAO0004<ESC


        XX: head.tsc   4000 - 4099
        4000:Almond…“ï
        [end of Head, start of Mimi]

        #0090
        <MNA<FLJ0341:0095<CMU0009<FAI0000<END
        #0091
        <MNA<FLJ0341:0096<CMU0009<FAI0001<END

        [...]

        #0610
        <FLJ0224:0611
        <KEY<MSG<FAC0007
        This is what happens to
        those who defy the order
        of the village.<NOD<END
        #0611
        <KEY<MSG<FAC0007
        They're not coming...<NOD<END


        [end of Mimi]
        <null character>e island.<NOD<CLO<FAC0000
        <ANP0650:0003:0002<WAI0022
        <ANP0650:0005:0002
        <IT+0023<FL+0744<FL+0162<FL+1801<GIT1023
        <MSG
        Obtained the Booster v2.0.<WAI0030<NOD<CLO<GIT0000
        <ANP0650:0000:0002
        <MSG<FAC0018
        Please honor my final request.<NOD<CLR
        If you see Sue one last time,
        please take her and...
        escape... from the island.<NOD<CLR
        She is Dr. Sakamoto's
        daughter.<NOD
        For the longest time she
        resisted coming to this
        island.<NOD
        But she couldn't be left
        behind, all alone...<NOD<CLR
        She had no choice but to
        follow us to the island.<NOD<CLR
        Please.<NOD<CLR
        Take her and escape.<NOD<CLO
        <FL-0160<FL+0161<FL+0741<PS+0004:6004<END

        [...]
Now, in the Pens1 NPC data, the characters are set to run event #621 (Booster),
#622 (Kazuma), #624 (King), and #625 (Sue). Since the Mimi script is what's in the TSC
buffer, and the last event in the Mimi TSC is numbered 611, attempting to trigger any of
these events results in the scan cursor reaching the null character at the end of the
Mimi script. This causes the scan to fail without finding the requested event, but since
the game doesn't care about that, it starts reading TSC from that point onwards
regardless.
This results in "<null character>e island." being printed to an invisible message box, and
then a real message box pops up and informs you that you've obtained the Booster 2.0.
It turns out that if the Mimiga Village script was just a little bit longer
(by 76 characters or more), then you wouldn't be able to get the Booster this way!


These aren't the only ways of abusing the inventory glitch -- in fact, I haven't even
begun to scratch the surface of what's possible with this glitch. So, I'll just leave you
to experiment with it and find out on your own what you can do. :)