I love this new route, MrGrunz! I would rather see a run using this route than a traditional RBA run, as long as it's not too much slower than the traditional route.
IMO the TAS should be on Dolphin (VC version). No idea how well it runs though.
^^, Also there's a new trick which uses stick on B, you equip sword the same time you swing bottle to get bugs I believe. Using this with Lon Lon route is how the new RTS WRs are archived now, it might even be faster than tektite. ZFG just got 49:02 with over a minute of mistakes, not mention other possible improvements like nuts from trees.
"Great spirits have always found violent opposition from mediocrities. The latter cannot understand it when a man does not thoughtlessly submit to hereditary prejudices but honestly and courageously uses his intelligence."
IMO the TAS should be on Dolphin (VC version). No idea how well it runs though.
^^, Also there's a new trick which uses stick on B, you equip sword the same time you swing bottle to get bugs I believe. Using this with Lon Lon route is how the new RTS WRs are archived now, it might even be faster than tektite. ZFG just got 49:02 with over a minute of mistakes, not mention other possible improvements like nuts from trees.
LLR is out of question. It is clearly slower for a TAS, because we have to wait for the Pocket Cucco to hatch. During this time we have to spend as much time in areas with progressing ingame-time and this is optimally archieved by going to the fishing pond. We are back at Kakariko right after the chicken hatches ;)
Btw, that trick ZFG uses is done get Stick on B later on by dying. If you die without ever having Master Sword equipped you will be swordless after dying with bottle on B. By doing what ZFG does you get stick on B back.
As you might have realized already, Spider-Waffle, if it is not totally necessary we want to avoid using Stick on B. For the RBA route it is easily possible to avoid this by stealing the rod a second time while going to Gerudo Valley (we are in Lake Hylia any way).
This costs around 20-30 seconds, though, but I dropping those is more than alright.
EDIT:
Just something else. You guys don't want stick B to be used, because a N64 TAS should be done in the boundaries of the N64 console.
Mupen is way too bad to archive the goal "emulate a N64 console perfectly". Just an example:
A few of the new Medaillon and Stone Cutscene Skips freeze on Mupen, whereas they seem to be very well possible on the original N64 console. That's why Mupen is in no way a perfect emulation of the N64.
That's why we definitely need a better Mupen. Especially a Mupen with both fixed Pause Delay and reset ability would be nice. I guess this will never happen, though.
Just wondering, what ever happened to the famous Mupen Plus project?
Isn't everyone using Mupen64Plus (or some variation of it)? It's still in development. It's true though that all N64 emulators (including Nintendo's) are terrible and inaccurate, and I doubt any existing N64 TAS would actually play back on real hardware.
Slowking wrote:
Derakon wrote:
Sounds to me like the GC/Wii version uses an inaccurate imitation of the real behavior.
Or they deliberatly fixed a bug the N64 has with OoT, where the game sometimes reads memory that is out of the N64s range.
That's kinda like blaming a person for getting in the way of a bullet. The N64 didn't have a bug. OoT did, and the N64 reacted as it was designed (throwing an exception on out-of-bounds access). The emulator is in the wrong, ignoring that and allowing it to keep running.
After all, why give the emulator more range than the N64 had, unless you want to prevent these kinds of crashes? Who knows what Nintendo was thinking. ;)
Because it takes extra CPU time to check for invalid memory accesses, and they decided not to bother doing so, since the game shouldn't be doing it anyway. Emulators often sacrifice accuracy for speed.
I should note though, IIRC the game only crashes if you attempt to use the Deku Stick as an adult. I had the stick on B many times on the N64, and it worked fine as long as I didn't press B. From what I've seen none of the routes require actually using the stick, so the game wouldn't crash anyway.
It'd also be worth investigating to see if the crash can be prevented, by using a different version or figuring out what causes it.
Isn't everyone using Mupen64Plus (or some variation of it)? It's still in development. It's true though that all N64 emulators (including Nintendo's) are terrible and inaccurate, and I doubt any existing N64 TAS would actually play back on real hardware.
Joined: 7/12/2009
Posts: 181
Location: São Paulo, Brazil
What if you TAS the rom included in either the GC or VC releases? When playing that ROM in the original console it doesn't have the B Stick bug... :P
The only thing I can comment on the route is: where do you get the fish to use the Bottle Switch Trick?
I'm more impressed about the implications of this trick for the 3DS version than here. The 3DS has two exclusive tricks that allows you to warp to the credits before ever becoming adult. That's just plain awesome.
That's kinda like blaming a person for getting in the way of a bullet. The N64 didn't have a bug. OoT did, and the N64 reacted as it was designed (throwing an exception on out-of-bounds access). The emulator is in the wrong, ignoring that and allowing it to keep running.
No it didn't. It just crashed. That is a whole lot different than throwing an exception or ignoring a command.
Furthermore Nintendo doesn't patch the roms when they want to change/fix something. Rather they change the emulator to apply patches on the fly. See the changed block and shield symbols in OoT. So who is to say this wasn't a deliberate fix?
I should note though, IIRC the game only crashes if you attempt to use the Deku Stick as an adult. I had the stick on B many times on the N64, and it worked fine as long as I didn't press B. From what I've seen none of the routes require actually using the stick, so the game wouldn't crash anyway.
Actually all of the new routes would profit from actually using a stick on B. That's what this whole thing is about.
It'd also be worth investigating to see if the crash can be prevented, by using a different version or figuring out what causes it.
You didn't read very carefully, did you? It can be prevented by using a different graphics plugin than Jabo.
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.
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.
Nothing that is impossible on the N64 is allowed in an N64 TAS.
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.
That's kinda like blaming a person for getting in the way of a bullet. The N64 didn't have a bug. OoT did, and the N64 reacted as it was designed (throwing an exception on out-of-bounds access). The emulator is in the wrong, ignoring that and allowing it to keep running.
No it didn't. It just crashed. That is a whole lot different than throwing an exception or ignoring a command.
Er, no? Throwing an exception (and failing to catch it gracefully) is exactly what a crash is.
It'd also be worth investigating to see if the crash can be prevented, by using a different version or figuring out what causes it.
You didn't read very carefully, did you? It can be prevented by using a different graphics plugin than Jabo.
Of course I meant by in-game actions, not by introducing further emulation inaccuracies. Hey, why don't we use a different CPU plugin that interprets every opcode as "jump to the end of the game"? We'll just say we're fixing a bug in the original N64 hardware that caused the game to run normally instead of beating itself.
You didn't read very carefully, did you? It can be prevented by using a different graphics plugin than Jabo.
Of course I meant by in-game actions, not by introducing further emulation inaccuracies. Hey, why don't we use a different CPU plugin that interprets every opcode as "jump to the end of the game"? We'll just say we're fixing a bug in the original N64 hardware that caused the game to run normally instead of beating itself.[/quote]
Because there is no official version that allows this. However there are 3 official versions that allow for stick on B (GC, Wii, 3DS). Considering how many bugs they fixed on 3DS shhouldn't this have been fixed if it was a bug?
I think they deliberatly allow access to more memory to prevent crashes. Probably not this particular one, but others like it. YMMW here, but the fact remains that there are 3 versions out there where this trick works, vs. 1 where it doesn't.
Because there is no official version that allows this. However there are 3 official versions that allow for stick on B (GC, Wii, 3DS). Considering how many bugs they fixed on 3DS shhouldn't this have been fixed if it was a bug?
I think they deliberatly allow access to more memory to prevent crashes. Probably not this particular one, but others like it. YMMW here, but the fact remains that there are 3 versions out there where this trick works, vs. 1 where it doesn't.
I don't see why it matters how it works in other versions. Those other versions can be TASed. Reprogramming an emulator you're familiar with to allow you to take advantage of an emulation glitch just because you don't feel like playing on an emulator you are not used to just seems a bit silly to me. If you need to use a glitch that works in one version but not another, you need to use the one it works in, or don't use the glitch.
Considering how many bugs they fixed on 3DS shhouldn't this have been fixed if it was a bug?
I don't think crashing was ever the intended result of trying to use B stick.
I don't see why it matters how it works in other versions. Those other versions can be TASed. Reprogramming an emulator you're familiar with to allow you to take advantage of an emulation glitch just because you don't feel like playing on an emulator you are not used to just seems a bit silly to me. If you need to use a glitch that works in one version but not another, you need to use the one it works in, or don't use the glitch.
What seems really silly to me is having to use an emulator in an emulator, where only people with high end computers will be able to play it back at full speed, to get the exact same result, you can get with a different graphics plugin (already availible) on mupen.
And it does work in mupen. That's the whole point. Nobody is talking about reprogramming mupen to allow stick on B.
What seems really silly to me is having to use an emulator in an emulator, where only people with high end computers will be able to play it back at full speed, to get the exact same result, you can get with a different graphics plugin (already availible) on mupen.
And it does work in mupen. That's the whole point. Nobody is talking about reprogramming mupen to allow stick on B.
We get it. You don't like this rule. Get over it. Repeating yourself 50 more times isn't going to change it.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
Nobody is talking about reprogramming mupen to allow stick on B.
Yes they are. The pause bug is only fixed in the plugin which does not allow you to use B stick. That would need to be fixed.
As far as running an emulator in an emulator, the VC version of oot runs even faster than most wii/gc games do. Yes, it still requires a top of the line pc to run at full speed, but most should be able to run it at at least half speed, and if that's not good enough, they can always watch an encode.
Considering how many bugs they fixed on 3DS shhouldn't this have been fixed if it was a bug?
Well they never wanted stick on B to be allowed in the first place. The only reason it is still there is because they were lazy in how they fixed the bugs. Instead of addressing the problem with why you could get stick B in the first place (rewriting pointers or something similar), they fixed stealing the rod from the pond. Therefore while they thought the glitch was perfectly fixed, once a new way to steal from the pond was found, all the old rba was back.
What seems really silly to me is having to use an emulator in an emulator, where only people with high end computers will be able to play it back at full speed, to get the exact same result, you can get with a different graphics plugin (already availible) on mupen.
And it does work in mupen. That's the whole point. Nobody is talking about reprogramming mupen to allow stick on B.
We get it. You don't like this rule. Get over it. Repeating yourself 50 more times isn't going to change it.
The discussion at the moment really has nothing to do with tasvideos moronic rules. Yes this site does have stupid rules left and right, but what interest me right now is how something can be considered not legit when it works on most iterations of the game on real consoles. And how it is a better idea to use an emulator in another emulator instead of just straight up using an emulator.
rog wrote:
Slowking wrote:
Nobody is talking about reprogramming mupen to allow stick on B.
Yes they are. The pause bug is only fixed in the plugin which does not allow you to use B stick. That would need to be fixed.
The pause bug is actually an emulator bug. There even is a version of mupen that fixes it. The problem is that version doesn't have reset.
The option in Jabo 1.6 just happens to reduce the pause lag so much that it's basically nonexistant. It's a lucky coincidence. But the option also reduces framerate considerably (it's about an 8th of the speed you would otherwise get), so it also slows TAS progress, because playbacks from the beginning are a pain.
We would just like a proper fix in mupen, not this sloppy workaround.
Jabo 1.6 is not the best graphics plugin for OoT and you can not use texture packs with it. So something like the cel-shading encode of the current any% TAS is impossible. So there are reasons apart from Deku Stick B to want a mupen that sucks slightly less than the current one.
rog wrote:
As far as running an emulator in an emulator, the VC version of oot runs even faster than most wii/gc games do. Yes, it still requires a top of the line pc to run at full speed, but most should be able to run it at at least half speed, and if that's not good enough, they can always watch an encode.
You should consider that somebody also has to TAS it. That means playback, after playback, after playback. Not every TASer here has a high end computer.
Btw. just noticed that Jabo 1.6 actually can emulate deku stick on B. Problem is different than other graphic plugins it won't just continue running when it encounters inconsistencies. It will throw an error box and pause emulation.
But between error boxes you can get input in (use stick, break stick) and if you put the stick away the game continues to run normally. Ofcourse that doesn't help with the TAS, but I thought it was interesting.
Awesome run, Swordless.
One question. What was the reason for using that last bombchu in Ganon's Castle the way you did? Could it have been used during the Ganon fight to arrive at the Master Sword more quickly? I assume you thought of that, but I just wondered.
Yes this site does have stupid rules left and right, but what interest me right now is how something can be considered not legit when it works on most iterations of the game on real consoles. And how it is a better idea to use an emulator in another emulator instead of just straight up using an emulator.
I can't help but feel like you're missing a rather obvious point here. If it doesn't work in the N64 version of the game on console then you shouldn't use it in a TAS of the N64 version of the game. It's not rocket science. If you think that's a dumb rule, then you're obviously unaware of what the site is for and should probably read up on it.
This isn't relevant to this run though, but emulation inaccuracies like that lead to rejected runs, a.la SML2.
Yes this site does have stupid rules left and right, but what interest me right now is how something can be considered not legit when it works on most iterations of the game on real consoles. And how it is a better idea to use an emulator in another emulator instead of just straight up using an emulator.
I can't help but feel like you're missing a rather obvious point here. If it doesn't work in the N64 version of the game on console then you shouldn't use it in a TAS of the N64 version of the game. It's not rocket science. If you think that's a dumb rule, then you're obviously unaware of what the site is for and should probably read up on it.
This isn't relevant to this run though, but emulation inaccuracies like that lead to rejected runs, a.la SML2.
It is an emulator inaccuracy which causes the glitch not to work; not the other way round. We had the same issue a few years back relating to the dokashira glitch in Pokemon Green.
