DeathBasket

Or you can rewrite the code in the disassembled actor and re-assemble it after. That way you should have no trouble adding as much code as you need to.

I remember having problems with textures disappearing before, there was a tool included in (I think) ZLE2 called 'clip kill' or something that fixed it. I can't think of any easy way to change texture co-ordinates in the next room other than writing a program to shift all the vertices though.

I can't remember specifically but you can usually transpose timpani 1-2 octaves above the sound you want (in your MIDI editor or using the trsp(?) command in InstEd's text files) and then use a percussion set that contains them as the instrument. There was never a standalone timpani instrument in OoT unfortunately.

?? I use Windows 7 64-bit and I have never had any issues with the program on the two computers I've used it on. It seems weird that you would need to do that.

What exactly do you mean by grainy? I'm assuming something like A lot of semi-transparent stuff ends up looking like the inside of Ganon's sword slash effect in that picture.

You don't need cutscenes to make a boss fight intense so in my opinion it isn't really necessary. One of the boss battles I had planned to make a long time ago would have taken place in just a plain dark room where the door locked behind you after entering, then the boss itself would quietly sneak up on you. I feel like if you get the atmosphere right then cutscenes just don't matter. It's up to you in the end though, do what you think works best for the situation.

It's here: http://www.mediafire.com/download/169jvby2rleemnd/remote_bombchu.zip I was more asking about what tools are best to use than differences to OoT. I'm sure I can figure things I should change out for myself if I need to, but I'm not sure which tools are currently best for converting maps and objects.

What is currently the best solution for making and importing maps to Majora's Mask? Just thought I'd ask here rather than looking around and trying to figure out what's new or what works by myself. Preferably I need some way of doing it that will work on a console. Thanks.

Actually the pause menu delay doesn't exist at all on a console and pausing on the debug version is much faster than other versions. Emulators are pretty bad at handling the pausing in both OoT and MM. What does this code actually do?

Last I knew the most popular place for SM64 was here: http://jul.rustedlogic.net/forum.php?id=41 I haven't really kept up with anything in a long time though so I don't know whether or not that's the case any more.

Got these about a week ago:

Yes. I don't know if this was a response to what I posted or not but it's irrelevant. The crash debugger does not appear on emulators and the button combination shown in the video does not activate it on a console, I tried. Maybe extra controllers are required (as with some other features) but I only have one so I don't know.

Did anyone ever figure out the correct button combination? I only remember MM's one because it's super easy but I know it doesn't work. Anyway, just wondering if anyone knows what colour the bar that appears is in a normal (not debug) version of Master Quest? I noticed that on the debug ROM it's red like in MM while in all earlier versions of OoT it's yellow iirc.

Regarding any kind of custom actor development: did anyone ever find out if there was a version of the mips-gcc compiler that didn't mess up the relocations data? This made it really difficult to properly produce custom actors. Also, does anyone know anything about why using custom actors often triggers the so-called "Hyrule Field glitch" (prevents actors from being spawned)? I also noticed that some things I wrote in assembly code worked differently between PJ64, Nemu, Wii VC and N64 and I don't know why (I'm not really a programmer and don't know much about programmy stuff). This is probably why my boss rush thing only partly works on console. Just a thing to consider for anyone still working with assembly code. I don't know if I can do much about InstEd. Anything about what it can do should have come with the program or be somewhere on my site I guess. I'm not great at keeping notes about stuff. If I can find the source maybe I could post it but that wouldn't be for a while right now. Sorry about that.

Yeah, there's no real flute in OoT/MM afaik. You can shift your music down an octave or two and use the piccolo but it's not ideal. I think there was one in StarFox 64 but I have long since forgotten everything about that game so I'm not sure how you'd get at it now. The closest to a flute Super Mario 64 had was pan pipes I think.

I'm not going to lie, this just looks like it'll be a really bad game. Judging by other games of the same style, it'll get very boring very quickly.

I'll admit I never really used to care, but that's because in the beginning I was naïve and assumed anything on emulator worked on a console too. That and I just assumed 99% of people only played on emulator because it's more convenient (ex. I don't have a USA N64 or flash cart so I can't really play NTSC games on a console anyway, and I never played games for any extended period of time). However, once I started noticing things that behave differently on different emulators it became a bit of a pain in the ass not knowing which emulator was giving you the correct behaviour or if any of them were at all. Also, since we are making N64 games, they should surely work on an N64... I don't know, it just got to the point where I didn't really want to continue knowing that I don't have a way to ensure what I'm doing even works on the original hardware. It's a bummer. :/

This is what spinout started (whenever it was) but some stuff couldn't be found yet iirc. I also know a lot of things have hardcoded addresses which can be annoying especially in the case where it's inside a compressed file.

Well I just saw xdaniel's tweet about this. Came here to say really good job on getting this to work! I hope in the future everything we do will actually work on hardware. That would really be something to look forward to.

Sorry, but: I programmed that actor from scratch in C, using en_anim that spinout wrote earlier as a guide for the animation part. I fail to see how this does "nothing but stand there". Interaction? The collision for the actor was fully working, if that's what you mean. Besides, what does a generic NPC do other than stand there and talk to you? Sorry for bringing this up again but yeah.

We really don't understand much about making hacks for this game that will work on hardware, do we? Did you change anything else at all other than the display list? I've run into things before that have crashed just because of the way a piece of code was written. It might also have to do with filesystem errors or something, I don't know. Did anybody ever figure out the exact reason Zelda's Birthday doesn't work on console?

Just out of curiosity, what method are you using to crash the game?

I'm moving tomorrow so I might not be around for a while. Hopefully I'll be able to get an internet connection set up quickly.

It's-a-me...?

The only reason things don't seem reasonable is, as I said, most people have an irrational fear of low level programming. If more people actually researched into the more complicated areas of actors then programming new ones wouldn't seem like such a huge task. All it requires is an understanding of assembly code and how to use a debugger (and interest, of course). There is enough information out there already to make programming completely new NPCs possible, as I've shown. The fact that only a small minority of people ever tried programming actors at all does not mean nobody can do it, it just means nobody really tried. We have all of those now. There just aren't many tools made specifically for MM so I guess that's why most people avoid it. Most people still interested in the games are taking on their own projects too, which makes OoT more useful to them. If anybody seriously wanted to start hacking MM then the lack of information on it shouldn't be an issue anyway. Sorry, I'm bad. I thought this project had only started not long before I joined it, no idea it'd been around any longer than that based on what had been thought up at the time I joined. Anyway, back on topic, I know stuff is still being developed for this project but I'm not going to pretend there's a significant amount of work being done right now. I'm not saying it won't pick up again soon, it just feels like we need to get everyone back together at some point (I mean everyone, not two or three people) to focus on it a little more if possible.