CloudMax

It should certainly be possible to uncensor the later versions. However, I do not really see why you'd want to go through the trouble of doing that? The only difference in the game is pretty much the censorships, and a very small amount of patched glitches, which you won't notice unless you try to do them. Wouldn't it be easier to just play 1.0 in this case? And for the second part.. That's something I'm interested in as well. I've been wanting to know what it is that cause hardware issues.

I remember trying out Forest Temple a looong time ago. One thing is for sure, this is way more difficult than Master Quest. The puzzles are no pushover in this mod. It really have you thinking, which is great, because that's what zelda is all about.

File Name: CloudMax's ROM Patcher File Submitter: CloudMax File Submitted: 30 Jan 2014 File Category: Community Downloads For a description of the tool, visit the project thread here. https://www.the-gcn.com/files/file/71-%7B%3F%7D/ Click here to download this file

Version 1.1 has now been released. You can use it online or download it at http://cloudmodding.com/app/rompatcher You can also download it here on The GCN at (Keep in mind that it is released roughly 1 day later on the-gcn) https://www.the-gcn.com/files/file/71-cloudmaxs-rom-patcher/ Patch format information is available here. So, as we all know, there is this thing called .ppf. It is an effective format for finding differences between two files and creating patch files that can be shared and then applied by others. However, as I was working on a project I noticed that .ppf just didn't make the cut. It was close to impossible to organize things, and no easy way of seeing what the patch actually does. So I began developing my own patcher, and based it on the Texture Packer that I've written. To apply a patch, simply drop the patch .txt file and the ROM on the tool together. Or drop two ROM files on it to generate a patch of the differences between the two. This patcher, unlike .ppf, is being developed for modders, as well as being a simple tool that can be used to generate patches which can then be re-applied by others. The patch file is in plain text, and the reason why will be very obvious soon enough. Here is an example of a patch file that was generated by the patcher. It compared a clean OoT Debug ROM with one that I had applied the MM Interface Color hack to: As you can see, each line represent an offset that the patch writes to, which is then followed by a hex string, that can be of any length, that should be written at the specified address. Now for the thing that makes this patcher so different from ppf. The patcher supports complicated expressions, pointers, variables, conditions, alerts and comment lines among other things. To create a variable, you create a line formatted like this: var,<variable name>,<variable value> For example: var,dma,0x12F70 To use a variable, you place it's name surrounded by curly brackets in the address. So you could do something like this: var,code,[{dma}+0x10*28] Now variable code will be [0x12F70+0x10*28], which is [0x13130]. 0x13130 happens to be the location in the dmatable that points to the code.zasm file in the OoT Debug ROM. By placing square brackets around an address, it'll act as a pointer, and it reads the 32bit value inside the ROM at the specified address. So variable code would become 0x00A94000. We can now use variable code to write data relative to the code.zasm file. For example: {code}+0x6C322,FF82 it'd turn into 0x00A94000+0x6C322, which is 0xB00322. So it would write 0xFF82 to 0xB00322. By starting a line with a semicolon, the line will be treated as a comment. Now if we combine everything that we have mentioned above, we're able to write a quick patch. Here is a patch I wrote that does a few minor ASM changes and set all the Interface Button Colors to the Majora's Mask Colors: I now had the patcher convert the RAM addresses into ROM addresses for me, and it uses the dmatable to determine where the code.zasm file is. This makes the patch flexible and usable no matter which file has been extended or shortened before it. Now for some other nifty little commands. You can create alerts by formatting a line like this: alert,<alert message> An alert is a small red bar that appear at the top of the page for 5 seconds with a message, before it disappear. If there already is one on the screen, it will be replaced. You can abort the patch, ending the execution of the patch and preventing the patcher from downloading a new ROM, by simply writing "abort" on a line. You can also end execution of the patch by writing "end" on a line. Unlike the abort command, this will still download a ROM of all the changes that have already taken place. Now, both "abort" and "end" are completely useless without the conditional command. You set up a conditional command like this: con,<condition ID>,<condition> and you end the condition with a command like this: endcon,<condition ID> The way you use it is very simple. The Condition ID is used so that the patcher knows which endcon command is connected to which condition. If the condition is true, the code between the con and endcon commands will be executed, otherwise they're skipped. Here's an example: If 1 is equal to 2, it will perform the alert saying that they're equal, then end the patch. Otherwise the alert saying that they are not equal will be performed and the patch will continue on. Here is a patch I wrote for the Debug ROM. It uses all commands except for "end". Everything is case-insensitive. condition IDs and Variable names may only consist of letters and underscores. the hex string may contain spaces, they are automatically omitted by the patcher.

I hope you're aware that the code.zasm file you linked is not actually a code.zasm file. I opened it in a hex viewer and this is the first thing I see "%PDF-1.4.%âãÃÓ.3 0 obj.<</Subtype/Link/Rect[247.18 662.52 345.26 673.62]/A<</S/URI/URI(http://BitManual.com)>>/Border[0 0 0]/C[0 0 1]>>.endobj.4 0 obj.<</Subtype/Link/Rect[294.68 194.52 426.02 205.62]/A<</S/URI/URI(http://BitManual.com)>>/Border[0 0 0]/C[0 0 1]>>.endobj.5 0 obj.<</Length 1960/Filter/FlateDecode>>stream" Could it be that you messed up and renamed some file to code.zasm? Because I am very confused right now, lol.

Ops. The Start Button is still gray because the pastebin I linked to set it to the default color (gray). the color should be FF823C not 787878 for it to be the MM color. And I'm not sure why it doesn't work for you with a clean ROM, I'll test it myself and see what happens. Edit: I tried it myself, and it works just fine.

Yeah. First I looked up which file the code was located in. (took a small sample surrounding one of the addresses mentioned in the thread, searched for that in the ROM, checked which file that address belonged too) It were located in the code.zasm, so we know that all the addresses are in there. Then I just looked up where the code.zasm started in the RAM by taking a sample of the beginning of the code.zasm file and searching for it in the RAM, and it was at 0x0001CE60. So I know that by subtracting that value, we'll convert the addresses to their addresses relative to the code.zasm file. Then I looked up where the code.zasm is located in the ROM, which is 0x00A94000. And 0x00A94000-0x0001CE60=0x00A771A0 This is how I convert big bunches of RAM addresses to ROM addresses. A lot more useful than looking up all of them manually.

That's some very simple math. Take the addresses and subtract by 0x0001CE60. That gives you their offset in the code.zasm file. If you want the offset withen the whole ROM directly, just add 0xA771A0.

Since I wrote this just the other day, I may just as well contribute with it: http://pastebin.com/qGDVSxda That is a very, very small ASM hack that allows you to set the red green and blue of all the interface buttons individually. Also, here's the RAM addresses for the Start Button Colors: S Button Red & Green: 0x80089180 S Button Blue: 0x80089184 It doesn't use the same format as the other buttons. each color is a byte rather than a halfword. I think all other things I have are there already? My documentation is such a big mess, I can't even find things myself. (it's a 900 rows text document filled with random stuff for the title screen, file select, pause menues and interface... Unorganized, etc.) Edit: A bunch of things for MM NSTC-U 1.0 80117390 Start Button Green 80117394 Start Button Blue 8011739C Start Button Red Clock stuff: 80119914 Hour Lines Red & Green 80119918 Hour Lines Blue 801199D8 Halfcircle Blue 8011A110 Diamond Red & Green 8011A114 Diamond Blue 8011A1A4 Day Number Blue 8011A39C Star Red & Green 8011A3A0 Star Blue 8011A738 Sun Red & Green 8011A73C Sun Blue 8011A888 Moon Red & Green 8011A88C Moon Blue 8011AB84 Sun Text Blue 8011AD20 Moon Text Blue I haven't doublechecked if these things actually are 100% correct, but it's what I have in my document. That's about everything I have on MM (that isn't already in the main post) since I lost all my documentation last year when my computer had a rollback after it crashed.

That is.. odd.. I just tested writing a clean texture pack back onto a clean ROM... And a lot of textures are all messed up. I do not know what has happened, for some reason I4 and IA8 textures are all messed up. I have no idea how this could possibly have happened. I have not touched the convertors.. I think..? I'll look into it. Edit: I've been doing it wrooong. What I've been calling IA4 textures all along is actually IA8 textures. I have no idea how I missed this since my "IA4" textures actually use 8bits. And what I've been calling IA8 textures have been IA16 textures that use 16bits. Now.. this leaves us with only IA8 and IA16..? Where the hell is IA4?! Well, turns out that I'm dumb. IA4 is a format that I didn't know about which uses 4bits. (logic...) 3 bits are used for grayscale, and one bit is used for alpha. So I've been calling I4 and IA4 textures that same thing, which explains the chaos. Edit2: I found the problem with the IA16 textures. (what caused the file select to look all messed up, etc.) The alpha and the color had swapped places. Edit3: Version 2.1 is now released. I've tested every single texture format now, and every texture available in the generator. If something is wrong now I'm going to be sad. Changelog: IA16 was incorrectly named IA8, this has been corrected. IA8 was incorrectly named IA4, this has been corrected. IA4 (the real IA4 format) is now supported. All textures in the OoT Debug Generator that were incorrectly set to I4 has been corrected. Solved an issue that caused the gray and alpha channel to swap place in IA16 textures.

The online and offline version should both work properly, however, the website may be cached as I do not provide a version stamp on the urls, so it is possible that it is loading old versions of files, causing some issues. I'll fix that for the next version so that the online and offline version should work the same way. I looked into the firefox issue, and you're right. One of the last minute changes seems to have broken firefox. The funny thing is, it is firefox that actually works correctly. the program SHOULD crash. I placed a function within the code that runs when combining files, but I also call the function from the code that generate a texture pack. In other words, I'm calling a function that shouldn't even be defined, I'm surprised it works in chrome. So until the next version is out, use chrome. And about the issue about changes not taking place in the downloads folder, I've never had the issue because my browser automatically suffix the file with (1), (2), etc. if there's already a ROM in the downloads folder. That does not seem to be the case for all browsers. I'll have the tool add a small timestamp in the next release so that this won't happen. And yes, I plan to add more addresses later. At the moment it uses the list from my z64editor. There'll most likely be a bunch of new textures in 1.3 (some stuff from the title screen, item names, action texts) Edit: Scrap the whole 1.3 idea. I've worked on the tool all day and improved a lot of things, and will be releasing 2.0 today. With this release, texture packs that are downloaded will contain proper names for almost every single texture available in the pack (and will have for all of them at some point). Here's a quick example: https://dl.dropboxusercontent.com/u/6440063/OoT/modding/texture_packer_2_preview.png Now, there will also be one major new feature for 2.0, which is why I decided not to go with 1.3, and that is the "generators". The generators is what tells the tool where all textures it should download for the provided ROM are located, their sizes, formats, and even a name to go along with it. Previously it was setup in a very lazy and bad way, there really wasn't a way to extend it and add new functionality. Now there will be a "generator" for every ROM that you can generate texture packs for. Now, I will only be maintaining the OoT Debug ROM generator, but the main idea of this feature is that others are able to create their own generators for other games and share it with others, so that they can create their own packs for other games. The setup is quite simple. There is one script file containing an object with one entry for each ROM. the entry key is the ID and Version of the ROM in question, and that's how the ROM will detect which generator to use, and the value of the entry is the name of the generator that is to be used. Here's what it looks like by default: generatorEntries = { "NZLE15":"oot_debug_gen", "CZLE15":"oot_debug_gen" }Now, as CZLE15 and NZLE15 (both of which are found in different OoT Debug ROM) both are "oot_debug_gen", we'll create a file named oot_debug_gen.jsNow, the format for the generator is *slightly* more complicated, but still relatively simple, and anyone should be able to understand it quite easily. Here's an example: This example would produce a pack that looked like this: pack/P_00012FE0_icon_item_static/0005A000_ia4_Heart_Piece_1.png All symbols in the folder and file names which are not supported will be replaced with a hyphen. Spaces will be replaced by underscores. So if you have textures that you want to extract from the ROM, but aren't available in the generator already, you can add it in yourself without any trouble. Iif anyone wants to contribute with textures that aren't already available in the generator, feel free to send me the details of the texture in question. I need the name of the file the texture is located in, the offset of the texture within the file, the format of the texture, and the size of it. If you do not know the format I can look it up myself. And if someone starts developing generators for other games I'll gladly include it with the official release of the tool if it looks promising enough. Edit2: Version 2.0 is now released. Solved an issue that caused some browsers to crash when attempting to generate a pack. When using the tool online you'll no longer have issues with previous versions being cached. The tool no longer get stuck in the loading state when providing an invalid file. The tool will no longer crash when using any symbol except underscore in pack file names. Generated packs will only include the A_00000000_default folder if the pack is empty. Texture Packs and ROMs that are generated now have a timestamp in the file name. The OoT MQ Debug ROM pack now include title screen, item names and action texts textures. A new feature called "Generators" has now been implemented. The generators is what tells the tool where textures are located so that they can be extracted from the ROM. You're able to add new ones for other games, or modify existing ones. There is a brief explanation of how it is set up in the generators/generators.js and generators/oot_debug_gen.js files.

That is very odd. If the names are set up correctly it *should* work just fine. I am using the tool to import all the custom textures I'm using for my mod, and I've applied it like 50-60 times with the latest version. If you send me the pack I can see if I can find the problem. Also, are you using a downloaded copy of the tool, or are you using it online? Edit: As an example, I just threw together a pack and applied it with the latest version of the tool, and here's the result: So it works perfectly fine for me. Edit2: Sorry about that! It appears that there was an issue with the IA8 and RGB5A1 converters, which made the arraybuffer half the size of what it should've been, so it caused an overflow and crashed. I'll be uploading a new version shortly with various bug fixes. Edit3: Version 1.2 is now released. The tool will no longer crash when importing ia8 and rgb5a1 textures. Solved an issue that caused the tool to get stuck in a loop if provided with 2 ROMs or 2 Packs. Fixed several crashes that could occur if you provided various files in specific orders. You must now provide a N64 ROM in order to generate a new texture pack.

Version 1.1 is now released. You can use it online or download it at http://cloudmodding.com/n64/ Changelog: Deflate compressed files are now supported. .jpeg/.jpg and .bmp/.dib images are now supported. The tool will no longer crash if you attempt to import an empty texture pack. If an error occurs, such as the one specified above, you'll now receive a message. Large files will no longer cause the tool to freeze temporarily when importing a pack. Rewrote the texture pack import code to improve performance and make import bar reliable. Solved an issue that caused the tool to get stuck in an import state if a file was invalid. You can no longer generate or import a pack when the tool is already doing so. The import bar is now properly reset after importing a texture pack. Updated a dead link in the instructions.txt file. All buttons can now be properly selected with Tab. All links now open a new tab.

So, I "kind of" picked up modding and custom scene making yesterday and therefor actually messed around a little with this tool, and I've come across the most annoying bug. It is driving me nuts. If you hold an arrow key and move the camera in a direction while changing tab on the right side, then release the arrow key, it will still be registered as pressed, so the camera just keep moving... I have to repress the key in question and then release it for the camera to stop. This happens to me like once or twice per minute, because I try to multitask and move the camera around while navigating the menus. It sure is a pain when the camera just keep panning away. The same goes for the space bar, etc.

I'd actually say that the second video was very well made. The first one was just... weird. These videos are pretty much what I'd expect to see when clicking on a link by Airikita in the IRC. 99% of the times it's something japanese that I just do not understand at all.

Well, it IS using data uri, which basically is an inline file, which is why I said that it wasn't really doable with CSS. (Several of my subsites even use data uri for the favicon, and I use data URI a lot for many of my sites) Sure, data uri makes it so that you won't have to load additional resources to the site, which does decrease the server load, but it does make the file containing the data uri itself larger, which will have an effect. I was thinking more along the lines of being able to do something natively with css. I'm not really sure if it would be worth adding it. I barely notice a difference. If I wasn't aware of the difference, I'd never notice it.

Everything oddMLan changed, should be perfectly doable with css (as long as the colors are websafe) without affecting server load, except for "Added a very small smooth noise to the gray background.", as I assume the grey background is a css gradient rather than one big image. I agree on several changes he did, especially the shadow in the search box, which was way to dark in my opinion. It looks like the search box goes very deep, and the search button pops out. It just look weird to me, I'd flatten it out a little. As for the other things he did, I can barely even see the changes.

Oh. Your ROM does not have the same ID as mine. Your says CZLE for the ROM ID. Mine is NZLE. So if doesn't detect the ROM as the OoT MQ Debug, and therefor does not extract any textures. If anyone know why this is, that'd be great. I guess I could make it check for either IDs in future versions. Until then I guess you'll have to either find a debug rom that works, or change the ID manaully in the ROM header. (you can easily locate it in a hex editor)

It is able to extract textures that i have manually told it to extract by providing texture offsets, types and sizes. This should work with a clean Debug ROM. (I think. It could just be that the ROM I'm using as a base isn't clean.) I set it up so that it check the ROM ID and version in the ROM header to see which ROM it is that you're providing. If you open the javascript console in your browser (Ctrl+Shift+J in chrome) it should say "ID: NZLE, Ver: 15" when you drop the debug ROM on the site.

Latest version of Firefox, Chrome, Safari, Opera and Internet Explorer SHOULD work. I tried all except Safari, but I don't see why it wouldn't work. When you generate the new pack, the .zip file should contain a folder named "pack" along with the instructions txt file. The pack folder should *always* be there. Even if you provide a file that isn't a ROM to begin with. It should just treat it as an unknown ROM in that case and generate a .zip containing a /pack/A_00000000/ folder. the instructions txt file is for the person you share the pack with once it's done, rather than you, so that they get some kind of pointer on what to do with it. There could possibly be some error causing the pack folder from not getting included in the zip file for you. But if that was the case, the site should just freeze and not download at all, because the tool does not catch any errors.

File Name: CloudMax's N64 Texture Packer File Submitter: CloudMax File Submitted: 11 Jan 2014 File Category: Community Downloads For a description of the tool, visit the project thread here. https://www.the-gcn.com/files/file/69-%7B%3F%7D/ Click here to download this file

1.0 is now out and available for download. It can also be accessed online on my website. Check the top of the first post for links.

That is correct.