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
We have shown a proof of concept for arbitrary code execution in the Japanese version of the game a year ago. However, it requires to gather one of several items that are only available in the late game (after about 2 hours of run), so we let it go. After the discovery of the game over glitch that lead to the latest TAS, featuring 15 boring minutes of game overs, we were eager to find another route that could beat this time and be more fun to watch. This is where we remembered of the mid-frame reset technique used in a couple of published TAS, that might lead to getting these items much quicker. This was the beginning of our third work on this game. Comments are embedded in the above video and are available here.

Glitch leading to ACE

The glitch used to get control over the game is based on the Japanese exclusive equip glitch. This glitch allows you to equip any item in any equipment slot. To equip an item on a weapon slot, for example, you must:
  • get rid of every weapon that a character can equip, so that the equip menu on that slot would show an empty list
  • place the item in the last (256th) slot
  • select "Optimize"
In unassisted speedruns, this glitch is used to equip items that raise your defense and/or magic defense drastically. In this TAS, we are using this glitch on the weapon slot.
During a fight, when you attack with a weapon, the game loads the weapon graphics properties from address $ECE400+8*id into $623B-$6242. Address $6240, which stores if the weapon has a short or long range animation, takes values between 0 and 4. According to this value, the game calls a different function, as shown below:
$C1/C217 AD 40 62    LDA $6240       load $6240
$C1/C21A 29 7F       AND #$7F               
$C1/C21C 0A          ASL A           multiply by 2
$C1/C21D AA          TAX
$C1/C21E 7C 21 C2    JMP ($C221,x)   call one of the routines below

Function pointers:
$C1/C221 34 C2                       call $C1/C234 when $6240 = 0
$C1/C223 47 C2                       call $C1/C247 when $6240 = 1
$C1/C225 2B C2                       call $C1/C22B when $6240 = 2
$C1/C227 C0 C2                       call $C1/C2C0 when $6240 = 3
$C1/C229 21 C3                       call $C1/C321 when $6240 = 4
However, for items that are not weapons, address $6240 can store any value, so that the jump instruction above leads to many wrong addresses. Among all the wrong jumps, the case with address $6240 = 0x07 (weapons X-Ether, Gold Hairpin, Czarina Ring or Charm Bangle) is interesting because the game jumps to address C1/8D7A which starts with instruction:
$C1/8D7A 1B          TCS      Push accumulator to the stack pointer
This instructions corrupts the stack, and will lead us to full control of the game (detailed in another section). The goal of the present TAS is then to collect one of the four items to trigger the ending sequence.

Mid-frame reset

As said in the introduction, all of the four items are only found in the later part of the game. This is why we will be using mid-frame reset to corrupt the game saves. Here are the different options that we used in this TAS:

World Map teleport

World Map coordinates are stored in addresses $1F60 (X) and $1F61 (Y). We can save once at coordinates (X1,Y1), then move to coordinates (X2,Y2), save on the same slot and reset just after the game overwrites the X coordinate. We will be left with a savefile containing (X2,Y1) stored coordinates. This helps to move rather freely around the World Map. Only a few spots are not accessible with this technique (Thamasa and the Triangle Island).

World Map teleport anywhere

This technique can only be used once. The principle is that the game starts inside a town (Narshe) for the first 15 minutes, and the World Map coordinates are never written until you leave the town. They contain uninitialized values until then. When you exit Narshe normally, the game copies the parent coordinates ($1F6B-$1F6C) to current coordinates ($1F60-$1F61). We can manage to load the uninitialized values as coordinates:
  • We save before leaving Narshe in slot 1
  • We save in the World Map in slot 2
  • We load slot 1
  • We save on slot 2 and reset just after $1F61 is overwritten
  • When loading slot 2, we will be on the World Map at coordinates corresponding to the uninitialized values.
In lsnes emulator, it is possible to manipulate the initial RAM values to some extend by setting the value of the Real Time Clock that acts as a seed. The first value of the RAM is set to the lower byte of the RTC, and each consecutive value is generated using a recursive formula:
value = (value >> 1) ^ ( ( (value & 1) - 1) & 0xedb88320)

Map warping

Map id is stored as a 2-bytes value in address $1F64. Using the same principle as with coordinates, it is possible to warp to a new map by using one byte from one map and another byte from a second map. Here is the list of (hopefully) all save points in the World of Balance, and the new interesting maps that we have access using this trick:
Map                            | Map ID
--WoB Save Points--
World Map                      | 0000
Narshe cave entrance           | 0029
Narshe cave                    | 0032
Narshe class room              | 006B
Mt. Kolts                      | 0067
Returners Hideout              | 006E
Lete River                     | 0072
Lete River                     | 0072
Scenario Choice                | 0009
Phantom Train - Tail           | 0092
Phantom Train - Middle         | 0095
Phantom Train - Head           | 0099
South Figaro - Duncan          | 0054
South Figaro - Basement        | 0058
Narshe - Kefka fight           | 0016
Magitek Factory                | 010E
Minecart                       | 0110
Magitek Factory Exit           | 00F0
Cave to the Sealed Gate        | 0182
Esper Cave                     | 0177
Floating Continent - beginning | 018A
Floating Continent - cave      | 0166
--Interesting Maps 
Daryll's Tomb                  | 0129
Fanatics Tower                 | 016B, 0167, 016E, 0172
Caves to the Ancient Castle    | 0192
Hidon's Cave                   | 0195
Kefka's Domain--Pipe Room      | 0199
Gogo's Room                    | 0116

Checksum

The game has a mechanism to detected corrupted savefiles, so we have to bypass it. When saving, it computes the sum of all values of the savefile in a 2-bytes value ($1FFE-$1FFF) and stores it at the end of the savefile. When loading, it computes the checksum and compares to the stored value. If they differ, the savefile is considered as corrupted and cannot be loaded. To overcome this check, we have to modify values in our save so that the checksum match after the sub-frame reset. The easiest way to change a lot of values is to modify the colors of the different window themes.

Route planning

We investigated the quickest way to collect one of the four items (X-Ether, Gold Hairpin, Czarina Ring, Charm Bangle). The fastest route we found was to enter the Ancient Castle using map warping, where there is both an X-Ether and a Gold Hairpin. To enter the Ancient Castle, we need to save in a map with id 01xx (we chose the Cave to the Sealed Gate) and in the Phantom Train. To enter the Phantom Train, we need both Sabin and Cyan in our team, otherwise the game will softlock. There are several ways to quickly get Cyan and Sabin in our team:
  • Manage to enter Narshe (using save corruption), and reach the snowfields where you can trigger the Kefka fight. At the end, you have a character selection screen and you can place Sabin and Cyan in your team. Estimated time: 6 minutes
  • Enter Zozo and climb to the top with Terra. After the cutscene, you have a character selection screen and you can place Sabin and Cyan in your team. Estimated time: 8-10 minutes
  • Go to the Imperial Camp and do the whole sequence. You will recruit Cyan and Sabin will be placed in your party as well. Estimated time: 10 minutes

Checksum bug

The initial route we designed involved an early Narshe escape. When you load the game for the first time, it sets all values in the SRAM to 0. We could take this in our advantage because the map id of the World Map is 0000. By reaching the first save point in Narshe and save/reset just before the map id is overwritten, we could produce a savefile that spawns you on the World Map. Then, we could enter Narshe again and trigger the Kefka at Narshe sequence. However, this did not work because of a flaw in the game programming.
C3/166D: 20D119    JSR $19D1      Calculate SRAM checksum and stores it in $E7
C3/1670: 20EB19    JSR $19EB      Determine if save file is corrupted:
| C3/19EB:	C220    	REP #$20      
| C3/19ED:	A5E7    	LDA $E7      Load calculated checksum
| C3/19EF:	CDFE1F  	CMP $1FFE    Does it match this file's checksum?
| C3/19F2:	D002    	BNE $19F6    Branch if they don't match
| C3/19F4:	8001    	BRA $19F7    Skip next instruction if they match
| C3/19F6:	7B      	TDC          Set A to 0
| C3/19F7:	A8      	TAY          Transfer A to Y
| C3/19F8:	E220    	SEP #$20
| C3/19FA:	60      	RTS
C3/1673: 8491      STY $91        Save result
C3/1675: F00B      BEQ $1682      Branch if result is 0: skip savefile
The consequence of this code is that a savefile is considered as corrupted if the checksum does not match, or if the checksum is 0. In our case, because the checksum is stored at the end of the savefile, it will be 0. So even if the checksum is correct, we won't be able to load the savefile.

Actual route

The first option was still thought to be possible at first, by transferring the event flags from one save at the beginning of Narshe to another save after Narshe. However, we could not do it in practice because we could not control the checksum to match between both savefiles. This was due to the fast that we have 11 Moogles joining the party, which modifies a lot of values in memory and greatly altered the checksum. With only the game options at our disposal to modify the checksum we are limited by the range we can access. In the end, we had to drop this quickest choice.
The current route uses the third way of recruiting Sabin and Cyan. Although it may be slower, the Imperial Camp is very close to the Phantom Train, meaning less travelling. Also, Zozo's boss would be difficult to beat quickly because of an underleveled party.

Arbitrary code execution

The setup

As started in the previous section, attacking with one of the four items corrupts the stack by setting the stack pointer to 0x000E. The game eventually reaches a RTS instruction, so that it loads the 16-bit integer $0F-$10 and jumps to C1/$10$0F. In address $0E-$0F we have the &16-bit battle timer. It starts at 0 at the beginning of the battle and increases by one every frame. In $10 we have a temporary variable that, at the moment of the glitch, can be either 0x0E, 0xAE, 0xCE or 0xEE. In consequence, we can jump to any address C1/0Exx, C1/AExx, C1/CExx or C1/EExx.
We are looking at jumping into RAM or SRAM, and this means getting out of the C1 address bank. We only have limited options to leave this bank: executing jump instructions JSL (22) or JML (5C, DC) that use a full 24-bit address; RTL (6B) is also possible. By examining if there is such instruction in our accessible addresses, we found a good candidate:
$C1/CEC7 5C 6F 60 AE  JML $AE606F
This jumps to address $006F in SRAM, which is just before Shadow's name ($0071-$0076). This is not part of the game code but starts at the middle on a instruction. By carefully renaming Shadow's name, we could jump to some other places where we have full control of the values, like the color windows. But there is a drawback to this: address $0F must contain 0xC7, meaning we have to wait 14 minutes in the fight.
So we looked at another solution, by trying to increase our range of accessible addresses. Now we looked at any jump and return instructions. Because $10 and subsequent addresses correspond to temporary variables, we looked at some places where $11 and $12 were modified, so that we can hit another RTS instruction to jump to C1/$12$11 and reach other places in the C1 bank. We found a really interesting piece of code:
$C1/CE59 A5 0E       LDA $0E    Loads battle counter $0E-$0F
$C1/CE5B 0A          ASL A      Multiply by 2
$C1/CE5C 85 12       STA $12    Stores in $12-$13
$C1/CE5E 0A          ASL A      Multiply by 2
$C1/CE5F 0A          ASL A      Multiply by 2
$C1/CE60 85 10       STA $10    Stores in $10-$11
By choosing carefully our battle counter value, we could control $11 and $12 and jump to new addresses. Now, we looked again at JML and JSL instructions but in the whole C1 bank. We found the instruction JSL $A41E20 at several places in the code (C1/A21C, C1/A239, C1/A256, C1/A276, C1/A30C, C1/A32E, C1/A3CE, C1/A3E6). This jumps to the RAM address $7E1E20 which is at the beginning of a unused segment. Like with the teleport anywhere trick, we manipulated the first two values to be 70 98 (BVS $1DBA), so that we jump to $1DBA which is at the end of the menu configuration. Then we change the colors to write in $1DBA 70 A5 (BVS $1D61) to jump again at the beginning of the menu color configuration, because we won't have enough place to write the full code.
Before writing the full code, we must be sure to be able to execute the above JML instruction. If we write the battle counter in binary and look at the obtained values for $11 and $12, we get:
Battle counter:  $0F = ...abcde | $0E = fghijklm
Return address:  $12 = ghijklm0 | $11 = abcdefgh
So the constraints on the return address are:
  • the high byte must be even
  • the highest 2 bits of the high byte must match the lowest 2 bits of the low byte
We found one good match which is:
Battle counter: 01000110 11010001 (4A 51)
Return address: 10100010 01010010 (A2 52)
The game will first jump to C1/CE4A, which will execute the code above that writes to $11 and $12. Then, when hitting the RTS instruction, it will jump to the value in $11-$12 + 1:
$C1/A253 0E 00 A7      ASL $A700
$C1/A256 22 20 1E A4   JSL $A41E20

Thanks to this new setup, we lowered the time to wait to 0x4A51 = 19025 frames, or 5 minutes and 17 seconds. However, because TAS convention times to the last input, we will use this to our advantage.

The code

We need to write a code that will trigger the ending without any input to do. In details, we need to:
  • Place the ending sequence as the current event
  • Fix the ending softlock that occurs when skipping the transition to the World of Ruin
  • Fix the stack pointer value
  • Finish the fight
  • Avoid any message at the end of the fight that would need to be manually confirmed
  • Return to the normal game execution
Also, there are some constraints on writing using window colors: every other value must be < 0x80.
Here is the following code used in this TAS:
C2 20          REP #$20              16-bit accumulator
A9 62 13       LDA #$1362            Loads the ending sequence event address
18             CLC                   Dummy
9D 4E 12       STA $124E,x [$12E5]   Set event pointer to the ending
0C 4F 1F       TSB $1F4F             Set NPC event bit to avoid the ending softlock
69 7F 02       ADC #$027F            A = 0x15E1
1B             TCS                   Fix the stack pointer
E2 20          SEP #$20              8-bit accumulator
9E 59 3E       STZ $3E59,x [$3EF0]   Unflag enemy 1 death, to avoid an XP/Gold message
7B             TDC                   A = 0
9E 5B 3E       STZ $3E5B,x [$3EF2]   Unflag enemy 2 death, to avoid an XP/Gold message
3A             DEC                   A = 0xFF
8D 3A 3A       STA $3A3A             Remove enemies from the fight
5C EA 4D C1    JML $C14DEA           Or any address in the C1 bank that leads to a RTS

The fight

We need to find a fight where eventually the holder of the glitched weapon will attack at exactly 19025 frames after the beginning. There are several way to provoke an attack without any input, the one we chose was to get the character muddled, so that he automatically executes a random command. We found the Goblin enemy in the Cave to the Ancient Castle that has a very interesting battle script:
 If 1 or fewer monster(s) (total) is/are remaining:
   Rand. spell: L.5 Doom or L.4 Flare or L.3 Muddle
   Rand. spell: Blaze or Nothing or Nothing
Locke is naturally level 6 as we are doing Narshe with Terra level 4 and he gets a +2 bonus when joining, so he will be the holder of the glitched weapon as he is sensible to L.3 Muddle. The battle strat is then to kill all enemies except one Goblin, and manipulate his RNG so that we will cast L.3 Muddle and Locke will attack at the exact moment to trigger ACE. This took about 20 hours of work actually, more than the entire rest of the TAS, but the result is good.

Run comments

Movie creation

We starts the TAS by checking "Random initial state" and setting "Initial RTC value" to 29857. This will write $1F60 = 9B-CD for world map teleport and $1E20 = 70-98 for ACE.

Narshe

Nothing special about Narshe itself. We must get Terra to level 4 so Locke joins at level 6. Level 4 Terra is mandatory anyway to get a quick kill on Whelk.
Before leaving Narshe, we save at the beginners class so that the uninitialized values for world map coordinates does not get rewritten. Then, we go up and open the menu so the map Y coordinate takes the value of 0x34 and save. We enter Narshe again and go again at the coordinate X = 0x18 and save/reset on the previous slot so that it now contains the map coordinates 18-34.

Outside Narshe

We load the save file in the class room and save/reset on the save outside Narshe to overwrite the world map coordinates. By loading the file, we will be placed at coords 9B-CD in the World Map in the Vector continent.

To the Sealed Gate

We use another world map teleport using Y coord from Narshe save and X coord from Vector to arrive near Gau's father house. We buy here a Sprint Shoes and sell Locke's weapon. We use another teleport to arrive in the bridge to the cave. We enter the cave, grab the Assassin weapon for Locke and make our way to the save point. We save/reset once to transfer the weapon to the savefile around Gau's father house, and another save/reset to write the map id on the savefile that has the map coords 18-34.

Imperial Camp

We continue our way until the Imperial Camp, and do the whole sequence (almost) normally. We have help from Locke's weapon which has a 1/4 chance of killing the target. This does not work on MTek Armor, too bad.

Phantom Train

We use a save/reset to teleport over the tile of the Forest entrance. This allows us to enter from the exit, and cut a part of the Forest. We enter the train and save/reset to overwrite only the first byte of the map id. By loading this savefile, we appear in the cave to the Ancient Castle at coordinates 18-34. If we didn't manipulate the coordinates in Narshe, we would appear in the walls out of bounds, and we would be stuck.

Ancient Castle

We enter the Castle, and use the fights to move Locke's Assassin at the bottom of the inventory. We can then equip the Assassin on Cyan using the equip glitch. We grab the X-Ether and leave the Castle. We equip the X-Ether on Locke and a Shield. The shield is mandatory, otherwise Locke would attack with bare hands during the fight and the glitch won't trigger. We write the code to execute by changing the colors in the menu.

Last fight

We kill the two enemies with Cyan, using the wait trick (opening a menu to freeze the enemies ATB during an animation). Then we produce lag in the RNG counter by selecting and un-selecting a weapon, to get the right setup. When we confirm Locke's steal command, the movie ends. After 5 minutes of fight, Locke attacks and the ending triggers.

Special Thanks

  • bover_87 for the enemy battle script FAQ
  • ff6hacking website for centralizing and showing new data on ff6

Suggested screenshots

Frames 73132

fsvgm777: Replaced with a LSMV that removes an empty SRM file. The total time remains unchanged.
Samsara: (J)udging.
I see three big arguments in the submission thread, so let me break them down real quick.
1. "This is a different kind of ACE, so it should be a separate category"
That's not how we do things. This specifically aims for the fastest glitched time. The Nico TAS that's 18 seconds faster than this one (and that's not counting this submission ending input 5 minutes early, but I won't be pedantic about that) also aims for the fastest glitched time. For the purposes of this site, "game end glitch" refers to any way that the ending is reached far earlier than expected. This could be something as simple as holding two buttons on an elevator and landing somewhere, or crashing the game in a way that lets you manipulate your way to the ending, or just going up and down stairs a bunch. "Game end glitch" is exactly how it sounds: The run uses a glitch to end the game. Both this run and the Nico TAS use glitches to end the game. Therefore, they are both "game end glitch" runs. We have a separate ACE branch, but it is only used for playaround runs. Since this was treated as an improvement to the published run (thus, the fastest run) and not as an entertainment-based category, we have to treat it as such as well.
2. "This run is more entertaining, so it should be a separate category"
That is also not how we do things. This is not a playaround run, we cannot treat it as such. The authors intended for this to be an improvement to the published run as the fastest time for this game. Unfortunately for them, a separate team completed a run with a faster time that just so happens to not be nearly as entertaining. Sure, entertainment is a huge focus for us as TASers, but for years now it has not been the primary focus. We do publish new categories if people find them entertaining enough, but not two runs in the same category. And yes, all of these arguments do end up going in circles and coming around to the same point, that the detractors are almost literally saying "publish this run in the same category as a different category".
3. "The faster run is not being submitted, so this should be published anyway"
Pop quiz: Is this how we do things? No. The existence of the faster run is the reason why we can't accept it. It doesn't matter where it exists, how it exists, or when it exists. What matters is that we have it as public knowledge. There's an input file for us to easily verify it. There's an encode for people to watch it. It's there. It's faster. We don't publish RTA runs here, but if a TAS is slower than an RTA run then we reject it exactly because of that. Part of the judgement process is verifying that the run in question is the fastest known record for the game. We're human, we do miss clear and known improvements sometimes, especially ones hosted nowhere except on a OneDrive link that's only shared on Twitter to a small group of people, and yes there are times where we accidentally publish a run before we find a known improvement. But this is not the case.
Trust me, I think this is a great run and I would have loved to see it accepted and published, but this particular run in its current state, as I and others have mentioned several times before, cannot be published, even as a different category. I extended some leniency, hoping that there was a way the run could be salvaged and improved or at least explained in a way that makes it drastically different enough to publish, but over the responses I see in the thread it doesn't look like anything I suggested is going to be met. There was a slight ray of hope in the Nico TAS starting from dirty SRAM, but looking at the file more closely the SRAM is blank, much in the same way that this submission was at first, so it turned from a ray of hope into the final nail in the coffin.
Rejecting for not beating the fastest known time.


Samsara
She/They
Senior Judge, Site Admin, Expert player (2238)
Joined: 11/13/2006
Posts: 2822
Location: Northern California
Chanoyu wrote:
I have only one question, and that is what effect the run recently posted in the FFVI thread, which is 31:29 long, though by no means as entertaining, has.
Thank you kindly for bringing this up. My memory failed me and I thought KadMony's post was in this thread (and deleted) instead of the FF6 thread. The problem with accepting this now is that a speed-oriented run of any game has to beat all existing records in its specific category, regardless of whether or not it's in Vault or Moons. We can't accept a slower, more entertaining run in the same category unless it's a playaround/glitchfest run, and technically we're treating this as the any% category so that can't happen here. The only ways we can accept this run now are either if one of the different setups/routes mentioned in the submission text ends up working out and saving enough time to beat the 31:29 run, or if there's enough strong evidence that this run is different enough to the Nico TAS/currently published GEG run to be considered a separate category. Keylie and KadMony, I'll leave the run un-judged in case you two want to do more testing with the alternate strategies and see if you can shave off those 20-ish seconds needed to beat the other run. If it doesn't seem possible, or if an improvement would take a while to complete, I would recommend cancelling this run in the meantime while everything is worked out.
TASvideos Admin and acting Senior Judge 💙 Currently unable to dedicate a lot of time to the site, taking care of family. Now infrequently posting on Bluesky
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
keylie
He/Him
Editor, Emulator Coder, Expert player (2840)
Joined: 3/17/2013
Posts: 392
Samsara wrote:
or if there's enough strong evidence that this run is different enough to the Nico TAS/currently published GEG run to be considered a separate category.
I think that this run deserves its own category for one specific reason: it triggers the end using ACE and I believe such TAS should still be published in the case it failed to get the fastest possible time. Showing and documenting a glitch that gives access to total control is important for me, as it may be reused for other purposes. I'm thinking about GDQs for example, even if some people started to get bored of ACE-derived demonstrations. Also, it features sub-frame reset which is largely neglected for now. I would like to see more people using this technique.
Samsara wrote:
Keylie and KadMony, I'll leave the run un-judged in case you two want to do more testing with the alternate strategies and see if you can shave off those 20-ish seconds needed to beat the other run. If it doesn't seem possible, or if an improvement would take a while to complete, I would recommend cancelling this run in the meantime while everything is worked out.
I currently don't have any idea for a better route. Because of all the freedom we have, we may have missed faster routes, but I'm not going to work on it again. Honestly, I'm quite tired of this game. I worked almost exclusively on this game during the last 2 years and this is the third TAS we submit. I don't understand your last sentence though. Why do you recommend to cancel it? What do you expect to happen in the meantime? I understand if you take your time to take a decision about it, but why does it need to be cancelled?
Experienced player (704)
Joined: 2/5/2012
Posts: 1795
Location: Brasil
it's the fastest we have,i also don't understand why the suggestion..oops,now i get it,but that run wasn't submitted so i still think we should have this one published until someone does the other setup.
I want all good TAS inside TASvideos, it's my motto. TAS i'm interested: Megaman series, specially the RPGs! Where is the mmbn1 all chips TAS we deserve? Where is the Command Mission TAS? i'm slowly moving away from TASing fighting games for speed, maybe it's time to start finding some entertainment value in TASing.
Patashu
He/Him
Joined: 10/2/2005
Posts: 4043
It would be a great shame if this run were unable to be published here. The problem is its category, 'game end glitch', is the same as the category the 31:29 run would be published as. I'm not sure how to work around this. (Except maybe by having an 'arbitrary code execution demonstration' style category, that doesn't have to be the fastest any%? Don't think there's precedent for it but this would be a good place to start.) On the other hand, it is faster than the published 'game end glitch' run. Is there a precedent for a known not fastest run to be accepted (if the actual fastest run is not being submitted and might not ever be)?
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
JoshButro
He/Him
Former player
Joined: 1/8/2015
Posts: 43
Patashu wrote:
Except maybe by having an 'arbitrary code execution demonstration' style category, that doesn't have to be the fastest any%? Don't think there's precedent for it but this would be a good place to start.
But now doesn't this run fit the same reason that the Super Metroid 100% Map Completion TAS was rejected: Too many categories for a game. This seems like a new category name is being created to publish this, instead of dissecting the existing movies and seeing if there is a faster way. It is an awesome video and looks like a lot of work went into it, so that makes this decision difficult on what to do.
current TAS: Q*Bert 3 any% v2TAS<br> next TAS: Q*Bert 3 X*Bert levels
Former player
Joined: 6/30/2010
Posts: 1107
Location: Zurich, Switzerland
JoshButro wrote:
Patashu wrote:
Except maybe by having an 'arbitrary code execution demonstration' style category, that doesn't have to be the fastest any%? Don't think there's precedent for it but this would be a good place to start.
But now doesn't this run fit the same reason that the Super Metroid 100% Map Completion TAS was rejected: Too many categories for a game. This seems like a new category name is being created to publish this, instead of dissecting the existing movies and seeing if there is a faster way. It is an awesome video and looks like a lot of work went into it, so that makes this decision difficult on what to do.
I don't think anyone would reject a TAS only because of the number of publications per game. New categories that aren't any% or 100% are rejected if they are not entertaining or too similar to an already published category of the same game.
Current project: Gex 3 any% Paused: Gex 64 any% There are no N64 emulators. Just SM64 emulators with hacky support for all the other games.
Invariel
He/Him
Editor, Site Developer, Player (171)
Joined: 8/11/2011
Posts: 539
Location: Toronto, Ontario
Actually, there's the question of whether the stack corruption that happens due to dying 50+ times on the map is ACE, which would then continue to beat this run in specific category as well as in any%. [2922] SNES Final Fantasy VI "game end glitch" by keylie & KadMony in 32:54.55
The Published Movie wrote:
Our goal is to write somewhere in RAM an event that will jump to the ending. A few events can do that: B2, B3, B6, B7, BD, BE, C0-CF, following by the destination address (e.g. B2 4E 13 00 jumps to $CA0000 + $00134E = $CA134E).
This sounds a lot like ACE to me. And because the NicoNico video uses the same tactic as the published movie, that is also ACE to me. Even though this is ACE with a mid-frame reset (which is awesome), it's slower than the other ACE movie.
I am still the wizard that did it. "On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." -- Satoru Iwata <scrimpy> at least I now know where every map, energy and save room in this game is
keylie
He/Him
Editor, Emulator Coder, Expert player (2840)
Joined: 3/17/2013
Posts: 392
Invariel wrote:
Actually, there's the question of whether the stack corruption that happens due to dying 50+ times on the map is ACE, which would then continue to beat this run in specific category as well as in any%.
This is not the same level of code. In the 52GO run, we can execute any game script code we want. The game features scripting code to build cutscenes. To put it in another way, we can only write stuff that will be executed by the game own engine. You can have a look at the specifications here (search for General Actions).
Player (109)
Joined: 11/3/2014
Posts: 9
@Invariel no, 52 GO glitch leads to get only control on the game scripts (cutscenes) needless to say they can be bugged, which is not ACE. The two TASes indeed give a good example of the differences between the techniques if you look at how we remove the ending softlock : for the 52GO glitch we have to launch the cutscene (in the begining of the WoR) in which the game itself sets the needed variable to the good value and thus does not softlock during the ending. In this TAS ACE allows full control on the game and thus the variable is directly set to the good value through instruction, not through loading the good cutscene. As for the other questions around the subsmission, it seems first clear to me that this TAS will not be faster than the 52 GO one. The 52 GO TAS done by Japanese is moreover not perfectly optimized and will soon be slightly faster. I also totally agree with Kilaye on the fact that ACE -and mid frame resets- are far reaching techniques which deserve to be shown, even if it would be in a specific category and some seconds later than the 52 GO TAS -which i actually also find interesting (and fast) even though it seems trendy to say it's shit-. As for the fear of having too much FF6 TAS, i simply would like to point out that this submission is the first one on JP version and we produced 2 TAS on the US one, which seems very reasonable to me. We produced 3 TASes the last 2 years, the first one -obviously the most important- was obsoleted for really debattable reasons and put in a separate category, the second one seems to be considered as garbage/shit. I personally do not crave for any lucidity from the community, still we will certainly not cancel this submission, which deserve much more a specific category than the 'sketch tas'.
Invariel
He/Him
Editor, Site Developer, Player (171)
Joined: 8/11/2011
Posts: 539
Location: Toronto, Ontario
With all due respect to the both of you (and with the caveat that I am not a judge), in the 52GO run, you write instructions in RAM by setting things up in the inventory and game state such that when the 52nd game over is triggered, "The game loads those values as the current event pointer, and executes events starting this location." You are executing arbitrary code that has been generated by your gamestate. In the current submission, you are again taking advantage of the stack pointer by attacking with an item that you shouldn't be able to equip. Your payload is different, absolutely, but your vector is the same. "As started in the previous section, attacking with one of the four items corrupts the stack by setting the stack pointer to 0x000E." "We write the code to execute by changing the colors in the menu." Both of these are examples of ACE, and while this submission seems like it has a greater number of options for the arbitrary code that can be written, 52GO is still executing arbitrary code. I am in no way attempting to invalidate your efforts here, and I did vote "yes" as to finding this entertaining (because it is), but my assessment and opinion is that this and 52GO are both ACE, and thus the same category with different routes.
I am still the wizard that did it. "On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." -- Satoru Iwata <scrimpy> at least I now know where every map, energy and save room in this game is
keylie
He/Him
Editor, Emulator Coder, Expert player (2840)
Joined: 3/17/2013
Posts: 392
Invariel wrote:
With all due respect to the both of you (and with the caveat that I am not a judge), in the 52GO run, you write instructions in RAM by setting things up in the inventory and game state such that when the 52nd game over is triggered, "The game loads those values as the current event pointer, and executes events starting this location." You are executing arbitrary code that has been generated by your gamestate.
When we are talking about "code" in ACE, to me this is short for "assembly code", or a sequence of assembly instructions. If we use that definition, then the 52GO run does *not* allow to execute arbitrary assembly instructions, thus it is not ACE. Edit: you may argue about the definition of "code" in ACE, but be aware that this is not the same type of code that is executed in either TAS.
Samsara
She/They
Senior Judge, Site Admin, Expert player (2238)
Joined: 11/13/2006
Posts: 2822
Location: Northern California
For the purposes of the "game end glitch" category on this site, it encompasses more than just ACE. Other methods of triggering the ending early count as well. Some of them don't even execute code at all. That's why it's difficult to accept this run: Even if the method is different, it's still triggering the ending early, so the Nico TAS is in the same category by our terms. I'd rather not reject the run either, which is why I haven't done so already in case we can find a solution, but justification for acceptance is hard to come by with a finished, faster run out there and available to us.
TASvideos Admin and acting Senior Judge 💙 Currently unable to dedicate a lot of time to the site, taking care of family. Now infrequently posting on Bluesky
warmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Joined: 4/3/2005
Posts: 575
Location: Spain
ACE could be used to accelerate the game ending sequence so that it ends earlier than the other run. ACE could be used to create a Newgame+ mode and beat it as fast as possible, starting from a verified savestate. ACE could be used to code another FF game and then it would become a TAS that beats both games, deserving its own category.
No.
Joined: 1/14/2016
Posts: 100
For the purposes of the "arbitrary code execution" category on this side, this run is decidedly different from the other FFVI runs, and the fastest of its sort. The site doesn't even have a category for sub-frame resets. I think it is silly to keep an old, known to be suboptimal in its category, run, and reject a new, different, not known to be suboptimal in its more specific category, run. If you want a strict interpretation of the rules, you could accept this run in the non-vaultable ACE/demonstration category. As the runs of Super Mario World demonstrate, it is possible in the current framework to have a "game end glitch" and a slower "arbitrary code execution" category.
Player (26)
Joined: 8/29/2011
Posts: 1206
Location: Amsterdam
Chanoyu wrote:
As the runs of Super Mario World demonstrate, it is possible in the current framework to have a "game end glitch" and a slower "arbitrary code execution" category.
That's not really accurate. There are two SMW runs with ACE, one with the goal "complete the game as fast as possible", and another with the goal "program your own minigame". Those are clearly two different branches. "Complete the game as fast as possible" and "complete the game really fast but slower than the other run" are not.
Player (109)
Joined: 11/3/2014
Posts: 9
@Invariel for us ACE is "Arbitrary Code Execution", while 52 GO only executes arbitrary cutscene, not any code. Still i understand your point of view, it makes sense and this is probably something real computer specialists (which i'm not) can have clear ideas about. @radiant i think Chanoyu wants to says that this one should be placed as "ACE run, fastest time", a then new category. This is again a matter of considering the 52 GO as ACE or not. For me it's not, but real expert may have more sophisticated debates around it to decided whether it is the case.
keylie
He/Him
Editor, Emulator Coder, Expert player (2840)
Joined: 3/17/2013
Posts: 392
Samsara wrote:
Keylie and KadMony, I'll leave the run un-judged in case you two want to do more testing with the alternate strategies and see if you can shave off those 20-ish seconds needed to beat the other run.
Actually, it is possible to save about 45 seconds with an emulator that supports setting arbitrary values in the initial RAM state. It would save about 25 seconds by teleporting directly on the bridge to the Cave to the Sealed Gate instead of close to it (saving two save/reset), and 20 seconds by writing the code directly in RAM instead of using the window colors. There was a topic some time ago about allowing such feature, and the feedback was mixed as far as I remember. Edit: Thread #14564: Site policy regarding Alternative RAM stats on Power-up
ALAKTORN
He/Him
Former player
Joined: 10/19/2009
Posts: 2527
Location: Italy
Invariel wrote:
With all due respect to the both of you (and with the caveat that I am not a judge), in the 52GO run, you write instructions in RAM by setting things up in the inventory and game state such that when the 52nd game over is triggered, "The game loads those values as the current event pointer, and executes events starting this location." You are executing arbitrary code that has been generated by your gamestate.
That is not arbitrary. Arbitrary means it can be whatever you want it to be, not just a specific part of something that’s not supposed to be run normally.
Active player (428)
Joined: 9/7/2007
Posts: 329
Voted yes because this is much more entertaining than sitting through 52 game overs. I haven't watched the new test TAS on nico because its player doesn't work for me, but I'm sure it is similar enough to the obsolete TAS that it would not be as entertaining as this one.
Skilled player (1785)
Joined: 5/7/2008
Posts: 187
Location: Japan
This is precious TAS with ACE. Yes vote. Because 52GO TAS is not ACE, this will be another thing. Probably run of the length of 31:29 is not submitted.
Experienced player (704)
Joined: 2/5/2012
Posts: 1795
Location: Brasil
i'm with pirohiko,accept this,we'll never see the submission of the nico tas anyway.
I want all good TAS inside TASvideos, it's my motto. TAS i'm interested: Megaman series, specially the RPGs! Where is the mmbn1 all chips TAS we deserve? Where is the Command Mission TAS? i'm slowly moving away from TASing fighting games for speed, maybe it's time to start finding some entertainment value in TASing.
TASVideosGrue
They/Them
Joined: 10/1/2008
Posts: 2785
Location: The dark corners of the TASVideos server
om, nom, nom... blech, bitter!
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3821)
Joined: 11/30/2014
Posts: 2829
Location: US
Aww, too bad, I hope this gets turned into a neat play around so it can get published. I also hope the actual fastest run gets submitted. Anyway to ask the authors about it?
keylie
He/Him
Editor, Emulator Coder, Expert player (2840)
Joined: 3/17/2013
Posts: 392
Alyosha wrote:
I also hope the actual fastest run gets submitted. Anyway to ask the authors about it?
Well Pirohiko is one of the authors, so the TAS will be submitted if the authors want to.
Patashu
He/Him
Joined: 10/2/2005
Posts: 4043
Well, isn't the 52GO run in japanese only faster because of the language change? If it's better optimized period, then go ahead and submit it. Otherwise not much point...
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu