Final Fantasy III/VI - Getting General Leo 100% Legit FOUND WoR

Trynabefunny

Edit history:

Trynabefunny: 2013-04-10 12:36:56 pm

Trynabefunny: 2013-04-10 12:32:25 pm

2013-04-10 12:24:49 pm

Quote from duckfist:

NEW CATEGORY: Beat the game with Vicks (Biggs is a chump; Vicks stole my heart from the start), Wedge, Leo, and Locke dressed as a merchant.

I believe that's not possible without cheating, Vicks and Wedge that is. Locke is possible to have in a different suit without the glitch. Also, beating the game with any of those players isn't possible even while cheating I believe.

Yohosie

2013-04-10 03:15:52 pm

I have a save file with Wedge that doesn't involve cheats, I just completely forgot how I did it. I'm pretty sure it's common sense and I'm just forgetting how.

PJ

2013-04-10 03:18:07 pm

Is PJ

I was pretty sure that someone found a way years ago to permanently overwrite a character slot with Leo so he'd work everywhere. I know it was found for most of those temporary Moogles, but I thought it worked for Leo, too. I'm pretty sure Nitrodon would have known about it if that were the case though...

Trynabefunny

Edit history:

Trynabefunny: 2013-04-10 03:41:11 pm

2013-04-10 03:35:28 pm

Quote from Yohosie:

I have a save file with Wedge that doesn't involve cheats, I just completely forgot how I did it. I'm pretty sure it's common sense and I'm just forgetting how.

What version of the game? The best possible reasoning I can think of to make that happen would be to trigger Banon then go back and trigger something for Wedge to be in that slot. Other than starting the game over, I don't know where else the trigger could be.

Nitrodon

2013-04-10 04:47:27 pm

The only method I know of is to airship glitch directly to the Imperial camp, then play through all of Sabin's scenario. This lets you reach the scenario select screen without ever triggering Banon.

Trynabefunny

2013-04-10 04:51:39 pm

Quote from Nitrodon:

The only method I know of is to airship glitch directly to the Imperial camp, then play through all of Sabin's scenario. This lets you reach the scenario select screen without ever triggering Banon.

I recall attempting getting by that scenario. I think that Banon was a blur when I did that. I'll attempt it again I suppose, I never did finish the area.

Nitrodon

2013-04-10 04:57:44 pm

If Banon was a blur, that means you triggered Maduin earlier. To get Wedge in his original state, you would have to glitch directly to the Imperial camp instead of going to Zozo. I've never done it myself because it would take 5-6 hours for very little reward, but I'm sure it would work.

Trynabefunny

2013-04-10 08:30:31 pm

Quote from Nitrodon:

If Banon was a blur, that means you triggered Maduin earlier. To get Wedge in his original state, you would have to glitch directly to the Imperial camp instead of going to Zozo. I've never done it myself because it would take 5-6 hours for very little reward, but I'm sure it would work.

Actually, using an emulator, it'd take maybe 20 minutes to get to that point. Which is why I was able to test the glitch 30 or so times in a day and a half. I'd imagine the GBA version taking at least an hour, this is with cheats of course. The problem is, if you don't do Zozo first, you'd have to finish that quest with bare minimum, Terra or Edgar in the party. In which I think freezes the game, IIRC. I'll be checking in a bit to see for sure.

Neohart

2013-04-10 10:36:24 pm

Final Fantasy VII Fanatic

Quote from duckfist:

Is everybody in this thread the same person?

This was my first thought as well.

Trynabefunny

2013-04-10 11:00:39 pm

Quote from Neohart:

Quote from duckfist:

Is everybody in this thread the same person?

This was my first thought as well.

Still confused as to why that would be your thoughts on the matter. Why would she need to create another account to help credit herself? That'd be kinda sad.

Nitrodon

2013-04-11 12:05:39 am

Completing Sabin's scenario without both Sabin and Cyan will freeze the game. Fortunately, the events in the Imperial camp add both characters to your party, so I don't see any reason there would be a problem.

Come to think of it, you need to have a solo character (either Terra or Edgar) when doing the glitch. Otherwise, there wouldn't be room for Gau to show up in battle.

Trynabefunny

Edit history:

Trynabefunny: 2013-04-11 12:16:59 am

Trynabefunny: 2013-04-11 12:16:55 am

Trynabefunny: 2013-04-11 12:16:54 am

Trynabefunny: 2013-04-11 12:15:37 am

Trynabefunny: 2013-04-11 12:15:16 am

Trynabefunny: 2013-04-11 12:12:57 am

2013-04-11 12:09:45 am

Quote from Nitrodon:

Completing Sabin's scenario without both Sabin and Cyan will freeze the game. Fortunately, the events in the Imperial camp add both characters to your party, so I don't see any reason there would be a problem.

Come to think of it, you need to have a solo character (either Terra or Edgar) when doing the glitch. Otherwise, there wouldn't be room for Gau to show up in battle.

I'm in the middle of doing it atm. I actually went to my second playthrough and grabbed Sabin so he could go alone. Got Cyan, flew to the waterfall and started Banon's part. He's named Wedge, looks like Maduin and plays like a blur. The only way I see to get, well It, officially is to play through the game a second time for a second Airship glitch. Otherwise, you're stuck because you can't reach your Airship.

EDIT:
Actually, I'm wrong. You could do it without the glitch, but it would require that you finish the Edgar scene in Figaro. Which means, you can't bring It to the WoR. You can if you do the glitch again. You'd also have to finish the war. You'd have to take a ship from South Figaro to reach the Airship.

[quote="Nitrodon"]Completing Sabin's scenario without both Sabin and Cyan will freeze the game.  Fortunately, the events in the Imperial camp add both characters to your party, so I don't see any reason there would be a problem.

Come to think of it, you need to have a solo character (either Terra or Edgar) when doing the glitch.  Otherwise, there wouldn't be room for Gau to show up in battle.[/quote]

I'm in the middle of doing it atm. I actually went to my second playthrough and grabbed Sabin so he could go alone. Got Cyan, flew to the waterfall and started Banon's part. He's named Wedge, looks like Maduin and plays like a blur. The only way I see to get, well It, officially is to play through the game a second time for a second Airship glitch. Otherwise, you're stuck because you can't reach your Airship.

EDIT:
Actually, I'm wrong. You could do it without the glitch, but it would require that you finish the Edgar scene in Figaro. Which means, you can't bring It to the WoR. You can if you do the glitch again. You'd also have to finish the war. You'd have to take a ship from South Figaro to reach the Airship.

Trynabefunny

Edit history:

Trynabefunny: 2013-04-12 03:55:15 am

Trynabefunny: 2013-04-12 03:46:31 am

2013-04-12 03:45:23 am

I did some mucking around and well, this should expedite the process by days. I was looking for some cheat codes for about an hour, I finally found a cheat code to allow you onto Daryl's Airship at any point. The problem with the code was, it turned the game into Limbo WoR/WoB. I modified it and it now gives the WoB Airship. Now, you can just turn the codes on, enter your menu and exit, then you'll be in the airship. This way, there is no reason to have to constantly play the entire game over and over again since this does exactly the same thing. Don't enter the Airship before getting Setzer (Presumably) since it won't let you leave like it would normally.

Master Code:
0000F914 000A
10133444 0007

Master Code Alt 1:
0000F914 000A
100F4F6C 0007

Master Code Alt 2:
0000F914 000A
100F4F6E 0007

Airship: Press menu and exit on world map to enter your airship.
32001E94 0000
320011FA 0003

Forgot to mention, this is for the GBA version of the game.

Trynabefunny

Edit history:

Trynabefunny: 2013-04-12 05:44:20 am

2013-04-12 04:45:34 am

I've found that if you never do the Opera, you can't go to the floating continent, since the game acts as though you've never had the Airship in the first place. Maybe you can if you finish the Opera, I didn't try to.

Also, bringing Shadow with you after the meeting with Ghestal and flying to Thamasa, you can skip the ship cut scene with Leo. You can return and do the scene but you will be docked the entire time.

Apart from making Leo and Wedge sing, I can't really think of much else to do.

So, I was on youtube and I happened to cross this video:
It describes Dawn/Elephantgun/Yohosie's LP and how to use the glitch.

Question?

2013-06-05 10:05:02 am

Just a question, has anyone tried using the rename card on Leo? According to the video, naming is the way to 'official-ize' the other 14 chars, so would that permanently assign Leo to slot 15 allowing him to be in the party switch screen/final battle/phoenix cave/et all?

Lone_Kilted_Ninja

2013-06-06 08:08:55 pm

Anything you can do I can do halfass

Quote from Question?:

Just a question, has anyone tried using the rename card on Leo? According to the video, naming is the way to 'official-ize' the other 14 chars, so would that permanently assign Leo to slot 15 allowing him to be in the party switch screen/final battle/phoenix cave/et all?

I'm not an expert in the FFVI code (at least not yet), but intuiting how things more or less have got to be laid out based on the glitches described, it's probably not that simple.

Fundamentally, the cart only has enough memory each save for a fixed number of characters. Imagine 16(?) empty boxes. The programmers threw some plot-related and technical cuteness by way of the Moogle battles to conveniently initialize all slots to valid data (put a character in each box) early in the game (although I'm vaguely curious if they're initialized prior to that, and if so, to what?). From there on, as is described somewhere between the video and this thread, various events repopulate the slots with "real" character data. The game can give the impression of having a greater number of total characters than it has boxes by clever plot design and only needing to retain the data for a limited number of relevant characters at once. Any boxes that don't need to actually retain player-affected (equipped/levelled/trained/etc.) characters for future use can be filed with different pre-fab'd characters on demand. As the game goes on, however, 14 boxes need to be allocated to retain real and proper player-affected character data, and I would guess that on some level any code that manipulates characters recognizes that those boxes are not to be messed with (this includes party selection). The remaining boxes serve as scratchpads for any immediately-required bit character. The whole execution of the glitch revolves around triggering events in just such an order that a spare box is filled with a pre-fab Leo, and then NEVER TOUCHING THAT BOX AGAIN because as soon as another event goes off, hey, look, a scratchpad, let's scribble over whatever is there.

Independently, the game is tracking what boxes the player has access to. I couldn't say offhand whether each character has a specific box and the game just flags each box as available/unavailable (i.e. Locke always lives in box 1, Terra always lives in box 2 (unless a moogle is still in residence), Edgar (or the preceding moogle) always lives in box 3, and the player currently has boxes 1 and 3 while 2 is just sitting on the shelf in memory) or whether the game actually moves data between boxes and gives the player access to specific groups of boxes at once (i.e. characters can live anywhere, the player normally has control of boxes 1-4, and it just so happens that Locke is in box 1, Terra is in box 2, boxes 3 and 4 are empty, and Edgar has been moved for the moment into box 5 which happens for the moment to be part of the reserve roster). The former arrangement would require less memory but more wizardry to make the multi-party segments work. The latter would require more memory (up to 12 boxes for active characters, and independently, 11 reserve boxes for e.g. when all characters are recruited and yet you only choose to put 1 into each party for Kefka's Tower) and more frequent ugly copying of data from one box to another, but would yield a more flexible system and make it slightly more likely that something as simple as a rename card would "finalize" a glitch character.

But anyway, it is more or less explicit that
- various events do a combination of putting character data in a box and setting up the metamanagement to give the player access to those characters
- not all boxes are created equal; one in particular is used exclusively to store temporary characters like Leo/Kefka/Bannon/etc.

The Rename Card most likely rewrites the name data in a chosen box and then sets up the metamanagement to refresh/re-add that box to the roster with the new name (dotting its 'i's and crossing its 't's in a more thorough way than events necessarily do, just to be sure there are no weird bugs or persistings of the old name anywhere). This side-effect can "finalize" both a character's presence in the party and presence on the roster, particularly if the character was previously only in the party. ... Actually, that statement alone makes me lean towards the hypothesis that individual characters having assigned box numbers and the game merely tags them as "in party position x" or "in reserve" rather than messing with moving them anywhere... Anyway... The Rename Card is very unlikely to actually move a character out of the special box and into a normal box (although cheats and hacks that e.g. overwrite Terra with Leo would put Leo in a normal box and make him 100% usable and safe* at the expense of whatever character normally lives in that box), therefore things like party select which only look for characters in the normal boxes will still miss the special-box character.

*Meanwhile, completely independent from where a character is temporarily or permanently living, each character only has certain scripts to control their automated actions. Special characters, while Squaresoft was very good and created art for things that special characters might never actually be able to do, would not necessarily have behavior scripting for all contexts. It would not surprise me in the least if the memory in which the game expects to find program code for what a character does e.g. in the arena is, for Leo, full of the things Leo does in his battle cutscenes and/or full of garbage/unrelated data. Hence when called to take action in the arena, the game tries valiantly to execute two teacups and a yellow frog as a battle command and ends up crapping itself after a generic attack. No amount of tomfoolery will get you around that problem without explicitly modifying the data yourself.

This post constitutes a large amount of speculation laced through a sparse framework of concrete observation, and may in fact be up to 80% utter BS. Quote it at your own risk, although I do hope it at least illustrates the scope of the problem!

[quote="Question?"]Just a question, has anyone tried using the rename card on Leo? According to the video, naming is the way to 'official-ize' the other 14 chars, so would that permanently assign Leo to slot 15 allowing him to be in the party switch screen/final battle/phoenix cave/et all?[/quote]
I'm not an expert in the FFVI code (at least not yet), but intuiting how things more or less have got to be laid out based on the glitches described, it's probably not that simple.

Fundamentally, the cart only has enough memory each save for a fixed number of characters.  Imagine 16(?) empty boxes.  The programmers threw some plot-related and technical cuteness by way of the Moogle battles to conveniently initialize all slots to valid data (put a character in each box) early in the game (although I'm vaguely curious if they're initialized prior to that, and if so, to what?).  From there on, as is described somewhere between the video and this thread, various events repopulate the slots with "real" character data.  The game can give the impression of having a greater number of total characters than it has boxes by clever plot design and only needing to [i]retain[/i] the data for a limited number of relevant characters at once.  Any boxes that don't need to actually retain player-affected (equipped/levelled/trained/etc.) characters for future use can be filed with different pre-fab'd characters on demand.  As the game goes on, however, 14 boxes need to be allocated to retain real and proper player-affected character data, and I would guess that on some level any code that manipulates characters recognizes that those boxes are not to be messed with (this includes party selection).  The remaining boxes serve as scratchpads for any immediately-required bit character.  The whole execution of the glitch revolves around triggering events in just such an order that a spare box is filled with a pre-fab Leo, and then NEVER TOUCHING THAT BOX AGAIN because as soon as another event goes off, hey, look, a scratchpad, let's scribble over whatever is there.

Independently, the game is tracking what boxes the player has access to.  I couldn't say offhand whether each character has a specific box and the game just flags each box as available/unavailable (i.e. Locke always lives in box 1, Terra always lives in box 2 (unless a moogle is still in residence), Edgar (or the preceding moogle) always lives in box 3, and the player currently has boxes 1 and 3 while 2 is just sitting on the shelf in memory) or whether the game actually moves data between boxes and gives the player access to specific groups of boxes at once (i.e. characters can live anywhere, the player normally has control of boxes 1-4, and it just so happens that Locke is in box 1, Terra is in box 2, boxes 3 and 4 are empty, and Edgar has been moved for the moment into box 5 which happens for the moment to be part of the reserve roster).  The former arrangement would require less memory but more wizardry to make the multi-party segments work.  The latter would require more memory (up to 12 boxes for active characters, and independently, 11 reserve boxes for e.g. when all characters are recruited and yet you only choose to put 1 into each party for Kefka's Tower) and more frequent ugly copying of data from one box to another, but would yield a more flexible system and make it slightly more likely that something as simple as a rename card would "finalize" a glitch character.

But anyway, it is more or less explicit that
- various events do a combination of putting character data in a box and setting up the metamanagement to give the player access to those characters
- not all boxes are created equal; one in particular is used exclusively to store temporary characters like Leo/Kefka/Bannon/etc.

The Rename Card most likely rewrites the name data in a chosen box and then sets up the metamanagement to refresh/re-add that box to the roster with the new name (dotting its 'i's and crossing its 't's in a more thorough way than events necessarily do, just to be sure there are no weird bugs or persistings of the old name anywhere).  This side-effect can "finalize" both a character's presence in the party and presence on the roster, particularly if the character was previously only in the party. ... [size="9"]Actually, that statement alone makes me lean towards the hypothesis that individual characters having assigned box numbers and the game merely tags them as "in party position x" or "in reserve" rather than messing with moving them anywhere... Anyway...[/size]  The Rename Card is very [i]unlikely[/i] to actually move a character out of the special box and into a normal box (although cheats and hacks that e.g. overwrite Terra with Leo [i]would[/i] put Leo in a normal box and make him 100% usable and safe* at the expense of whatever character normally lives in that box), therefore things like party select which only look for characters in the normal boxes will still miss the special-box character.

*Meanwhile, completely independent from where a character is temporarily or permanently living, each character only has certain scripts to control their automated actions.  Special characters, while Squaresoft was very good and created art for things that special characters might never actually be able to do, would not necessarily have behavior scripting for all contexts.  It would not surprise me in the least if the memory in which the game expects to find program code for what a character does e.g. in the arena is, for Leo, full of the things Leo does in his battle cutscenes and/or full of garbage/unrelated data.  Hence when called to take action in the arena, the game tries valiantly to execute two teacups and a yellow frog as a battle command and ends up crapping itself after a generic attack.  No amount of tomfoolery will get you around that problem without explicitly modifying the data yourself.

[size="8"]This post constitutes a large amount of speculation laced through a sparse framework of concrete observation, and may in fact be up to 80% utter BS.  Quote it at your own risk, although I do hope it at least illustrates the scope of the problem![/size]

Lone_Kilted_Ninja

2013-06-07 08:53:25 am

Anything you can do I can do halfass

Thinking about this for far too long last night while failing to sleep, this is quite an ingenious bit of routing assuming it works (hey, it's not levelling to 99 or getting an ultra-rare dragon drop, but it's still a pedantically involved enough setup that I'd love to see independent verification...). It's also quite revealing of how the game's data and logic are set up and I'll probably do another uberpost at some point once I've had time to watch the vid again and cross-check my hypotheses, if only to see if the community sense of what's going on matches my own.

For now, though, the one point that snagged me on my first watch and which I have yet to compellingly explain. It may just be that I haven't played the game for too long and don't remember exactly how the scenario is supposed to end, but... if the trigger at the end of Sabin's Returners subquest ~is~ still present to take you back to Choose a Scenario Kupo, how did you manage to sneak past it and talk to Bannon to end the war and clear the cave guard? If it's ~not~ there, how did you get back to Choose a Scenario to Kupo to switch to Terra/Edgar/#15?

Thinking about this for far too long last night while failing to sleep, this is quite an ingenious bit of routing assuming it works (hey, it's not levelling to 99 or getting an ultra-rare dragon drop, but it's still a pedantically involved enough setup that I'd love to see independent verification...).  It's also quite revealing of how the game's data and logic are set up and I'll probably do another uberpost at some point once I've had time to watch the vid again and cross-check my hypotheses, if only to see if the community sense of what's going on matches my own.

For now, though, the one point that snagged me on my first watch and which I have yet to compellingly explain.  It may just be that I haven't played the game for too long and don't remember exactly how the scenario is supposed to end, but... if the trigger at the end of Sabin's Returners subquest ~is~ still present to take you back to Choose a Scenario Kupo, how did you manage to sneak past it and talk to Bannon to end the war and clear the cave guard?  If it's ~not~ there, how did you get back to Choose a Scenario to Kupo to switch to Terra/Edgar/#15?

Nitrodon

2013-06-07 10:31:31 am

The trigger for the meeting after the IMRF is one tile below the trigger preventing you from entering Narshe via the front entrance. Thus, you can enter Narshe without being kicked out and without hitting the Terra/Edgar/Banon scenario end trigger.

As for getting back to Terra/Edgar/#15, you can do that by fighting Ultros 1 or (if you already fought Ultros 1) TunnelArmr. Sabin's and Terra/Edgar/Banon's scenario triggers both check whether you have reached the WoR, so they can't be used for this. (Terra/Edgar/Banon's scenario would be a bad choice even if it didn't check the WoR flag.)

Lenophis

Edit history:

Lenophis: 2013-06-07 10:51:48 am

2013-06-07 10:41:37 am

0-10

Quote from Lone_Kilted_Ninja:

The Rename Card most likely rewrites the name data in a chosen box and then sets up the metamanagement to refresh/re-add that box to the roster with the new name (dotting its 'i's and crossing its 't's in a more thorough way than events necessarily do, just to be sure there are no weird bugs or persistings of the old name anywhere). This side-effect can "finalize" both a character's presence in the party and presence on the roster, particularly if the character was previously only in the party. ... Actually, that statement alone makes me lean towards the hypothesis that individual characters having assigned box numbers and the game merely tags them as "in party position x" or "in reserve" rather than messing with moving them anywhere... Anyway... The Rename Card is very unlikely to actually move a character out of the special box and into a normal box (although cheats and hacks that e.g. overwrite Terra with Leo would put Leo in a normal box and make him 100% usable and safe* at the expense of whatever character normally lives in that box), therefore things like party select which only look for characters in the normal boxes will still miss the special-box character.

If you had a Rename Card for the brief time you had Leo in your party, you could rename him just fine. Same goes with Vicks, Wedge, Banon, Mog (scenarios), both ghosts, Kupek, Kupop, Kumama, Kuku, Kutan, Kupan, Kushu, Kurin, Kuru, and Kamog. If you want to get technical, all 16 slots are throwaway slots (evident since the moogles take up 10 of those slots). Yes, I know that almost every character mentioned here takes up the "regular slots," the focus here is on the so-called "temporary characters" which has no bearing on anything here. If need be, I will provide video.

[quote="Lone_Kilted_Ninja"]The Rename Card most likely rewrites the name data in a chosen box and then sets up the metamanagement to refresh/re-add that box to the roster with the new name (dotting its 'i's and crossing its 't's in a more thorough way than events necessarily do, just to be sure there are no weird bugs or persistings of the old name anywhere).  This side-effect can "finalize" both a character's presence in the party and presence on the roster, particularly if the character was previously only in the party. ... [size="9"]Actually, that statement alone makes me lean towards the hypothesis that individual characters having assigned box numbers and the game merely tags them as "in party position x" or "in reserve" rather than messing with moving them anywhere... Anyway...[/size]  The Rename Card is very [i]unlikely[/i] to actually move a character out of the special box and into a normal box (although cheats and hacks that e.g. overwrite Terra with Leo [i]would[/i] put Leo in a normal box and make him 100% usable and safe* at the expense of whatever character normally lives in that box), therefore things like party select which only look for characters in the normal boxes will still miss the special-box character.[/quote]
If you had a Rename Card for the brief time you had Leo in your party, you could rename him just fine. Same goes with Vicks, Wedge, Banon, Mog (scenarios), both ghosts, Kupek, Kupop, Kumama, Kuku, Kutan, Kupan, Kushu, Kurin, Kuru, and Kamog. If you want to get technical, all 16 slots are throwaway slots (evident since the moogles take up 10 of those slots). Yes, I know that almost every character mentioned here takes up the "regular slots," the focus here is on the so-called "temporary characters" which has no bearing on anything here. If need be, I will provide video.

Lone_Kilted_Ninja

2013-06-07 07:00:49 pm

Anything you can do I can do halfass

Alright, that makes some sense. 'Regular' vs 'special' likely is immaterial as far as any function that takes a handle to a character and operates on it, so yeah, Rename Card ought to do its thing even on the slots used for temps. My only niggling was with whether or not the game has static assignments between characters and slot indices and could/does limit certain roster-based actions to only the range of slots intended to hold eventually-permanent characters (even if those slots happen to hold moogles earlier). If that were the case, Question?s point on why not "finalize" Leo with a rename card (which I read to mean rename card as a side-effect e.g. flags the target as in-roster even if they were previously only in-party) would only have limited utility, and would not counter prior assertions that even as such, Leo cannot be accessed in e.g. the Kefka tower party builder.

Question?

2013-06-27 10:36:35 am

Wow! Thanks for all of the responses! That gave me alot to think about! I actually ended up trying the Rename Card trick myself and what ended up happening was that the game 'rewrote' Leo's info to Banon's. In other words, if Leo got killed/stoned, I'd get "Banon fell..." message and the game would end. B4 the card, Leo could go down just fine and be revived later w/ no problem.

HOWEVER, I also found out that Leo/Banon actually DO NOT get kicked out of the group upon going into the party select screen, at least not in the GBA version!!! The game just permanently 'assigns' them to whichever battle slot they are in. The game makes their menu profile and overworld sprite disappear, yes, but they REMAIN IN THE PARTY, you just can't see them until you go into battle w/ that particular slot open. I've taken both Banon and Leo into the WoR from the FC this way. I found this out by accident when I made the 3 member party for the FC - there was Leo, still in the 4th/bottom slot where I'd left him!!!

Now, when I got Shadow on the FC, he 'overwrote' Leo and became my 4th member (I guess the game bumps Leo/Banon to the '5th member' status Elephantgun talks about). But once that 4th slot was clear again at the start of the WoR, There was Leo again, along with Celes! I'm currently replaying the game to see what the earliest is that I can get Leo w/out making the game unplayable, but as of this writing I've taken him into the Phoenix Cave and Kefka's Tower, just by making a party of 3 instead of 4 and leaving 'his' slot open.

One more thing, once you switch members and Leo/Banon goes 'invisible,' they can't be healed/revived/status restored at the inn or w/ tents, I guess the game only recognizes them while in battle, other than that I've had no other issues with them, other than the fact that they still can't change equipment or use Espers. Can anyone else confirm my findings?

Wow! Thanks for all of the responses! That gave me alot to think about! I actually ended up trying the Rename Card trick myself and what ended up happening was that the game 'rewrote' Leo's info to Banon's. In other words, if Leo got killed/stoned, I'd get "Banon fell..." message and the game would end. B4 the card, Leo could go down just fine and be revived later w/ no problem.

HOWEVER, I also found out that Leo/Banon actually DO NOT get kicked out of the group upon going into the party select screen, at least not in the GBA version!!! The game just permanently 'assigns' them to whichever battle slot they are in. The game makes their menu profile and overworld sprite disappear, yes, but they REMAIN IN THE PARTY, you just can't see them until you go into battle w/ that particular slot open.  I've taken both Banon and Leo into the WoR from the FC this way. I found this out by accident when I made the 3 member party for the FC - there was Leo, still in the 4th/bottom slot where I'd left him!!!

Now, when I got Shadow on the FC, he 'overwrote' Leo and became my 4th member (I guess the game bumps Leo/Banon to the '5th member' status Elephantgun talks about). But once that 4th slot was clear again at the start of the WoR, There was Leo again, along with Celes!  I'm currently replaying the game to see what the earliest is that I can get Leo w/out making the game unplayable, but as of this writing I've taken him into the Phoenix Cave and Kefka's Tower, just by making a party of 3 instead of 4 and leaving 'his' slot open.

One more thing, once you switch members and Leo/Banon goes 'invisible,' they can't be healed/revived/status restored at the inn or w/ tents, I guess the game only recognizes them while in battle, other than that I've had no other issues with them, other than the fact that they still can't change equipment or use Espers. Can anyone else confirm my findings?

Trynabefunny

Edit history:

Trynabefunny: 2013-07-14 08:51:29 am

Trynabefunny: 2013-07-13 09:01:29 pm

2013-07-13 08:53:39 pm

@Lone

If the glitch doesn't work for you during any testing you may be doing, you should try a different version. I had someone post on my video that he couldn't get it to work. I checked his video, he did the entire process properly, just when he got up to Figaro in the WoR, the cutscene wouldn't progress. This is the video he sent me so you can understand what happened.

I never did get a confirmation as to what the problem was exactly, but I believe it was simply because of the version he was using. If you notice in the video I made, Locke will suddenly look up while you're following him to the room. I don't know what significance it has to the glitch, but you'll notice in the video, his Locke doesn't look up. So, I suggest if you attempt this glitch at all, you should get some cheat codes to do it. I never did fully attempt it on the GBA even with the codes, but I heard it works on there as well. I also haven't tried it on the PSX either.

EDIT:
There is a likely possibility I had Celes with me during that part, where he couldn't do anything. I really cannot remember, but I believe it worked regardless. I'll try it again tomorrow or something, but I had to reformat sometime after uploading the video, so I'm not even sure what version I used. I'll check a few versions and see if I can get a hold of some cheat codes. Going to attempt it without cheating as well, to make sure the codes had no impact on the glitch.

@Lone

If the glitch doesn't work for you during any testing you may be doing, you should try a different version. I had someone post on my video that he couldn't get it to work. I checked his video, he did the entire process properly, just when he got up to Figaro in the WoR, the cutscene wouldn't progress. This is the video he sent me so you can understand what happened.

http://www.youtube.com/watch?v=1sMJfWyznm8

I never did get a confirmation as to what the problem was exactly, but I believe it was simply because of the version he was using. If you notice in the video I made, Locke will suddenly look up while you're following him to the room. I don't know what significance it has to the glitch, but you'll notice in the video, his Locke doesn't look up. So, I suggest if you attempt this glitch at all, you should get some cheat codes to do it. I never did fully attempt it on the GBA even with the codes, but I heard it works on there as well. I also haven't tried it on the PSX either.

EDIT:
There is a likely possibility I had Celes with me during that part, where he couldn't do anything. I really cannot remember, but I believe it worked regardless. I'll try it again tomorrow or something, but I had to reformat sometime after uploading the video, so I'm not even sure what version I used. I'll check a few versions and see if I can get a hold of some cheat codes. Going to attempt it without cheating as well, to make sure the codes had no impact on the glitch.

Trynabefunny

Edit history:

Trynabefunny: 2013-07-14 01:53:39 pm

2013-07-14 01:39:49 pm

Update:
I checked 3 different versions, v1.0/v1.1/japanese translation(skyrender). They all worked. Turns out, the only reason Locke was looking up in the first place was because of a code I was using (I believe the one that set everyone's life and MP to 9999/999). It does work, which I am glad to say it does. Also, when I was doing this I used save states so I didn't have to run the entire game again (might be lazy but both games work on almost identical codes). I made sure to save the game as well and try from a save slot instead, which both worked. Oddly enough, when I loaded state on the Japanese version, right at the castle entrance inside the area, it acted as if I just found Bahamut. Terra walks down a step, looks left then right, then you hear the magicite chime while she's "praying". It leaves the area and you're inside the airship. Was kind of odd, but it didn't mess up the glitch.

Lone_Kilted_Ninja

2013-07-16 06:50:28 pm

Anything you can do I can do halfass

@Question:
Those are some fascinating observations. To an extent, I suspect that there are enough specific per-character checks going on to clutter the empirical data, but in a general sense I'd say this supports the notion that each character is associated with a specific slot in memory, and that each slot has an associated set of flags e.g. "in roster", "in party", a numeric value indicating battle slot, etc. Leo reverting to Banon's death checks probably means that, for the specific slot reserved for Leo/Banon/temp, one of the slot flags (of which there are probably 8 or 16 even if fewer are strictly needed) is examined to trigger the gameover if that character's HP is 0. With the flag being an exceptional case intended only ever to apply to Banon, and Banon never intended to be in the party when you have a Rename Card, I'm guessing that snippet of gameover message is hardcoded and does not reflect the actual character name. I will further go out on a limb and assert that whatever bit of whatever byte serves as the "gameover on death" flag, that bit being in its default state implies "yes," and needs to be set to "no" manually during some event (e.g. when Leo is switched into the memory slot). Rename Card, as previously implied, sets the in-roster and/or in-party flags, probably by overwriting the whole flag bank (byte) rather than doing a proper bitwise comparison, and so executing a Rename Card on Leo blows away the "gameover on death" flag and results in the message you see.

In the mental image I've been forming of this chunk of character-data memory, I've been sticking Temp in the final slot. Intuition? I don't know. But it would explain how, assuming characters are associated with particular fixed slots in memory, and assuming that presence in party/roster is controlled by flags and position in party is controlled by an independent value, Leo/Banon could magically reappear as soon as you leave a slot open. When Temp is in your party, he is validly flagged as in-party and he has a party position legitimately assigned. His in-roster flag, however, is not necessarily set. Therefore, when he leaves the party, no system for showing you your current characters ever picks him up. So it's conceivable that the event scripts which remove him from your party never bother to null out his party position. When you set his in-roster flag with a Rename, things get weird. Now, while party-management interfaces may still not show him (it would be quite easy/sensible for the loop which checks all characters to only go up to memory slot 15 regardless of what's in 16), the battle routine needs to be able to find slot-16 characters. It probably sets up battles by looking at each battle position, and walking down the list of slots in memory until it finds the first instance of a character with the in-party flag set and the party position set to the battle position it's looking for. If it doesn't find a character matching that description, the position is left empty. When more than one character somehow ends up with the same party position set (which "shouldn't happen" if all party management systems are working as intended), the game doesn't care- it just uses the first matching character it finds. So when Temp is in roster and has his party position set sensibly, then if an earlier character in the memory list also has the same position, that character is used. But if no other character has that position (the menu screens all show a blank because they only check so far in the general case), the battle init walks right through to slot 16 and finds Temp and sticks him in the battle!
Inns, tents, the party select menu, and other systems dealing with all roster'd characters at once probably only only count to slot 15. Things which affect character stats probably explicitly hit party positions as well, so that Temp and other off-roster guests behave normally while they're with you. My remaining curiosity would be with the regular menu- it obviously needs to inspect all 16 memory slots to find the 4 with active characters, and it can obviously find Temp when needed. And both evidently behave the same way when a "real" character is discovered at a desired position before Temp is discovered. But if the battle system falls straight through and finds Temp when no other character is around, but the menu system does not, then the menu system has some other bit of intelligence controlling when it searches all the way to slot 16 and when it doesn't...

@funny
Science! The point here is not how it "should" work for anyone, or how if it doesn't work for me I'm doing it wrong. I am likely never going to attempt the glitch; I've got too much other stuff going on. My point is that so far you're the only one posting proof that it does work, and while it makes logical sense that it might from a programming standpoint, logical sense + 1 claim does not make rigorous proof. If the NIH claimed to discover that jumping up and down 1 million times cured cancer, and theorists surmised that it's a known fact that applying physical pressure to certain cancerous cells helps the body to realign them to their normal function and therefore it is theoretically within reason that applying physical jolts repeatedly to the whole body would have a beneficial effect... I'd still wait for some other labs to repeat the trial and reproduce the results before counting them as more than promising indicators. It's a big problem that people have been working on for a long time with a lot of incentive to show results and a lot of results that aren't quite as good as advertised, so it makes sense to wait for independent evidence that a solution works before declaring the problem solved Smiley

@Question:
Those are some fascinating observations.  To an extent, I suspect that there are enough specific per-character checks going on to clutter the empirical data, but in a general sense I'd say this supports the notion that each character is associated with a specific slot in memory, and that each slot has an associated set of flags e.g. "in roster", "in party", a numeric value indicating battle slot, etc.  Leo reverting to Banon's death checks probably means that, for the specific slot reserved for Leo/Banon/temp, one of the slot flags (of which there are probably 8 or 16 even if fewer are strictly needed) is examined to trigger the gameover if that character's HP is 0.  With the flag being an exceptional case intended only ever to apply to Banon, and Banon never intended to be in the party when you have a Rename Card, I'm guessing that snippet of gameover message is hardcoded and does not reflect the actual character name.  I will further go out on a limb and assert that whatever bit of whatever byte serves as the "gameover on death" flag, that bit being in its default state implies "yes," and needs to be set to "no" manually during some event (e.g. when Leo is switched into the memory slot).  Rename Card, as previously implied, sets the in-roster and/or in-party flags, probably by overwriting the whole flag bank (byte) rather than doing a proper bitwise comparison, and so executing a Rename Card on Leo blows away the "gameover on death" flag and results in the message you see.

In the mental image I've been forming of this chunk of character-data memory, I've been sticking Temp in the final slot.  Intuition?  I don't know.  But it would explain how, assuming characters are associated with particular fixed slots in memory, and assuming that presence in party/roster is controlled by flags and position in party is controlled by an independent value, Leo/Banon could magically reappear as soon as you leave a slot open.  When Temp is in your party, he is validly flagged as in-party and he has a party position legitimately assigned.  His in-roster flag, however, is not necessarily set.  Therefore, when he leaves the party, no system for showing you your current characters ever picks him up.  So it's conceivable that the event scripts which remove him from your party never bother to null out his party position.  When you set his in-roster flag with a Rename, things get weird.  Now, while party-management interfaces may still not show him (it would be quite easy/sensible for the loop which checks all characters to only go up to memory slot 15 regardless of what's in 16), the battle routine needs to be able to find slot-16 characters.  It probably sets up battles by looking at each battle position, and walking down the list of slots in memory until it finds the first instance of a character with the in-party flag set and the party position set to the battle position it's looking for.  If it doesn't find a character matching that description, the position is left empty.  When more than one character somehow ends up with the same party position set (which "shouldn't happen" if all party management systems are working as intended), the game doesn't care- it just uses the first matching character it finds.  So when Temp is in roster and has his party position set sensibly, then if an earlier character in the memory list also has the same position, that character is used.  But if no other character has that position (the menu screens all show a blank because they only check so far in the general case), the battle init walks right through to slot 16 and finds Temp and sticks him in the battle!
Inns, tents, the party select menu, and other systems dealing with all roster'd characters at once probably only only count to slot 15.  Things which affect character stats probably explicitly hit party positions as well, so that Temp and other off-roster guests behave normally while they're with you.  My remaining curiosity would be with the regular menu- it obviously needs to inspect all 16 memory slots to find the 4 with active characters, and it can obviously find Temp when needed.  And both evidently behave the same way when a "real" character is discovered at a desired position before Temp is discovered.  But if the battle system falls straight through and finds Temp when no other character is around, but the menu system does not, then the menu system has some other bit of intelligence controlling when it searches all the way to slot 16 and when it doesn't...

@funny
Science!  The point here is not how it "should" work for anyone, or how if it doesn't work for me I'm doing it wrong.  I am likely never going to attempt the glitch; I've got too much other stuff going on.  My point is that so far you're the only one posting proof that it does work, and while it makes logical sense that it might from a programming standpoint, logical sense + 1 claim does not make rigorous proof.  If the NIH claimed to discover that jumping up and down 1 million times cured cancer, and theorists surmised that it's a known fact that applying physical pressure to certain cancerous cells helps the body to realign them to their normal function and therefore it is theoretically within reason that applying physical jolts repeatedly to the whole body would have a beneficial effect... I'd still wait for some other labs to repeat the trial and reproduce the results before counting them as more than promising indicators.  It's a big problem that people have been working on for a long time with a lot of incentive to show results and a lot of results that aren't quite as good as advertised, so it makes sense to wait for independent evidence that a solution works before declaring the problem solved :)

Trynabefunny

Edit history:

Trynabefunny: 2013-07-16 07:13:48 pm

2013-07-16 07:13:08 pm

Well, I'm not stopping anyone and I've only heard of one person actually attempting this and it was the one in the video. I'm trying to do the PS1 version right now, burned it to my computer, but loading from CD or using the bin file I created, I can't get past the part when the espers start flooding out. The game freezes. Not sure if it's because I am skipping everything, I used cheats to get to the product quicker since the emulator won't let me speed up the game (you can understand me doing this having done it 100 times), so I don't officially know if it's the image, the emulator, the CD or my CD drive. (chances are it's the emulator)

It'd be great if I weren't alone in this. I haven't even heard if Yohosie attempted this. It works, I made video proof (short but it is proof) of this. Perhaps I'll just make a playthrough of it, even if it is to only satisfy your need of real proof.