comparing accuracies between diffrent emulators sounds very arbitrary. What if the most accurate emulator only had 1 inaccuracy that let you beat the game super fast or with 0 a presses? Who should decide (arbitrarly) which emulator is the most accurate?
Also, as far as I know, SoulCal have a controller that plays back N64 games from input file on consoles. And as far as I know, it played back several Super Mario 64 runs on N64 already.
Do you still think that this trick that would crash the N64 should be allowed to reduce the A press counts? Because that's what it sounds like to me...
Arguing that it's possible on Wii's VC would only reduce A presses for Wii's VC runs.
I think using emulators should be considered tools when making TAS inputfiles for runs that can be verified on console. If you use a more accurate emulator you're just using a better tool for your tool assisted run. If you're aware of flaws in the tools you use, then you have to adjust how you use the tools.
From what I understand, that's exactly what he meant.
My bad in that case. I thought he meant that we automatically had to reject all runs that can't be console-verified as in not having any way of testing it for certain consoles. My point was that these runs arn't automatically rejected because of this. Only because of known emulator bugs. This doesn't mean that the run can't be rejected later if/when we have methods of testing the run on consoles.
If someone wants to make Super Mario 64 TASes and use known emulator inaccuracies then I have no problem with that. I just don't think it's fair to claim that these TASes represent the real console. And at the very least can't compare the run to runs that avoids known emulator inaccuracies.
Therefore my opinion is that emulator inaccuracies shouldn't be able to reduce A-press counts for Super Mario 64. If we were to accept emulator only tricks, we might aswell develop/modify an emulator to allow us to beat the game with 0 A-presses.
I'll briefly weigh in with what I've said in the past: the emulator is an intrinsic part of the TAS.
The process of making a TAS input file on emulators is an intrinsic part of making the TAS input file for emulators. Couldn't you in theory have tools that let you make input files for consoles that does not require any emulators?
Bobo the King wrote:
It's not about what can be accomplished on the console, it's about what can be accomplished on the emulator.
If this was the case, then shouldn't TASvideos sort their forum based on emulators->games instead of consoles->games?
Bobo the King wrote:
In addition, the best and most preferred emulator offers the closest emulation of the console
Best and most preferred emulators doesn't automatically imply closest emulation of the console? I can think of situations where the best and most preferred emulators would be able to avoid certain crashes from the original console or just reduce loading time.
Bobo the King wrote:
, so we will inevitably drift toward TASes that are more console-accurate, even if today's TASes aren't.
This isn't guaranteed unless best and most preferred emulators imply better console-accuracy.
Bobo the King wrote:
So I say let emulator-specific glitches stand.
Arn't emulator-specific glitches -> emulation inaccuracies by definition? Wouldn't it be better to strive for runs that could be run on the actual console instead of an arbitrary emulator? The most inaccurate emulator could have the fastest run possible.
Bobo the King wrote:
To do otherwise invites a slippery slope argument towards invalidating any TAS that can't be console-verified.
No? It only invalidating any TAS that either use known emulator only tricks, or any TAS that doesn't play back on console. Certain runs might get invalidated when there are console-verification tools for these games.
Bobo the King wrote:
After all, if a run desyncs on the console, that means the emulator "glitched" in a way that the console didn't.
Exactly? And shouldn't the console be the standard the runs (and accurate emulators) should try to achieve?
I feel this discussion could be had in a better thread.
With all those edits, I never know when there’s new content. How far have you gotten now?
I have to agree with ALAKTORN again. I check the SNES forum mainly for this game at the moment. I clicked this thread to find an old WIP, but saw that your last post had many updates as edits. I'm not sure if you do so because of forum rules or something, but I would find it much more convenient if you just made new posts instead!
Also good job on saving 38 frames! Can't wait for the final result. :)
I think MUGG is talking about the part from 4:50 to 5:00 in your video. It looks like you keep the same curve over a long path. Any kind of straightening should save you from walking a longer distance than necessary.
The red line is shorter than the grey line, it's as simple as that. The only reason to walk in curves is if the game gives you extra speed by doing so.
You're probably already using memory watching tool for TASing this game, but if you arn't then there should be a value for the facing direction. This should be helpful for straightening your lines as much as possible. Especially considering that the camera is moving and you (probably) have to adjust your angle every frame!
Also I really liked the WIP! Keep up the good work :)
Hey guys, does anyone know how to manipulate rupee drops from bushes or drops in general? Do I need to mess around with MHS in order to get the drops I want?
AFAIK, diffrent frames and attack animations change the drops from bushes. I'm not sure about drops in general. I guess MHS would be a good tool if you know all variables involved and know how to manipulate them. I might be wrong, but I think MHS is better for confirming max speed/acceleration and optimizing movement directions in OoT.
Not the best video :) But still a lot of fun to watch:)))
I suggest watching this video if you are interested in TASing and want to continue making your own TASes :) I think it fits your current skill level and you should be able to learn quite a few new techniques :)
I think that any trick allowed by SDA should also be allowed here.
I still hold that only penalizing a reset 1 frame is unreasonable, as real game systems have startup screens, which most emulators simply skip.
If it simply skips it in a run, then it's bad emulation and the run most likely won't be accepted.
in my opinion, that VC can't/can run N64 games is not the best arguement, neither is the texture diffrences. The biggest arguement is that VC actually need to be inside a wii, or a wii emulator. The same goes for the N64 emulator inside the GC. These emulators use other ways of saving the game and got other inputs. Also I'm not sure about the timing rules for a Zelda OoT run on VC, but I would guess it starts when you turn on the wii, not when you start Zelda OoT in the VC emulator. IIRC, you can still have some Wii inputs like going back to the Wii homepage while playing on VC.
Sorry, but I can't see how you can ignore the fact that you actually need the VC to be inside a Wii emulator(or the parts you need to be able to emulate of the Wii emulator).
Also I think it's pretty obvious that Spider-Waffle is just trolling.
Right, which is why I proposed putting inside a Windows emulator labeled a Wii emulator, or having Dolphin call Mupen when it emulates N64 roms. Standard rules for RTS run never use see the Wii screens, ever, they are only concerned with the N64 emulation, which I think TAS community should follow suit.
:P that post about using windows as a wii emulator was the post I figured you must be trolling :) atleast for 1 post :)
I don't think anyone is against the run(or maybe some are against it), but you can't call it a N64/VC/GC run, that would be lieing. You can call it a run that would be close to a VC run, playing on an N64 emulator while abusing an emulator glitch to enable a VC run route. As long as you keep the facts straight and don't lie about how this is possible or how this is a good emulation of VC, then it's all good, but don't hope for a N64 publish on TASVideos.
in my opinion, that VC can't/can run N64 games is not the best arguement, neither is the texture diffrences. The biggest arguement is that VC actually need to be inside a wii, or a wii emulator. The same goes for the N64 emulator inside the GC. These emulators use other ways of saving the game and got other inputs. Also I'm not sure about the timing rules for a Zelda OoT run on VC, but I would guess it starts when you turn on the wii, not when you start Zelda OoT in the VC emulator. IIRC, you can still have some Wii inputs like going back to the Wii homepage while playing on VC.
Sorry, but I can't see how you can ignore the fact that you actually need the VC to be inside a Wii emulator(or the parts you need to be able to emulate of the Wii emulator).
Also I think it's pretty obvious that Spider-Waffle is just trolling.
You can't tell if he modded his controller from that.
What matters does it do if he modded the controller? All you have to do is to remove the left and right button and replace it with something that allows them to be pushed at the same time. if the console doesn't crash from it, it should still be a legit input for the console.
The electrical hardware might allow it, but the physical hardware does not. We are doing something which is physically impossible I can't be done on the real hardware.
VC isn't an official Nintendo release? And why does that matter anyway? If the RTS that use VC are so popular and all the runners use that, why shouldn't TAS be able to as well. We run hacked roms on this site which aren't official Nintendo releases which the community and contributors want to see, why is this different? Why does it have to be run on Dolphin, why can't it use a different VC emulator?
Why is it okay for some things to not be official and impossible and others not? What determines that? Why don't the community and contributors get to decisions catered to help them contribute. We all want to see a VC run, people willing to make it want to a VC run, why don't we do w/e we can to let this happen. Why are we road blocking our on community and contributors, what do we stand to gain by doing that and is it worth it?
It's looking to me like this run is just going to get done on Mupen and stick on B and won't be submitted to TASvideos, it's really not worth it. What TASvideos stands to gain by not hosting the run really isn't much.
The problem isn't doing the run. It's not even a problem abusing this emulator bug in mupen. The problem is tho that it can't beat the current any% run, it would need to be a freerun with a goal that allows it to abuse emulator bugs to achieve a route that is not possible on the console the emulator is emulating.
The point is that it is unfair for future runs, if this emulator ever gets fixed. Also this is not even a semi-decent reason to allow it, because we already know it's not possible on the console. If this was extremely hard to verify on console, and nobody knew if it works or not, then it most likely would be an accepted speedrun(which is not the case here).
Why would you allow a trick for a N64 - Zelda OoT TAS that you know for sure 100% can't be reproduced on a N64 console? it's clearly a bug in the emulator, and should be improved.
Tasing mupen64 "instead" of VC on GC/Wii doesn't make sense for me, sorry. Mupen is not meant to emulate the emulator you play on Wii or GC, it's meant to emulate N64 console. I would enjoy watching both runs, but a run that isn't even possible on N64 shouldn't be published as a world record atlesat. Maybe a free run of OoT using emulator glitches, where the goal is to have a more entertaining route than the RBA route.
See the changed block and shield symbols in OoT. So who is to say this wasn't a deliberate fix?
To be honest, i don't see why it even matters. Regardless of why, it does work on these platforms, which are official releases from nintendo. Poor emulation or not, it's an official release, and if it works on the actual console, it should be allowed in the tas.
Any% means by definition completing the game as fast as possible, by any means necessary.
Problem is that "completing the game" needs a clear definition.
I agree with Wyster. In my opinion, the game should have 2 diffrent categories because one is defeating ganon, while the other glitch let us skip to the credits. but if most people agree that glitching the credits is the same as beating ganon, then I don't mind this glitched run to obsolete the current any% run.
Yeah, considering the current any%, and the time difference here, i don't really see this being a new category.
I could be wrong, but I think people would consider this an own category, since you don't ever defeat the last boss. Just like mario world and pokemon yellow, you don't ever actually beat the final guy. I don't mind this taking the place of the rba any% run if everyone else agrees on this, but I think skipping killing gannon deserves it's own category.
Also good job finding this glitch guys!
You're clearly not following along. I said I glance once in a while at workbench too and published movies... Pff, why did I even bother replying to you.
And that's not really the point. It's about being clear, precise, and organized.
If this topic was posted in a thread more convenient, than this whole fuss wouldn't even exist. Tasvideos would only benefit making it easier for newcomers to navigate through the stuff THEY THEMSELVES are interested in by simply implementing this "complaint" and putting things in order. In other words, by actually having people doing their job properly.
obvious troll is obvious...
I don't see the problem of having 1 thread for a N64 game(hack) in the N64 games part of this forum. people have tons of Super Mario World hack threads under SNES games. Also Brian, I think DarkKobold's posts made much more sense than your posts.
Ok I just had to post this:
-Pikachuman, the title "Ocarina of Time hack Zelda's Birthday" implies to me that this is no "official" rom (or not in the way the Master quest edition is). That said, this topic shouldn't have even been under "N64 games".
Of what I understood, there are people who would like to see a tas of this because of reasons X, etc (you can include me in here too if you would like even though I haven't played this "hack" or seen much (if any) of it); but that does not make a legitimate reason for submitting such a run here.
"But who said anything about submitting here?"
Well, my point exactly, why are you posting this stuff (specifically) here?
Then, look at the fact that people haven't posted in between your last 5 trillion posts. This could be a good indication that maybe they have ceased to show interest because of reasons like emulation issues, rom lags, Y, Z, etc OR they just realized how pointless it is discussing about something like this HERE. So why are you pushing this? Were you waiting for a post like mine to realize it?
I mean, I absolutely love Zelda OoT, so much that just looking at the graphics and some new endings or a bit of a modified story plot would be like a dream come true for the epicness this game has had to my life, but again, not the right place here...
I may not be a TASVideos "employee", but I really felt like doing something about this.
I think people are allowed to discuss games that arn't tas-able yet (e.g. DK for N64). Any usefull information about tasing this game should be posted and discussed here. I have seen other rom hacks been discussed in other threads too. I'm just happy we don't get all these posts in the Zelda OoT thread.
Pulling out mushroom twice might not be slower, just looks less clean... I think I remember someone saying the problem was that you had to wait x number of frames before pulling out the shroom. so, pulling it out once would be considered a playaround time waster while waiting for those frames.
Hey I'm pretty new here, I was lurking these forums for quite a while now. I'm an active member at SDA and like TASer and SDAer :P are going so well together now, I was hoping to give and or receive help. First, I saw a run recently on Youtube that look as fast or faster than the current one here, he use the JAP ver. The only thing in is run that I couldn't under stand is skipping the first cinematic
Here's the link:
http://www.youtube.com/watch?v=AhcbmrF6GWY&feature=related
Since we can't always trust human eyes and I don't know if the Jap version is faster, I was asking if this was actually faster than Bloobiebla's one.
I could be wrong, but I think that run starts timing when you get to controll link, while a tas would also time from power on to the last input. He also just edited the intro out of the run, only showing what he did after leaving link's house.
The japanese version can't be compared to the english version unless you know how much faster/slower the text boxes are etc. What we do know is that the japanese version got much much faster text boxes, so that alone makes for several minutes shorter runs.
Yeah, that's fine. I'm well aware of the rules. If they wanna keep them, it's cool. I don't like them so I just won't submit my run if they aren't changed to what I and many others in this topic consider more sensical.
Edit: Oh, I should also point out that I'm also breaking another "rule" the site has. The version of Mupen I'm using has resets, but it resets the entire emulator and not actually the ROM. I guess it's more equivalent to shutting the system off then turning it back on, than pressing the reset button. I remember people caring a lot about this silly difference a few years ago, and I'm sure some wonderful person would actually vote no based on it (XD).
wouldn't being able to turn on/off emulators be more realistic for a speed run anyways? and not only being restricted to resets?
I also think that the rules could be modified so that these games does not need "exceptions". does it matter what language the texts are in if you can only read them if you pause the emulator/video on the exact frame or else you couldn't even read it?
go for it! not sure if it will be accepted, but I hope so! I think it will be atleast as entertaining as the any% speedrun, maybe even more entertaining!
The red line is shorter than the grey line, it's as simple as that. The only reason to walk in curves is if the game gives you extra speed by doing so.
You're probably already using memory watching tool for TASing this game, but if you arn't then there should be a value for the facing direction. This should be helpful for straightening your lines as much as possible. Especially considering that the camera is moving and you (probably) have to adjust your angle every frame!
Also I really liked the WIP! Keep up the good work :)