Hello,
this is my first tas i submit to TASvideos.
I love the Zelda games and thought this game needs a TAS after all these new discoveries. My goal was a near perfect run but Oot ruined it. I had over 20desyncs while doing it and it was pain to redo half of the game. It's a known problem of oot and heres my solution: just wait some frames after entering a new area or closing the inventory. If u move to early, it desyncs. I think the movie is ok for my first tas and the whole desync problems with it. The worst part of the game is the forest escape: i know the one nut hover trick and i performed it once (it took ages), then i was shocked that the file descyncs and the jump wasnt saved :(. I wasn't feeling like redoing it so i took the easy way (sry for my lazyness). There is a big problem with all the savewarps in the demonstration run. Mupen cannot softreset so i needed to do it in one file. after i received the master sword i jumped through the hall of time wall so i can save after my death,restart and escape the hall of time room.
I hope it will be accepted but if not its ok, I was just to lazy.
JNX
adelikat: Fixed ROM and Game name (and fixed up the text/formatting a bit).
adelikat: According to the Guidelines: If you are aiming for speed and you fail to beat existing speed records, your movie will be rejected.
It has been established that Groobo's movie does complete the game faster even after factoring timing differences and save warping. Therefore, I am rejecting this submission.
Groobo did a test run and got 1:02:17, with TAS conversion that would be about 1:09. He openly admitted that it sucked and only tried to replicate what a speedrun on SDA might look like, thus removes some TAS strats.
Even if this run was rejected, if somebody else posted a run that was say, 5 seconds slower but looked cleaner, we could simply point out this run and say "YOU CAN DO FASTER" and reject the run as well.
As that speedrun demonstrates, faster alone is not enough to warrant publishing. With the right shortcuts a perfectly optimized (but lacking that shortcut) TAS could be beaten by a sloppy realtime run.
If people object so much to the current TAS being obsolete then delete it, don't replace it with something that would have had no chance at getting published if there hadn't been a previous run.
he used a lot of savewarps in the demonstration run thats why his time is better. if u restart the mupen after saving, ur old movie file stops recording and u need to start a new one. i tried it but got heavy desyncs problems so i did it in one file which means i need to run back instead of warp and save time.
K, done watching it now. Voted meh, as it really has some very sloppy parts in it, but it's quite ok other than that. And I vote for cutscene- and dialogueless versions, oh how i hate OoT for them being unskipable!
But it's interesting for me to see the new route for the first time. I didn't know you could equip the light arrows like that..
Isn't there a faster trial skip which requires two bombs? And this run finishes with two unused ones? Hm..
Would be cool if there was a way to skip the scarecrows somehow. Seems like megaflipping isn't possible as an adult, too bad.. What about abusing some tektites, crows and ISG? Has this been tried?
So me and AKA are in agreement that even with SDA timing and savewarps, this run is slower than groobo's run?
Now if groobo used savewarps, he must have used okaygo's re-recording mupen, or recorded in real time each segment (starting from a save-state) on pj64... If he did the latter, that just shows how unoptimized this run is.
Joined: 6/13/2006
Posts: 3300
Location: Massachussetts, USA
If I remember correctly, he did use the record reset mupen, and edited out cutscenes/pausebug, because I don't think PJ64 has its own AVI recording, but needs FRAPS.
lul, a "route demonstration" is faster than this TAS?
Though I wonder if a TAS of this game will be much faster than an ordinary console run since TAS has disadvantages like the pause delay and reset-is-not-allowed-yet. A TAS should probably go below 1h though.
most of this run is cutscenes. it would probably be around 10 minutes long without them ehehehhehehehheheh.
<Baxter> DK64_MASTER that run you linked in the topic used save warps... you can't really compare it
FYI, he used save-warps where it was slower because he wanted to provide a save point for a segmented speedrun for sda.
So yes, while I can't compare the two, because of the route, I can say with absolute certainty that groobo's run is faster.
Let me express two points about this whole dilemma:
1: Assume that currently there was no LoZ:OoT movie published. Would this submission be acceptable, knowing the suboptimalities it has (acknowledged by the author himself)? I guess the answer is no: The suboptimalities don't conform to the current basic standards of the site.
So my question is: If this is the case, why would the fact that there exists a past publication affect this decision in any way? Should a suboptimal run be replaced with another suboptimal run, which doesn't still meet the minimum quality standards of TASing? Should past history of TASing of a game affect its future history?
2: Think about these two hypothetical cases:
a) Someone submits a frame-precise movie, where every single frame has been optimized. However, someone else points out that there exists a glitch which would save time. The author of the movie didn't know about this glitch at the time he made the movie.
b) Someone submits a movie which has glaring suboptimalities in it, and he readily admits that he didn't bother to perfect the run, and knowingly skipped abusing some time-saving glitches, not because he didn't know about them, but because of laziness.
Now, ponder about these questions:
1) Which one of those cases is more "forgivable"?
2) In the first case, would the movie still be published?
If your answer to the second question was "no" (as I believe would be the case), then why should the b) case be published? Is the b) case somehow more worthy to be published?
Not entirely sure, but the menu also seemed to cost less time in groobo's run. Either way, I very much disagree with your absolute certainty. Save waring saved a lot. I'd say this submission has a slightly higher quality (probably because of groobo's goal to make it look like it could be played normally).
Either way, of as stated before, this run could be optimized... this is however not what really bothered me. Things that did bother me a lot were for instance the method of dying after getting the Master Sword. It would have been so much quicker if damage had been gotten in some other place, and Link only needed to drop down once. This has nothing to do with problems with the emulator... just mere planning. There was also a place during the cucco collection where it seemed Link walked to far, and had to walk back for a cucco... Either I missed the reason why this was done, or it was a terrible mistake.
Don't know if I'm gonna vote on this submission, since I wouldn't know what to vote at this point, but the optimization wasn't really the issue for me, and I disagree with DK64's example of the other run.
my plans were to create a new movie file after i recieved the master sword and savewarped to escape, but it desyncs with 2mupenfiles so i decided to die there. i couldnt pick up the chicken so i needed to screw it first by touching it so i can pick it up at the end.
Well, why not publish this run as a concept demo? It show the concept of the new run/route, but is not publish worthy (due to "laziness" or whatever else you guys want to call it) to replace the older, but longer, OoT run.
Everybody wins! o/*\o
adelikat wrote:
I very much agree with this post.
Bobmario511 wrote:
Forget party hats, Christmas tree hats all the way man.
While publishing as a concept demo is a good idea, one small problem is that the site does not (as far as I can tell) very clearly distinguish between concept demos and "normal" publications, and the concept demo may well pass for a regular publication. In that sense it doesn't really solve the dilemma itself.
While publishing as a concept demo is a good idea, one small problem is that the site does not (as far as I can tell) very clearly distinguish between concept demos and "normal" publications, and the concept demo may well pass for a regular publication. In that sense it doesn't really solve the dilemma itself.
To be the devil's advocate (sorry ^_^) couldn't we put in the actual publication "THIS IS THE CONCEPT OF THE NEW ROUTE, NOT AN ACTUAL RUN" Well, I just fucked myself there, because it IS an actual run, but at the same time, it is not. Never mind. Warp 1, Sticky 0
adelikat wrote:
I very much agree with this post.
Bobmario511 wrote:
Forget party hats, Christmas tree hats all the way man.
Here's my attempt to solve the problem the easy way: http://tasvideos.org/576M.html?rev=8
Feel free to revert if you think it doesn't get the point across.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
No need to mention that in the description as it applies to a lot of games none more so than *cough*Super*Metroid*. It could perhaps be made more clear in the guidelines
Baxter, I'm quite certain the only time groobo save-warped was because he wanted to end a sgement, to properly predict what a segmented speedrun should do. This HINDERANCE would make save-warping slower in almost all cases.
He has 10 segments, right? So I highly doubt this 1 instance of save warping being faster and the lack of a pause freeze can make up 9 times being slower + 7 minutes (1:02 sda timing => ~1:05 tas timing) in order for groobo's run to be slower than this run.
Isn't the pause freeze still in okaygo's mupen? I haven't watched groobo's run to notice it yet.
alden wrote:
DK64_MASTER wrote:
So yes, while I can't compare the two, because of the route, I can say with absolute certainty that groobo's run is faster.
I'm not entirely clear on why groobo's is faster -- is it a better route? More optimized? Recording difference? Sorry if I'm being slow.
I'm not sure, I haven't watched either run*. I'd say that since it was a route-planning run for a single segment speedrun, the route is probably a lot stronger. He also tried not to incorporate (TAS-only) tricks. So either he's modest, and his run is actually pretty nice, or this current run is a poor example of what an OOT TAS should be, or I'm completely wrong.
*Am I allowed to make a judgement on a movie based on just time (without watching it)? Sure I am, whether it is ethical is a source of debate. BTW, I haven't voted yet.
EDIT: groobo pmed me on sda forums and said this.
"Hey, I've timed both runs (gaining control till getting the master sword) just for the sake of it. Funny thing actually since, even if you'd add the removed pause delay and the time that the savewarps saved, my run ends up being a couple of seconds faster. Remember that mine was done in real time using like two maybe three savestates per segment without any luck manipulation whatsoever. In other words the tas is crap. Unfortunately I don't have any movie files other than avis since I threw everything in the bin after capturing it."
Let me express two points about this whole dilemma:
1: Assume that currently there was no LoZ:OoT movie published. Would this submission be acceptable, knowing the suboptimalities it has (acknowledged by the author himself)? I guess the answer is no: The suboptimalities don't conform to the current basic standards of the site.
So my question is: If this is the case, why would the fact that there exists a past publication affect this decision in any way? Should a suboptimal run be replaced with another suboptimal run, which doesn't still meet the minimum quality standards of TASing? Should past history of TASing of a game affect its future history?
2: Think about these two hypothetical cases:
a) Someone submits a frame-precise movie, where every single frame has been optimized. However, someone else points out that there exists a glitch which would save time. The author of the movie didn't know about this glitch at the time he made the movie.
b) Someone submits a movie which has glaring suboptimalities in it, and he readily admits that he didn't bother to perfect the run, and knowingly skipped abusing some time-saving glitches, not because he didn't know about them, but because of laziness.
Now, ponder about these questions:
1) Which one of those cases is more "forgivable"?
2) In the first case, would the movie still be published?
If your answer to the second question was "no" (as I believe would be the case), then why should the b) case be published? Is the b) case somehow more worthy to be published?
Personally I think if a movie is considerably faster than a published version and that it is well played it should be accepted. I have been on this site since the start of Arc's site and I can't detect when certain movements waste a few frame, and I doubt most viewers can either.
I also feel that if you vote no on this movie, you should vote no on the optimized run if it ever gets released because there will undoubtly be small timer savers here and there discovered later (see super metroid or mario games). There will never be an absolutely perfect run of this game I feel, so there's no point in voting no if this run is better than the current one, UNLESS you weren't entertained because you don't like the game or don't like sequence breaking.
We know this run isn't perfect, but it is still better than the published version.
Joined: 11/11/2006
Posts: 1235
Location: United Kingdom
NO.
My reasoning is almost identical to moozooh's. The logic is simple; let one suboptimal run through, more will follow. "Oh, this isn't THAT optimal, so I might as well make another run thats not as optimal for this game/<other>"
I understand and accept the need for a new run. I only hope the creators of the new run (Swordless? AKA? Someone else?) can accept this and do us all a favour by keeping it as a primary project and trying not to sway too much by looking at other projects :)
<adelikat> I am annoyed at my irc statements ending up in forums & sigs
I'll just clear up the situation regarding the optimised any% run now...
Me and AKA were working on it, but we put it on hold because we decided to wait for mupen64plus, which has the pause delay fixed. It isn't ready yet, so now, we're considering just moving on with the pause delay. If we moved on now, we could probably (hopefully) have the run finished by the end of summer at the latest.