https://puu.sh/y7npZ/2a8d2f6faa.png
The little summary on the OoT page says that the specific Japanese version was chosen for version elusive glitches and faster text, and thats kinda misleading. The only difference between the two NTSC roms (Japanese
English) is 1 byte in the rom header which determines whether or not to load the Japanese or English text, with Japanese being the faster one. How ever NTSC 1.0 was chosen for version exclusive glitches to the 1.0 build.
If someone with the ability could update that summary to reflect that it was the 1.0 version chosen for version exclusive tricks, and Japanese was chosen for the language. The way its worded now implies that Japanese 1.0 has version exclusive tricks, which it does not.
I watched the live reveal, and saw some of the actual TASing done.
Run is very entertaining. Lots of cool MM glitches are shown off that are otherwise useless and unknown, namely anything with 0th day.
One problem with any MM run is 1st cycle, as its essentially an autoscroller in that what you can is very limited and are waiting for an in game event to happen, and yet they managed to make it entertaining.
I voted yes, and I believe it deserves to be published. The run is very entertaining and heavily optimized.
I'm just curious what are these tools that N64 TASers lack?
I'm saying that that SOME of them are not willing to learn newer tools, they use savestate, frame-advance and Virtual Pad and leave it at that. They never go into learning lua or TAStudio/debuggers/trace-loggers.
Then there are tools that don't exist yet (Output Log, setting game logic in intiutive ways, automating optimization). And they don't provide ideas on how to improve existing tools or on creating new tools, because they assume the tools they use can't be better or replaced.
You do realize not everyone has the exact same skill set. Something that you or I see as potentially being automated doesn't mean someone with less (or no) programming experience will notice that as well. Automating things or even programming experience in general isn't required for TASing, and to insult people for not having those skills in what is a hobby they do for fun by calling them stubborn is not cool. Even having written scripts to automate things in OoT, I will do many things manually just because these automatization can be situational and because sometimes its relaxing to do something monotonous
TASeditor wrote:
I think you are seriously underestimating the complexity of TASing a game with hundreds of runners over time, no new tool is going to be created that will dampen the sheer amount of knowledge required to make even the most basic route.
Knowlegde has nothing to do with it. The tools don't take away the need of knowing the game, but it's possible to automate certain things based on knowledge. Of course next step is to integrate the knowledge into tool for trivial tasks, eg. initiating a SuperSlide/BombHover/etc.
Yes, which is why this TAS used certain scripts to automate simple things like textboxes and side hoping. However, these tools are very situational currently just because with a game that has as many mechanics as OoT and with the precision of a TAS there are a lot of subtle variations you can do to save a frame here and there, and to program the logic behind all of those gets too complex to quickly.
TASeditor wrote:
I want links to all resources for this project (lua script, ROM/RAM maps, planning documents, etc.).
TASeditor wrote:
There already exists memory watch, lua scripts, and a vast amount of information on ZSR/accompanying spreadsheets that are used. Hell, even this TAS makes use of a new tool to view collision... which you can find in the submission. [...] Attacking jmarvin suggesting he is lazy for not developing tools is fairly arrogant.
Then link the source, it isn't linked in the submission. And don't put it on whatever generic file hosting service. I wasn't talking about him specifically in the second sentence, sorry if it sounded offensive.
So, I'm the guy that actually wrote the automating scripts used in this run, and the collision viewing script (which wasn't actually used in the making, it was only written after the input file was finished), and I've asked Taylor / the rest of the no doors collective to not make them public.
First off, there is no golden rule of developing that says that every piece of code needs to have the source be released, so to just demand them like you did on page 1 and again a few posts ago is kinda annoying. That being said, I do plan on releasing these scripts at some point. The versions I gave them are very situational and were never meant to be made public. You have some programming experience (it seems) so you should know that the stuff that comes out of prototyping is generally not releasable unless you start with the mindset of releasing it. Right now these scripts look really ugly cause I never intended on releasing them, merely just quick prototypes before I work on implementing them on the OoT practice ROM, but decided later on they should be released as a TASing / OoT science tool.
Also I did post in newbie before posting here, but still no response. After actually going into bizhawk code, I found that they don't have debugging or breakpoints supported yet. It's really frustrating when they say they have a feature and do the bare minimum in a way that makes it useless.
So I'm trying to learn more about goron missile, but I'm having issues with the debugger. The breakpoints i've set don't trigger when the flag is set. Anyone know of a guide or something to help with the bizhawk debugger?
Sorry that I can't help you (I don't know how to debug myself as well), but try asking in either the newbie forum section, or the bizhawk section since this appears more relevant there (less likely to be overlooked by new posts).
So after speaking with natwa and mzx, and they recommended using nemu. It may be old as hell, but it still has a good debugger. I've been using it to look into getting row 4 of BA to update in a duped bottle. I'm documenting everything here, http://pastebin.com/dLCc7cFX
Also I did post in newbie before posting here, but still no response. After actually going into bizhawk code, I found that they don't have debugging or breakpoints supported yet. It's really frustrating when they say they have a feature and do the bare minimum in a way that makes it useless.
So I'm trying to learn more about goron missile, but I'm having issues with the debugger. The breakpoints i've set don't trigger when the flag is set. Anyone know of a guide or something to help with the bizhawk debugger?
So I've spent the last few nights trying to learn more about this glitch. There is a flag that is set [English: (* 0x8040081F)&8 ] is set when entering 1st person shooting mode (arrow/hookshot/deku bubble). having that flag set while in goron mode causes goron missile. I've also confirmed that if you can get one of those items on goron b with weird b, it would still work. Since weird b is perserved through loading zones, it could be used in most catagories with goron just for fast movement and save time since it is faster than the 18 speed of a superslide or hess, and (1st video) a much faster lulliby skip and (2nd & 3rd vids) much faster alternate exit, and all explosive less.
https://www.youtube.com/watch?v=OoxaN8TVRjIhttps://www.youtube.com/watch?v=frRkvKxWXEMhttps://www.youtube.com/watch?v=rClCjzKcjVc
I'm trying to see when a specific memory address is read and written to in Majoras Mask (n64 game). I've set both a read and write breakpoint for this address but the debugger doesn't pause execution when the value is read or written, even when I can see in ram watch that the value has been written to. The address in ram watch is 40081F, but it seems for this game this corresponds to the physical address 8040081F, and I set breakpoints at both of those addresses and nothing happened.
What am I doing wrong.
Hathor, could you reupload the link to your ram watch/lua script, the link is broken.
Also Is anyone interested in working on an all masks TAS with me? I've only been working on it for a few days now. I'm currently trying to get the text skip before the twisted room.
It's not because it's not optimized. I don't think we have to explain you guys why we won't submit it here..
anyways, did anybody see my video and has an idea what happened there?
If it would be possible to post a movie file that can reproduce those effects, then it would be a lot easier to figure out.
Also, is the 100% TAS uploaded yet? I've been checking your youtube channel once a day since you said it was finished.
I could fill you in with more info and WIPs if you want.
If you wouldn't mind that would be great.
Also about your WIP on the other page, is it possible for me to convert it into something that Bizhawk can use?
Nvm I figured that part out.
Just out of curiosity, has anyone documented the emulation differences between snex9x 1.51 vs 1.53 vs bizhawk. The WIP i grabbed from the previous page seemed to only work in snes91 1.51. Using TAStudio in bizhawk I believe (but am not certain) it has to do with how the emulators handle lag frames.
Anyone have the link to the all dungeons route. I feel like that would be a good first TAS to try.
I've already got a tas up to the secrete passage that leads to sanctuary, and can only go up through sanctuary.
