Submission Text Full Submission Page
  • Emulator: lsnes rr2-beta23
  • Rom: Final Fantasy VI (J)
  • Aims for fastest time
  • Manipulates luck
  • Executes arbitrary code
  • Features mid-frame resets
  • Corrupts save data
  • Ends input early
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.


Noxxa
They/Them
Moderator, Expert player (4128)
Joined: 8/14/2009
Posts: 4090
Location: The Netherlands
SmashManiac wrote:
Please excuse my ignorance on the matter, but does a RAM state containing only zeroes must be proven possible on a given console now before submitting a run with this property? I realize that this is probably true for most computers by waiting long enough on a power off state, but I don't think it's true for the general case. If my fear is justified, it would put the validity of most published movies into question.
What the rule forbids is using unproved/customized states, particularly to gain an advantage. The default RAM state of emulators for many consoles is indeed unproven (and in some cases probably invalid), but that is something we can't really do anything about without (retroactively) outlawing the majority of runs on the site. By allowing the default emulator state, no specific run is particularly advantaged or can specifically exploit it, so we can at least consider it a neutral state. If that is an invalid state, then that can be chalked up to just an emulator inaccuracy, and not a TAS exploit.
http://www.youtube.com/Noxxa <dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects. <Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits <adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Dwedit
He/Him
Joined: 3/24/2006
Posts: 692
Location: Chicago
Supposedly, the NES's uninitialized memory is mostly FF but with some bits randomly cleared. It's consistent enough for games like Final Fantasy 1 to have a predictable RNG. I wonder if the SNES is also like that too?
Player (13)
Joined: 6/17/2006
Posts: 510
Mothrayas wrote:
By allowing the default emulator state, no specific run is particularly advantaged or can specifically exploit it, so we can at least consider it a neutral state. If that is an invalid state, then that can be chalked up to just an emulator inaccuracy, and not a TAS exploit.
I understand now. Thanks a lot!