DeathBasket

I put a link up yesterday but I didn't 'officially' update the thread since I was pretty sure people would find things that would have to be fixed early on (turned out to be true, as always). Right now almost everything works the way I want it to as far as I can tell and I'm happy with this version. I may update again if something really major is found that ex. makes a dungeon unbeatable or crashes the game. For now, it should be fine and completely playable. If you did download the old one, I would recommend that you update since there was a switch I missed that could get set in Stone Tower Temple and would prevent you from completing a later room (and the dungeon itself).

Most likely case is that you pressed a d-pad button. The functions for interrupting and skipping cutscenes haven't been patched out in this ROM. You actually receive the shard of power when you enter the blue warp after beating Gohma and not when Link is shown holding it over his head - this is merely part of a cutscene. I'll be playing it on N64 so if I have any problems with it I'll let you know. I'm not sure how much time I'll be able to put into it though.

You appear to have broken the start menu a little - where the game would usually put the last visual frame in the background it's just freaking out instead. I'd take a guess that this might have something to do with the code for 'fixing' pause delay that has been floating around. Last I heard some people were going as far as patching it to the ROM, which is totally unnecessary. I'm not sure how many people know it, but the debug ROM's pause menu on a console is very fast compared to all other versions of OoT; it's only on emulators that it will slow down or crash. I'm not saying you're wrong to use it (vast majority will play this on emulator only) or that you should go and fix it but, to me, looking at a pause menu that's flashing is a little annoying/distracting. Also, when I received the shard of power I couldn't see it on the screen for more than a few seconds because it was being drawn behind the map's mesh (again this probably doesn't happen on emu). I assume this can be fixed but I wouldn't know how. Other than this it seems good so far, no other major issues for me and the script has made me giggle more than a few times already.

You can never really quit a hobby I think. I don't intend to get back into it altogether, this is just something I want to do at the moment.

This is a pretty easy feature to add. I've thought about it for a while but I'm not sure if it's necessary. I have plans for those but not for things like skulltula houses or the moon trials. This may change, as I mentioned. I can handle this myself but thank you for the offer! I haven't used it in a long time and I don't plan to really.

What you can expect: Much like what Nintendo did with Master Quest for Ocarina of Time, my main goal was to rework the four core dungeons from the game. In addition to this, there are some changes to overworld areas and to some of the side dungeons, but nothing too extensive. Text has been updated to reflect these changes where necessary. While I don't consider this to really be a full-blown hack of the game, it's likely that you won't be able to play it in the same way you'd play the original. Glitches are not required to complete any puzzles or to beat the game but I have made no effort to patch any of them. Estimated progress: 100% Release formats: 32MB N64 ROM (hardware compatible), Wii channel for Virtual Console users Downloads: http://pastebin.com/RLzh6FpJ (updated to v1.1) Screenshots/trailer: None, maybe I'll add some soon. From what I've heard from the people who have played so far, this can be pretty difficult to beat. My advice for playing would be to not treat it the same as normal Majora's Mask; puzzles might not always have obvious solutions, items might not always be in the place you'd expect, switches might not behave the same way, etc. I didn't think anything I did would be too hard to figure out but it's different when you're making it I guess. I would like to thank xdaniel btw because SceneNavi has been incredibly useful and reliable throughout my time working on this, it's a very good tool.

Thanks for the input. I checked out the texture explorer tool and it worked well. I ended up overwriting the copyright text instead but for what I needed it's fine. Wouldn't say I'm back as such, I don't really intend to be posting much or sticking around when I'm done with this but we'll see. I'll post a topic for the project I'm working on when it's closer to completion.

Basically what the title says. I'm working on something at the moment and ideally I will need to edit the title screen logo a little but I'm not sure where to look to find it, what format it will be in, etc. I'm working with a decompressed US ROM. If anyone has any info on this at all then it would be very helpful to me. Thanks.

I don't consider this useful. To me, ROM hacking is about taking a game and changing its functionality while remaining within the constraints of the hardware you're given. This is not it. This is like the URA project where you're going to need a very specific setup to get the game to work at all when the goal imho should be to release something that would work on a retail N64/expansion pak/cartridge and not require additional hardware. Nobody has a 51MB expansion pak. Emulator-only hacks are less impressive. Let's not do this.

Porting actors between games would be pretty difficult - someone claimed to have done it once but it was quite obviously fake, which they didn't admit at the time probably because this community has been awful for people wanting to say "I'm better than you" in the past. Anyway, that's kind of irrelevant. To port actors between the games, you would basically have to find all the function calls made in the actor's code and change their target addresses to be the same function in the other game, if it even exists. That's actually not too hard in itself but becomes a huge pain when most of these functions are not documented at all and you've got to check whether they are taking the same arguments and whatever. You'd also have to find and change any fixed addresses the actor reads from such as the current save file, loaded actor list, etc. and data at these addresses are not structured the same way in both games. Even then, the actor's RAM structure is treated differently in OoT and MM from what I remember so that would probably have an effect too. It's not impossible, but for anything other than a very basic actor it could be quite difficult to get this to work.

I like games that I find fun to play. In general this seems to be older games but there are certainly some newer ones that I do enjoy. I don't really like handheld gaming because it's uncomfortable (as much as I want to enjoy 3DS I can't play it much) and I guess I don't ever play PC games either. Most of the time it's N64/Gamecube but I recently bought a Wii U so we'll see how that turns out when I have time to play it properly (I did a playthrough of TWWHD only so far).

The advantage of having an N64 copy would be in helping to develop the emulator that was used to run the game rather than to actually debug the game itself I would imagine. It's not unreasonable to think that this ROM is out there somewhere but whether or not this is an original copy is debatable.

Do you guys remember that the disc with MQ on it also had regular OoT? It makes sense that there would have been a debug version for both. As xdaniel said though, why would they have put it on an N64 cartridge?

Really good. More people should be doing things like this.

I don't get that error (original, unmodified debug ROM). I did get it with some MM ROMs I made a few changes to (even after correcting CRC) but they started anyway.

SketchUp's built in exporter makes oddly sized textures iirc. I can't remember exactly but I never had any problems when I didn't use the built in exporter.

The size actually doesn't matter. While the file's location is noted in the file table, it's never actually used by the game iirc. You can just put it anywhere as long as you change 2 instructions somewhere that specify where the file is supposed to start (I don't remember where this is). You might run into problems if the samples within the file are arranged differently though since I think their addresses are all referenced from within the instrument sets. Unless you were to also move all the instrument sets then if one sample is in a different spot you could end up having most instruments sounding like static or something. by the way, just to clarify (if I remember the correct names) Audiotable - all sound samples Audiobank - instrument/sound sets Audioseq - music sequences

I don't even remember how this works anymore lol. Maybe I didn't put anything in the control file but used the length of the longest channel that was in use? If it is that way then it'd be a pain to go through each trying to find the total lengths. Are you sure all channels are ending at the right time and there's not some unused channel in the MIDI or something that's somehow making it through and messing things up?

Is there silence at the end of the MIDI file? Sounds like the length defined (I think) in the control file before looping is longer than the length of any of the actual music channels.

This looks really cool.

Can't really say what's 'best' as I only have an everdrive and haven't tried any other N64 flash carts. All I can say is that it works perfectly for what I bought it for (playing games). I don't know if there are any issues right now that would make another flash cart worth getting instead.

The sequences are all in order. There's no free space after that table which is why a hack would be required to allow more sequences in the game. iirc that z variable had something to do with how the sequence plays like not allowing other sequences to play over the top of it (unless that was something unrelated I did, this was all so long ago now). Yes, you can make a hack that plays different music at night only in certain areas. It's really just a case of how much time you want to put in and how complex you want a hack to be. I can't really help out with anything right now. Real life is kinda hard for me to deal with at the moment and I don't want to spend time on things like this in my free time. Sorry.

My guess would be looking at how the sequences or sounds are loaded on the change from day to night (or night to day) and forcing both to act (almost) the same way. iirc the sound effects set for night is part of the scene header so that part could likely be replaced with another sequence number that would be played during night if you wanted to do it that way. To add more sequences and instrument sets than the game usually defines, you can rewrite the tables to have more entries, store them in another area of the ROM and use a piece of code to load the new tables into unused RAM at some point before they're needed. You would then have to update anything that needs to read the tables to use the new RAM addresses of course. Unfortunately just saying what I'd do doesn't really help anyone out...

All cartridges contained compressed ROMs afaik and very few games ever used the 64MB cartridge. Having 12MB free when it's decompressed doesn't mean that you can compress 12MB worth of files and fit them in the compressed ROM (this was mzx's point). I checked and one of the Japanese versions of MM has less than 0.5MB free when in compressed form compared to over 16MB when decompressed. Still, this argument is pointless right now.

imo it's a whole lot simpler than having to manually update relocations data etc. but I didn't know about it crashing on a console, I never tried any actors out that I modified. I did hear that my boss rush hack mostly worked (most actors were modified this way) but I don't know.