Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
At the very beginning, at 0:15, wouldn't it be faster to slow down instead of hitting the wall, and then clear the obstacle at maximum velocity both upwards and to the left? Or is the problem that slowing down (by moving right) also moves you upwards, which is counterproductive?
Around 0:40, the two first steps down are done differently than the last. Why?
Also, I'm worried that the star shepherding is suboptimal. the star tries to follow you, so to avoid having it run into corners, can't one do better than just running ahead of it and waiting for it? For example, around 2:50 the star runs into the wall and loses its forward velocity because it is trying to move towards ikachan, and ikachan is ahead of it. Wouldn't it be faster to position ikachan above the star at that location, making it slow down a bit and accelerate upwards in order to clear the ledge, and only then run ahead with ikachan again? And around 3:04 it looks like you wait slightly longer than necessary for the star, as it clears the ledge with a good margin. And just after, at 3:05, wouldn't it be better to led ikachan fall along the left wall, so that the star ends up further left. That would give it room for a running start for entering the passage just after.
But I haven't actually played the game, so take my comments with a grain of salt.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I think this is a pretty good solution - certainly a big improvement on what we have now.
(But I'm confused about "Arbitrary Code - Level ending". Why would you just end the level when you have the power to do anything you want?)
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I've done some work on making it easier to make EAC TASes for super metroid by making a small macro language that lets you write inline assembly in lsnes input files. It's only partially tested at the moment, but it should remove some of the error-prone tedium from this when it's done. The example from the readme-file (which you can see by scrolling down on the linked page) bootstraps a general main loop that lets you run arbitrary amounts of subframe input each frame while the game is still running.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I like thatguy's suggestion of "researcher". It's not a complete match, though, as research and tool-development aren't the same thing. But in practice most people who do one does the other too. And it's clear, if perhaps a bit grandiose.
I also like the original suggestion of "assistant".
Perhaps a poll would be in order?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I think there are two issues here:
Specific or general category names
What the default constraints on a TAS are
Specific vs. generic
For the first issue, I have previously argued that while I sympathize with the wish to have as objective and explicit category names as possible, being too specific runs the risk of overfitting, where one ends up describing incidental details of a TAS rather than the point of the category. This makes the category non-future-proof, needing to be amended with a potentially ever-growing list of prohibited glitches. And which glitches to include in that list would be a subjective judgment. So overly specific category names do not provide the objectivity they at first seem to promise.
That said, I do think it is good to maintain a list of which glitches are being avoided for each category. One could decompose categories into a "statement of intent", describing what the category is about and allowing it to adapt to new discoveries; and "current interpretation", a list of the glitches that are currently deemed to be excluded from the category. But I think the "statement of intent" part, such as "less glitched", makes the most sense as the category name, as it is
short, descriptive and unchanging. The "current implementation" part is a detail better mentioned in the movie description.
Default constraints
For the second issue: Any%/unlabeled TASes are set of inputs that complete the game as fast as possible under the default constraints. These default constraints used to be something like
No passwords
No cheat codes (?)
Hardest difficulty unless it only adds to boss hp (?)
No game-breaking glitches
Deviations from the default constraints must be mentioned explicitly. For example, a 100% TAS has an added constraint of having to collect every item or similar, and this is mentioned explicitly in the category because it's not part of the default constraints. Similarly with glitched categories.
Recently, "no game-breaking glitches" was removed from the default constrains, turning "glitched" categories into "any%" and "any%" into "no foo-glitch" or "less glitched" or similar. But this hasn't been done consistently. For a glitched game with many categories one would typically have a single "glitched" category and many other "less glitched" categories such as "any%", "100%"*, "low%", "pacifist" etc. So to be consistent, not only "any%" should be renamed to "no foo-glitch", so should "100%" be renamed to "100%, no foo-glitch" and so on with the other less glitched categories for each game.
I think whether "no game-breaking glitches" should be part of the default constraints depends on what constraints the majority of categories use. If almost all of them assume no such glitches, then factoring that out into the default makes sense, like with the "no passwords" constraint. But I'm fine with either way, as long as it is done consistently.
*: We do have a few examples of glitched 100% runs, though, for example from the castlevania series.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
For an any% or 100% TAS, the current question is mostly sufficient (though it would still be nice to have an option for "this TAS is too sloppy/slower/doesn't fulfill its goals and shouldn't even go in the vault") because in that case one is only determining which tier the run should be published in.
But for TASes of other goals which currently aren't allowed in the Vault, the implication of not being fun enough for Moons is not being published at all. So regardless of what the poll text says, the real question is "should this TAS be published", and hence that's the question people are going to answer. And the answer to that may be different from the answer to "were you entertained", because some people don't agree that only any% and 100% deserve record keeping. For example, I think that any optimized TAS of a category with a well-defined non-entertainment-based obsoletion criterion (i.e. not playarounds, but most other categories) should be allowed in the Vault.
Another example of the "were you entertained" question being insufficient would be a very sloppy but entertaining TAS. The vote should make it possible to point out that there is a serious problem with a TAS despite it being entertaining.
So I suggest asking these questions:
Does this TAS fulfil its stated goals? (Eg. does a "no A button TAS" actually not press the A button)
Is it sufficiently optimized?
Is it entertaining? (determines Moon eligibility)
Should it be published? (not binding, of course)
Of course, the best thing to do is to not just answer the poll, but also post a response. But if what you want to say has already been said, it feels spammy to post "me too" or just repeat those points if you don't have anything to add. One way around this would be a moderation system like what they have on stackoverflow or slashdot, but that would require huge changes to the forum which I do not think are realistic. And in the absence of that, I think adding more granularity to the question being asked would both satisfy voters and make more information available to judges.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
This was a fun TAS. Thanks, Masterjun! Some opportunities to entertain were missed (which I understand, since it had to get done in time for april fool's day), but it was still a good watch. I was entertained and I think this should be published. Edit: On further thought, I think that while this one is a good april fool's submission, it's not optimized enough to be pblished. But I think an optimized version would be publishable.
The question is what category is should be published in. This TAS is very heavily glitched - it uses a glitch that allows arbitrary code execution, and uses that to finish the game using the normal shortest route - the 11 exit path. So the most natural category for this TAS would be "glitched normal route", which would be in line with our old naming scheme, and also with schemes used in unassisted speedrunning.
Another suggestion has been to let this obsolete the normal "11 exit" TAS. I do not agree with that. The whole point of that TAS is to complete the game as fast as possible without using completely game-breaking glitches. That it completes 11 exits is quite incidental. If somebody discovered a secret exit in yoshi's island 1 that lead to bowser valley 1, then I'm sure that would obsolete the "11 exit" TAS. So in my opinion that category is misnamed - the category name captures a minor detail of the TASes that are in it (i.e. that the complete 11 exits), rather than what the category is actually about (fastest normal completion). And this leads to things like suggesting that a heavily glitched TAS should take the "11 exit" record, leaving us with no fastest low-glitch category any more.
It's a bit where having a race where cycles and cars are in different categories because it's fun to see how fast one can go under pedal power. But instead of naming them "cycles" and "cars", or perhaps "no engine" and "no hold barred", they're called "yellow vehicles" and "any color vehicles" because all the cycles happened to be yellow during the first few races. And then somebody makes a yellow car and uses it to win the "yellow vehicles" category, completely removing the original point of that category.
As a small side note, I'll point out that depending on what one means by completing an exit, it's possible to do this much more quickly: Just set the level completed flags directly in memory, and then jump to the end. Things inevitably get vague when arbitrary code execution is combined with other goals.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I though of something similar recently: How to make console verifiable TASes of SNES games with tight timing dependencies, such as Super Metroid. Ilari has shown that a typical Super Metroid TAS will desync if the ratio of the two oscillator frequencies changes by a tiny fraction, much less than the actual stability of real hardware oscillators. So this sounds like it would doom a Super Metroid TAS (or similar) to always desync on console.
However, it might be possible to make a less timing sensitive TAS using the same techinques as for multi-game TASes, treating a set of different oscillator frequencies as individual games. Hopefully, if one makes a TAS that syncs with 10 different such ratios, then it will be robust enough to sync for other small frequency variations. A data point in favor of this is that Ilari found the desyncs to tend to happen certain problem spots in the game (which would be more and more frequent (but still discrete unless I misunderstood) as the timing difference grows).
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
PJBoy: It jumps there from $91beb2. I just used x-ray quite normally (while being oob). The code leading there did not seem particularly glitchy. That eye enemy uses a similar effect to the x-ray scope, so it wouldn't be odd for them to share some could, would it? Here is <a>a trace</a> of the execution leading up to it. It starts from just after we return from interrupt, which released the code from a long waiting cycle.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I'm currently investigating the Yapping Maw shinespark glitch:
Link to video
It crashes the game, and as we all know, crashes often lead to arbitrary code execution, and this glitch only depends on the speed booster (and a yapping maw). Tracking down the full mechanism of this glitch is complicated, but a rough sketch is that $a60 contains a pointer to code to run depending on Samus' pose. When moving normally it has the value e913, but while shinesparking it has the value e90e. When yapping maws releases Samus, it sets this value to e913 (moving normally) even if she is shinesparking. This messes up the handling of the speed echoes that are supposed to circle around Samus when she hits a wall. A mirror of Samus' pose in $a28 is supposed to contain ffff when she stops sparking, but due to this error, it contains her actual pose, which further down the line causes ffff to be written to $aae. Which finally leads to this:
90d346 lda #$000f A:ffff X:0080 Y:0004 S:1ff4 D:0000 DB:90 NvmxdizC V: 56
90d349 sta $0a68 [900a68] A:000f X:0080 Y:0004 S:1ff4 D:0000 DB:90 nvmxdizC V: 56
90d34c lda $0aaf [900aaf] A:000f X:0080 Y:0004 S:1ff4 D:0000 DB:90 nvmxdizC V: 56
90d34f and #$00ff A:90ff X:0080 Y:0004 S:1ff4 D:0000 DB:90 NvmxdizC V: 56
90d352 asl a A:00ff X:0080 Y:0004 S:1ff4 D:0000 DB:90 nvmxdizC V: 56
90d353 tax A:01fe X:0080 Y:0004 S:1ff4 D:0000 DB:90 nvmxdizc V: 56
Things are sensible up to this point, where we perform the jump
jsr *$d37d[($aaf&ff)<<1].
We jump far into a region of the rom which is filled with ffffffff, which we execute
until we wrap around into RAM. $d37d is ROM, so what's going wrong must be
$aaf, which is documented as an index used for shinespark echoes.
This value is ff here, but is not set in this file. Should compare with normal shinespark
90d354 jsr ($d37d,x) [90d57b] A:01fe X:01fe Y:0004 S:1ff4 D:0000 DB:90 nvmxdizc V: 56
90fead sbc $ffffff,x [0001fd] A:01fe X:01fe Y:0004 S:1ff2 D:0000 DB:90 nvmxdizc V: 56
...
90fffd sbc $d3ffff,x [d401fd] A:01fd X:01fe Y:0004 S:1ff2 D:0000 DB:90 nvmxdizC V: 59
900001 sta $0000,x [9001fe] A:01fd X:01fe Y:0004 S:1ff2 D:0000 DB:90 nvmxdizC V: 59
900002 brk #$00 A:01fd X:01fe Y:0004 S:1ff1 D:0000 DB:90 nvmxdizC V: 59
900003 brk #$04 A:01fd X:01fe Y:0004 S:1ff0 D:0000 DB:90 nvmxdizC V: 59
900004 tsb $b5 [0000b5] A:01fd X:01fe Y:0004 S:1ff1 D:0000 DB:90 NvmxdizC V: 59
900006 bra $ff88 [8fff88] A:01fd X:01fe Y:0004 S:1ff1 D:0000 DB:90 NvmxdizC V: 59
900009 brk #$98 A:cc1b X:01fe Y:0004 S:1ff1 D:0000 DB:90 NvmxdizC V: 59
90000c brk #$53 A:001b X:01fe Y:0004 S:1ff1 D:0000 DB:90 nvmxdizC V: 59
90000d eor ($00,s),y [909094] A:0036 X:01fe Y:0004 S:1ff1 D:0000 DB:90 nvmxdizc V: 59
90000e brk #$27 A:0036 X:0036 Y:0004 S:1ff1 D:0000 DB:90 nvmxdizc V: 59
We enter oam here, and survive for a surprising amount of time
9004a9 beq $04ab [9004ab] A:0036 X:0036 Y:0004 S:1fef D:0000 DB:90 nvmxdizc V: 59
...
Ok, this brk is real. The others must be fake somehow. Amazingly, we get all
the way to 4f1 here, which is in oam I believe. So with lots of luck, one could
manipulate oam to jump somewhere better.
9004f1 brk #$0e A:9dd3 X:0037 Y:007e S:1ff7 D:0000 DB:90 NvmXdizC V: 60
008573 jml $808573 [808573] A:9dd3 X:0037 Y:007e S:1ff3 D:0000 DB:90 NvmXdIzC V: 60
The upshot of all this is that the Yapping Maw shinespark glitch ends up executing RAM as code, and while we have less control than with the charged space-time beam, it makes it into the powerful but tricky OAM region of memory, which is the same one I used for my original game-ending demonstration video.
So I think this is pretty pomising, and certainly worth more investigation. If it could be made to work, one could make a TAS that makes a beeline for the speed booster, and then heads for the closest yapping maw.
Edit: Total and I have investigated this now. It seems like snes9x does not emulate this correctly. In lsnes it seems like this inevitably leads to a BRK soon after it starts executing RAM. Too bad.
Edit2: It seems like the lava/sand shinespark crash is practically the same as the yapping maw glitch, including the same wrap-around to RAM, and the same method of avoidting the glitch (holding a button). So that's another promising method that didn't work out. Though, the current approach is already fully workable, we just hoped one could go faster.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Wow, fantastic Total! PJBoy and I were discussing whether OOB could be sufficient to jump to the ending, or even execute arbitrary code, but the route we thought of was to try to exploit glitched door transitions, and the whole setup seemed pretty unlikely. The X-ray method seems really promising!
Edit: I looked at what happens when using the X-ray OOB:
$91/C505 08 PHP
$91/C506 C2 30 REP #$30
$91/C508 A5 18 LDA $18
$91/C50A 3A DEC A
$91/C50B 0A ASL A
$91/C50C A8 TAY
$91/C50D A5 12 LDA $12
$91/C50F C9 40 00 CMP #$0040
$91/C512 D0 07 BNE $07 [$C51B] down
$91/C514 A9 00 FF LDA #$FF00
$91/C517 97 00 STA [$00],y
$91/C519 80 05 BRA $05 [$C520] down
$91/C51B A9 00 FF LDA #$FF00
$91/C51E 97 00 STA [$00],y
$91/C520 88 DEY
$91/C521 88 DEY
$91/C522 B7 00 LDA [$00],y
$91/C524 C9 FF 00 CMP #$00FF
$91/C527 F0 09 BEQ $09 [$C532] down
$91/C529 A9 FF 00 LDA #$00FF
$91/C52C 97 00 STA [$00],y
$91/C52E 88 DEY
$91/C52F 88 DEY
$91/C530 10 F0 BPL $F0 [$C522] up
$91/C532 A5 18 LDA $18
$91/C534 0A ASL A
$91/C535 A8 TAY
$91/C536 B7 00 LDA [$00],y
$91/C538 C9 FF 00 CMP #$00FF
$91/C53B F0 0C BEQ $0C [$C549] down
$91/C53D A9 FF 00 LDA #$00FF
$91/C540 97 00 STA [$00],y
$91/C542 C8 INY
$91/C543 C8 INY
$91/C544 C0 CC 01 CPY #$01CC
$91/C547 30 ED BMI $ED [$C536] up
$91/C549 28 PLP
$91/C54A 60 RTS
At this point, $0 = 7e9800 = base and $18 = samusY-screenY-10 = yoff, so this should be equivalent to the pseudo-code
Assuming no 00ff values are encountered, this will overwrite [base+(yoff-1)<<1:base] backwards and [base+yoff<<1:base+1cc] forwards. We cannot affect anything below base, I.e. below 7e9800. But there are some interesting things above there, such as the event bit array, which is what total used. We are very limited as to which values will be written. It's either 00ff or ff00, but that is enough to set any event bit we want. On the other hand, this leaves very little potential for arbitrary code execution: It's hard to do anything useful with only ff00 or 00ff.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Are we talking about a non ACE RBO here? Otherwise, there aren't any restrictions on being able to shoot the beam in the mother brain battle. You just shoot the charged space-time beam somewhere (probably right after you get the plasma beam), use that to get full control and make the game call your code every frame. From that point on you can make anything happen whenever you want. So you can escape from the mother brain battle at any moment, no shooting required.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Warp: Unless one excludes the undead pause trick from the category. The in-game tases are in the moon tier, meaning that people found them to be entertaining. A tas that used the pause trick would probably not be found to be entertaining, and so couldn't obsolete them. The cleanest and simplest solution is therefore to just disallow the pause trick in in-game category TASes. Why would you want to remove entertaining runs?
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
While this TAS executes arbitrary code, it does not make sense to put it in an "executes arbitrary code" category, as the goal of this TAS isn't to showcase arbitrary code execution - that is just used as a tool to reach the ending as fast as possible. EAC tases are essentially playarounds, and are judged for the quality of their payload, not their speed, and this run aims for speed. It's the same as for Super Mario World, where the any% run also uses an arbitrary code execution glitch.
Total control-type tases can be very entertaining, and I hope somebody makes one for super metroid too. One could have Samus turning into a space pirate and fight princess peach - imagination (and workload) is the limit. But the possibility of doing all that doesn't mean that it isn't interesting to see how fast the game can be completed.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Wow, that's a long and well-argued post, ais523!
I agree with some of what you say: It would be more satisfying not to have the GT code as a prerequisite, and I think a non-GT version of this TAS would be very interesting to see. I definitely think such a TAS should be made.
But I also think the current version has merit:
This is the no holds barred, fastest known way to reach Super Metroid's end state. That is, if we had an imagninary infinitely fast computer and used that to brute force the shortest input sequence that reaches the ending, then as far as we know, it would end up with this strategy. All the other categories are formed by adding restrictions to this one.
We have had a lot of discussion about which controller inputs constitute cheating, and which do not. I think this is putting things in the wrong terms. There isn't any absolute cheating or not cheating. What matters is whether you achieve the category's goals or not. Just like using a bicycle would be cheating in a footrace, it is fully allowed in a bicycle race. Similarly, using, say, the Konami code would be no problem as long as the category allows it. So the debate should instead be over the questions
Does the any% category allow any and all tricks?
Does it allow the GT code in particular?
If not, is this TAS entertaining enough to be published in a category that does allow it?
I think that having certain implicit restrictions in the any% category makes sense, but lately the majority opinion seems to have shifted to "any% should be the absolutely, objectively fastest possible completion". But in any case, the response to this movie is positive enough that it's hard to see how it could not qualify for a moon, and hence be published in a category that does allow the GT code.
GT code is a category in unassisted speedruns, and these can now beat the current X-ray TAS route. I think most viewers who saw that would wonder how fast such a speedrun could be done with tools, and this video answers that question.
On a side note, I do not agree that this TAS is too similar to existing ones - in fact, I think this is the one that stands out as most different from the others. Due to showcasing one new and two rarely seen glitches while going woefully unprepared to the most hostile environment in the game. But this is simply due to giving different weights to different things, I guess. Though as I said, I'd really like to see a no-GT charged spacetime be published too. But that would be in a slower category than the current TAS.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Wow, it's like we have a flood of arbitrary code execution TASes lately! It's nice to see so much effort going into understanding the inner workings of these games. I'm unfamiliar with gameboy machine code, but it looks like having 0 mean NOP is a huge benefit. On the NES and SNES, it means BRK (hang), which means that any 0 is a potential showstopper.
The setup took some time, but it was worth it. I voted yes. Thank you for providing all the details in the submission message.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
ALKATORN: This is a debug code, not a cheat code. It is like discovering a debug room filled with powerups that you weren't supposed to be able to access, but which had been left open by mistake.
It's also not a obvious that the GT code would always be faster. For example, collecting the morphing ball is faster without the GT code. In fact, most items can be collected faster without executing the GT code. You're making it sound like the GT code is some sort of action replay that you can use to get anything you want. It actually only gives you items you were supposed to have by that point. The fact that you can get there without items like varia, gravity suit or grapple beam was probably not anticipated by the developers in the first place.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I did my investigation using snes9x, but a recent version of lsnes would have worked just as well. I started by making short movie files of me firing the various glitched beams. I then played them back, and started trace logging just before releasing the beam. You can see some example of such traces here. I then go through those, and search for some reference point - for example and address from the RAM map that I know will be involved, or in this case, part of the workings of the space-time beam had already been posted by others in the super metroid thread, so I knew which part of the code that glitched beam jumped to.
I then worked my way backwards, looking for which variables make the game jump there, how they get their values, and so on, until I understand the logic the game uses to determine where to jump. This is also where it helps to shoot the different beams, as the non-glitched parts will be similar, while the glitched parts will be very different. You can see some comments I made for myself during my work in some of those trace logs.
Normally, one would try to figure out how to make the game jump to RAM once one understand how the glitched stuff works, but in this case the game jumped to RAM by itself with no extra work needed for 5 of the beams, so that saved a lot of work and made things much more feasible. So I just looked at where in RAM those 5 cases jumped, and consulted the RAM map to see how manipulatable the variables at those locations were.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Yes. In particular in order to get the plasma beam quickly. The GT code actually gives us too many power bombs, which is why we have to waste so many of them.
The border between a cheat code and a debug code is fuzzy. Conceptually, the former is meant to be used by players as a crutch, while the latter is not meant to be available to the players, only to developers.
While I would prefer if the GT code wasn't necessary, I don't think it is a bigger problem than the use of non-standard 16 button controllers.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I don't think there is any fear of the Vault getting out of hand, because making a TAS is a lot of work, and we obviously wouldn't accept sloppy runs. It's not like we have a population of millions of TASers standing by to flood us with optimized submissions. Or rather, if there were, it's a shape that they're not currently a part of TASVideos. No, regardless of what the initial intention of the Vault was, I think it would be improved by expanding it from "any% or 100%" to "anything with a clear obsoletion criterion".
Anyway, sorry for going off on an off-topic rant - how the vault should work is not what this thread was about.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
I don't agree that we have too many categories for Super Metroid, or any other game. If a TAS is good, then the number of existing TASes shouldn't matter - it should be judged on its own merits. And if a category is fun, the number of categories shouldn't matter - it should also be judged on its own merits.
If you reject a category based on the number of other categories, or remove another category to make room for it, then you are just introducing unnecessary dilemmas. You can have the cate and eat it too in this situation.
In my personal opinion, there are far too few categories for all games on this site. The entertaining Super Mario 64 "random task" tases all have well-defined, if arbitrary goals, and the competition they spark leads to a lively TASing environment that sadly does not have much overlap with this site. They therefore exist primarily as youtube videos, with the associated lack of record keeping and input file preservation.
The Vault was supposed to solve the "problem" of too many categories by hiding TASes that aren't deemed entertaining enough. I think the Vault was a good idea, except for the decision to only allow any% and 100% TASes. It should instead allow any category with a clear obsoletion criterion. That way one could have all sorts of oddball categories, but only those moon-worty would be displayed prominently on the site. Then the discussion in this thread would simply be reduced to whether this TAS is entertaining or not, like the question on the top of the page asks.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
An argument could be made that the GT code was left in the game by accident, making it a programming error, i.e. a glitch. It certainly makes most sense as a helper function for debugging the GT fight than something put there to help the player, unlike the codes DarkKobold mentioned. I thought the main reason why Saturn's TAS was rejected was because people thought it was too similar to other categories. Though I agree that doing this without the GT code would be more satisfying.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
Cpadolf wrote:
Ok, then I'm thinking that it would probably be fastest to use the time it takes to reach that position to use up 3-4 of the PB's so preferably only 1 has to be used each time in GT's room
When playing around OOB a few days ago, I experienced that power bombs would get stuck after exploding OOB. Once a few of them were in that state (5 or so?) I could not lay any new ones. I haven't looked into the cause of this, so I don't know how common it is. But it's something to watch out for.
Experienced Forum User, Published Author, Former player
Joined: 2/19/2007
Posts: 424
Location: UK
total: I agree. I had thought of 0xe00 as the changed buttons, not the newly held ones. Had it been the former, we would have had full freedom there, but as it is, the on-bits of 0xe00 must be a subset of the on-bits in 0xdfe, as you say.
This is a major blow for this strategy. It eliminates JSR addr (20), JSR long (22), JMP addr (4C), JMP long (5C) and BRL (82). There is sill some hope left for the more fickle JSR (addr,x) (FC), JMP (addr) (6C), JMP (addr,x) (7C) and JMP [addr] (DC). These all work by reading a value from the address indicated, and then interpreting that value as the address to which to jump. Since we can freely control the low byte, and have 6 out of 8 controllable bits in the high byte of that address, we can cover 1/4 of the bank 7e memory, for a total of 16384 memory locations. The probability that the word 0x4218, 0x4219, 0x421a, 0x421b, 0x421c, 0x421d or 0x421e can be found there is pretty good.
Edit: I just made a script for searching ram for these numbers, and I didn't find much. In most rooms in red brinstar the perfect values are always in reachable memory, but other than that the hits were mostly in OAM, where we already knew they could occur. The value can also be formed using the scroll values in 0xb4 and neighbors, and in 0x914. But basically all of these are scroll/position-based, which plays very poorly with the position-based prerequisite for doing anything using the uncharged murder beam in the first place. So I'm currently much less enthusiastic about this approach.
We should probably focus on the OAM or 0b00 strategy of the charged space-time beam instead. For the OAM method, the golden pirates a few rooms right of the GT room are the best candidates. They produce third-byte equals 42 quite often, and no OOB is required. However, it might not be easy to get their x position right. But the best method is probably the 0b00 method.
