1) Why didn't you get a bomb drop while you were at the graveyard? That way you could have superslided out of Kakariko, and not have had to of twice backwalked across Hyrule Field (the most obvious) -you can only pick up bombs, if you got the bomb bag. i receive the bomb bag a lil later with cojiro(rba) 4) The amount of delay before beginning movement after entering an area, and also the horrible angling, leaves me to believe that you could have saved time by just mashing A and rolling everywhere. -if i moved to fast, the movie desyncs... i had to play the hookshot part like 10times, because i immediatly started backwakling gg Bisqwit wrote: What's the deal at around 33 minutes? You go fishing, but instead of catching a fish, you go swimming, and then leave with your rod. What follows after that doesn't make sense at all. You go around in various places releasing the bugs in your bottle, only to catch them again... -these are all parts of the reserve bottle adventure and i need the rod,a lot of recatchings and the "play any item as ocarina" glitch for this time.[/quote]

Voted no. What I liked -Glitch routes always fun to watch. -Zelda telling you your worked your ass of to save six sages when all you did was run around and played with insects. -The 6 or 7 enemies that were actually fought over the course of the run. The rest however... (WHat I didn;t like) -Cutscenes! not really a fault of the author but still lame to sit through. -Travel. I swear that's all the movie is, not only is it irritating to watch since nothing interesting happens but... -Unoptimized. I honestly couldn't see any section of travel that couldn't have been improved. A lot of the angle changes in illogical places (say the middle of a field, instead of at a "corner"), times the angle was wrong (running into/against walls, hell in the first trip to the village you lose around five seconds exiting from being very far off-right of the gate and having to correct yourself), and things that were slow and had no real reason to be? (a few twitchy moments before performing some glitches). -Also, even though I have no idea what the route is, some things you go out of the way to get don't -SEEM- necessary, but I can;t say for sure and that brings me to my final point; -The submission text. In the future if you plan on submitting more movies to the site, please try and explain the movie better. If explaining a complex glitch is still too tedious, at least explain why some out of the way things were gotten, and actions taken which seem pointless, so the audience isn't left wondering. All you did here was write a half page apology for inoptimal-ness and bad english.

lol, bisqwit clearly has no idea how RBA works

Believe it or not, some people know very little about oot! :o

Even those who know "everything" about the game would get very confused by BA/RBA at first, so not getting what's going on is definately nothing to be ashamed of. I for one know next to nothing about how the glitch works, only what it does.

Believe it or not, some people know very little about oot! :o

LIES! D:

On RBA.. I've always thought, it wasn't so difficult to understand, but whenever I try to explain it I seem to fail. Every item slot (C-Slots) has a value (which item is it?) and a 'pointer' into the inventory (so the game knows f.e. which bottle you use. this is needed to update the bottle value in your inventory after using it! you can turn every item into a working bottle using glitches because it's coded like that btw). Those 'pointers' are saved as an offset to the address where your inventory starts. The B slot doesn't have memory reserved for a 'pointer' to the inventory in OoT (as opposed to MM). There's the value of the item on C-Right on that specific offset instead. -> B button value C-Left value C-Down value C-Right value C-Left offset C-Down offset C-Right offset Address where the offset is stored = Address of value + 3 So if you use a bottle on B and catch something or release something, the item value on B changes and the game attempts to update the same change into your inventory. It looks for the offset where it suspects it to be and finds the value of the item on C-Right instead. It adds the value af the item on C-Right to your inventory base pointer. The result might, depending on that value, even point outside your inventory. The game then copies the new value of B to that address. In other words the game just simply executes the update bottle code.. Something completely different: How getting Bottle B works (not fully explained): Normally if you use a bottle the use-bottle code gets triggerred instantly. If you, however, use it while in air the game waits until you touch the ground. The game then executes the use-bottle code and updates the value of the last pressed button (!). So if you press another button before that piece of code gets executed (=before you touch the ground) the new bottle value gets written to another button instead. The game also tries to update your inventory then of course, which instantly triggers the RBA gltich if that button was B. Why this only works with some (weak?) items and leads to Ocarina items glitch with others (strong items?) is beyond me though. One of those weak items is the Deku Stick, the Sword is a strong one. So to get Bottle B you need to get the Deku Stick on B first. Which is why the whole procedure of stealing the rod is required.

All I could think watching was "I wish this had subtitles" when stuff I didn't understand is going on. Like, the Might & Magic run, for instance, has subtitles to explain what the item transforming glitch is doing. I don't mean anything major, maybe just a little "glitching Shadow Medallion" or whatever the heck is going on.

for those waiting for the new mupen64plus before recording a new zelda64 TAS: okaygo is working hard, but won't necessarily be done soon. I'll be helping him out after I finish another task for the project. If I understand correctly, the current fix for the zelda pause bug involves inputting a gameshark cheat that alters the game somehow. A more "legal" fix hasn't been found yet. Our entire team has almost 0 windows experience. Even if we fix the pause bug legit, and frame-advance/re-record is in, only linux TASers might be able to take advantage. Unless, that is, we find a Windows hacker willing to help us out. hint, hint. My point is: -- Don't get your hopes up for a zelda-TASable windows-capable mupen64plus in the near future --we need help

Believe it or not, some people know very little about oot! :o

What's oot?

Believe it or not, some people know very little about oot! :o

What's oot?

Ocarina of Time

If I understand correctly, the current fix for the zelda pause bug involves inputting a gameshark cheat that alters the game somehow. A more "legal" fix hasn't been found yet.

Bisqwit deemed the patch to be legal. However we could use some WINDOWS developers to help us.

Yes vote Voting "no" means you are in favor of keeping the existing run which is 80 minutes slower!

voting no still means you did NOT like watching this movie

Yes vote Voting "no" means you are in favor of keeping the existing run which is 80 minutes slower!

I guess I am then.

I voted "Meh"... This run is very entertaining and fast... The only problem is... I don't geht half of it xD Like... After he brought the Saw to that guy... And teleportated back to Cathedral (with the bottle full of bugs oO wtf xD) He triggered the Scene after getting the final Medaillon... Things like that really makes me: "Holy Shit, wtf happened!?" Hmm... I really would like to see a 100% run ^_^ THIS would be entertaining and really fun to watch if 100% Optimized ;)

About the run, I thought that since Mupen64 will not be finished for a while, the current run should be obsoleted, so that people can get a little familiar with the current route that TASers will be using and what RBA is. THEN AGAIN, this movie is kind of bad, and there is a much better demonstration movie posted on youtube which was made by groobo. Therefore I voted No Also For anyone looking for information on RBA, this is the archive of information on it that most speedrunners (at least over at SDA) swear by http://cosmo.dreamhosters.com/RBA.html

if someone makes a tas that beats groobo's run i think that would push it to 80% yes even if it doesnt beat the theoretical optimal tas (and i would vote yes instead of no) then that would allow a judge to dart in, accept, and then dart back out since in the hazy area of 70%-90% the judge gains despotic powers and it seems the judges are all treating this like the "hot potato" from when we were kids with none of them really wanting to be the one who has to uphold either side and deal with the blowback also i think if in a few months we see another sizeable improvement and continue to hear how we should hold off for the theoretical optimal run we will probably ignore the pleas that time around finally, if that improvement was made by an "experienced person" that would also probably boost credibility also sprach zarathustra

Really, if it's so important that an obsolete run does not stay up just remove it from the site, putting a placeholder up is silly.

Really, if it's so important that an obsolete run does not stay up just remove it from the site, putting a placeholder up is silly.

You make a good point. TASvideos is not a placeholder, so I agree that a placeholder run should not be published. But I will accept whatever the judge's decision ;D

THEN AGAIN, this movie is kind of bad, and there is a much better demonstration movie posted on youtube which was made by groobo.

I think this fact alone should mean an automatic rejection, because there's a rule stating exactly that: "A speed-oriented movie must beat all existing records." Note that it says "must", not "should".

I watched it on youtube (something all N64 submissions should have in my opinion), but I'm afraid I fall into the too sloppy camp, so I gotta say no. Keep trying though!

I understand killing time waiting for the Cuckoo to hatch, but what was with the constant dropping and picking up the bugs? Or was it to use the Ocarina without having it?

om, nom, nom... blech, stale!