TASVideos

Tool-assisted game movies
When human skills are just not enough

Submission #5387: Keylie & Kadmony's SNES Final Fantasy VI "game end glitch" in 29:23.58

Console: Super NES
Game name: Final Fantasy VI
Game version: JPN
ROM filename: Final Fantasy VI (J).smc
Branch: game end glitch
Emulator: lsnes rr2-β23
Movie length: 29:23.58
FrameCount: 105989
Re-record count: 12114
Author's real name: Clément Gallet, L.L.
Author's nickname: Keylie & Kadmony
Submitter: keylie
Submitted at: 2017-02-07 18:24:24
Text last edited at: 2017-02-21 02:00:12
Text last edited by: Nach
Download: Download (9036 bytes)
Status: decision: rejected
Submission instructions
Discuss this submission (also rating / voting)
List all submissions by this submitter
List pages on this site that refer to this submission
View submission text history
Back to the submission list
ALERTS POSSIBLY COMPROMISING MOVIE INTEGRITY:

LSMV starts from a random initialized state

Author's comments and explanations:

(Link to video)

Here is an improvement of 8661 frames from the previous submission, thanks to a route change. Most of the tricks and glitches leading to ACE are identical to the previous submission, so we will only describe the changes in the present text. Comments are embedded in the above video and are available here.

Route change

To reach the Phantom Forest, Sabin and Cyan are mandatory. We choose in this TAS another way for them to join the team, by doing the Kefka at Narshe section. Normally, when you leave Narshe the first time with Locke, you cannot enter Narshe again until much later after the 3 scenarios. However, if you overwrite the events flags stored in the savefile with the ones from the beginning of the game before Locke joins, you can freely enter Narshe. By heading north to the snowfield, you will be able to trigger the fight against Kefka. After that, you can form your team, which contains Sabin and Cyan. Because they did not actually join the team yet, they are replaced by their Moogle placeholder. After that, the route is pretty much the same.

Executed code

The code executed to trigger the ending was improved a bit. We were very lucky this time to encounter the Goblin*2 fight, so we only had to kill one enemy, which shortened the code.

   3A             DEC                   A = 0xFF
   9E 55 3E       STZ $3E55,x [$3EEC]   Unflag enemy death, to avoid an XP/Gold message
   0C 3A 3A       TSB $3A3A             Remove enemies from the fight
   C2 20          REP #$20              16-bit accumulator
   A9 62 13       LDA #$1362            Loads the ending sequence event address
   0C 4F 1F       TSB $1F4F             Set NPC event bit to avoid the ending softlock
   9D 4E 12       STA $124E,x [$12E5]   Set event pointer to the ending
   69 7F 02       ADC #$027F            A = 0x15E1
   1B             TCS                   Fix the stack pointer
   5C C9 18 C1    JML $C118C9           An address in the C1 bank that contains SEP #$20 then RTS
Also, the offset in the color configuration to write this code was optimized to minimize the number of color values to change. Both changes accounted for a total improvement of 7 seconds.

Suggested screenshots

Frames 62280, 95655


Fog: Judging.

Fog: This is a great run that alleviates all of the prior issues that were had with the previous publication, as well as the rejected submission. The use of the new route makes the entertainment factor of the submission much better than the previous publication, where you needed 52 game over screens, while also being faster than the previous publication. Unlike the previous publication, this movie does not start from dirty SRAM (albeit empty). However, there has been some chatter in the submission comments about how this submission seeds the RAM by adjusting the RTC. This is a feature that is built into Higan, the most accurate SNES emulator, and the core that lsnes uses. For it to be used, the TASer must turn on initialize random values in the emulator settings.

And here lies the problem with this run. The movie rules state that there are to be no randomized or unverified initial RAM states. If this run can be completed without using the randomized initial memory, then that run would be accepted. However, it's not possible to accept this run under it's current form.

Rejecting for using randomized initial memory.


Similar submissions (by title and categories where applicable):