CloudMax

I see. that makes sense. still, it should be possible to convert pixels to scale by comparing the original pause menu size (240x160) with the scale ingame to get the difference. Then do the same with icons (which actually appeared to be 28x28 in oot when I checked). However, in the end it just felt like useless extra work, so I'll just scrap the idea of doing that. I don't work Fridays, so I'll spend most of the time when I get home today and tomorrow to make some actual progress.

I put together a code to get the float height and width of the pause menu panels, so I can use that as a base to calculate the perfect position for objects (so I can provide pixels values from OoT and have it converted to the right float value). According to the code, the height of LPlane is 6.000001f, and the width of LPlane, CPlane and RPlane combined is 9.133646f. That seems wrong? The textures should total 240x160, in other words it should be 9:6. Are you sure that you set up the scaling properly? because it sure seems to be off, by very little. I'm setting it up so that the items are stretched along with the equipment so that they go together perfectly, so this won't really be a problem for my code. Just bringing it to your attention. Edit: Scratch that, I'm confused. The height and widths I receive from .renderer.bounds.size.x and .renderer.bounds.size.y does not seem to be what I excepted them to be. Edit2: nvm. I am dumb. I forgot to do something quite important.

When I get home I'll try to finish up the positioning of all the items in the equipment and inventory (possibly even quest) subscreens and make commit. If you guys are find with it, I'd like to focus on the subscreens primarily, such as the cursor movement and that. (basically the content a of the panels you've already made SoD). I enjoy designing and coding interfaces a lot, which is why that's been the focus of my mod so far.

This is actually really interesting. I think an open world game featuring both termina and hyrule would add a lot to the game. It'd make it it's own thing rather than just "OoT in Unity" (which by itself is amazing, at least for modders). One thing to keep in mind though is to not think too far ahead and get too ambitious. That is unfortunately end up being what kills off many projects. Start out small, and build upon it rather than coming up with a gigantic project all at once.

and before we know it.. we have OoT in unity. oh, one can always dream. It looks awesome though!

I'm not sure if this is a misconception but.. I've always heard that this isn't console compatible? Model2n64, and Hylian Toolbox which uses it, that is. That is what has been putting me off. I really want to start modeling (when I have the time, working on other stuff atm.), but I don't want it to not work on console. xDaniel has made a new tool, which is compatible with console, problem is that I am dumb, and can't figure out how to use it properly, so I am stuck, since there isn't any proper tutorials out there for it.

My file select hack crashes when it loads on console. And this function does not get called at all. I also noticed that it is this very function I've hooked my ROM to RAM transfer in, since I thought it was only called on boot. So yeah, I guess this doesn't always run when the game crash Edit: The crash was caused by a relocation offset or w/e they're called.. Those things are damn annoying.

The only interesting photo that I've taken (in my opinion anyway) Taken roughly 2 years ago while I were sick for ~2 1/2 weeks. I were watching the TV series "24" all the way through during that period. At one point I got kinda bored, so I took out my phone and waved it back and forth while taking the picture. I kinda liked how the person on the TV screen ended up looking like some ghost or w/e so I kept the photo. (the fact that the camera on the mobile was horrible just made it look better)

Me ~1min before going to work today. Just look at how perfectly aligned those glasses are. not.

echo "wtf? php? Really?"; Let's try this again... console.log("Welcome! I hope you enjoy your stay at this unpredictable place that is the-gcn."); I were going to attempt C++, but I'd fail horribly.

I spoke with my friend and now I feel dumb. He found the info at http://tcrf.net/Proto:The_Legend_of_Zelda:_Ocarina_of_Time_Master_Quest (I must have missed it, because I use that page quite a bit) In the memory editor section it says "Setting RA15 to 1 enables a collision display. If Link swings the sword, hide behind his shield, shoot an arrow or do other stuff, the collision box will be colored red." So yeah, just set RA15 to 1 in the memory editor and it will display collision. Should prove helpful.

There is a way to make it so that your sword and shield hitboxes are visible during gameplay. I have no idea at all how to do it, but when my friend was over a few weeks ago we started up the debug rom on console, and he looked up things you could do with the debug menu. Specifically a menu when you could change a bunch of values to affect gameplay. As I recall, the sword hitbox is a flat square surface that follow the sword, and your shield is a *giant* flat square surface. (It is huuuge) So yeah, both of them are flat at the very least. And it is not just a line. Some googling should help. If not, I can always go grab my laptop later and look at the browser history, should be there somewhere. Edit: Or I can't... I can't see it in the browser history. He may have been using his own laptop.. Hmm.. I was sure he used mine.

A Debug ROM that isn't Master Quest. Do want. If that gets dumped one day, that'd be awesome.

Indeed, though reality can be harsh. I currently do not have the time to work on this project. I used to be unemployed and was actively modding for like 3-4 months, which explains the rappid progress of the stuff I did. That is no longer the case. You could basically say that I replaced the time I spent modding with my job. The little time I have left during workdays I'd rather take it easy and watch TV, surf the web, etc. This leaves the weekends. On the weekends I still do exactly what I used to, only thing is, my top priority is my new website, so all my modding related stuff is put on hold for now. (Well, I do still help people out "behind the scenes" through private messages and such, but nothing with my name on it is being worked on) The current idea is to finish writing the new CloudModding website, after that I want to finish my Texture Explorer (I got my job roughly 1 week after I started working on the tool, such bad timing, never got around to finishing it, haven't touched it ever since). What happens after that I don't even know. I currently have the urge to just sit down and rewrite my z64editor.. again... to make it even more flexible and manageable, not to mention improve the framerate of the entire thing. But you'll never know, perhaps I'll change my mind and pick up this mod again after the texture explorer is done. One thing is for sure, I am not ready to throw away this mod yet. I really want it to get somewhere as I myself am looking forward to being able to play it when the time comes. It will however take longer than anticipated.

I am actually quite confused by this whole "units" thing. when something is supposed to be 100 units, I just set it to 100 meters, or millimeters, or inches, etc. The only thing I have to do is make sure the I set the unit that the sketchup file is using (doesn't matter which one) to 100. and when I save it as an obj and import with sharpocarina or hylian toolbox, the sizes are set up perfectly. I didn't have to do anything else. Or I missed something and misunderstanding this whole discussion?. That's how I've been doing things though. I used to obj exporter that's available in sketchup (pro only perhaps?) Pretty sure one of my maps uses millimeters, and another uses meters. But I set the units to exactly the same values, and get the same results ingame. but obviously millimeters and meters aren't the same size.

Welcome! What in specific is it that you're interested in modifying? Game modification is a very broad subject and you can do all kinds of things like custom music, textures, maps, and so on. If you know a "subject" of modding that you're especially interested in, I am sure that there are people & tutorials around here that can help you get started.

Sorry for this taking sooo long. I've been caught up in real life, and the little time I've had to spare, I decided to play Lightning Returns which I bought recently. I'll look into the message textures. Those were last minute additions, I'm not sure if I actually tested re-importing them, which is totally my fault and I should never do so, because it can screw people over. I do however have time now. I'll first look into solving the incorrect textures, then the brightness issue. After that I'll *attempt* to solve the issue with firefox, etc., if I can't find a solution for it quickly, I'll release a quick fix for the first 2 issues. Edit: I also noticed that the letters in your pack aren't completely white? The do_action texture names are supposed to be white. (As can be seen when you extract the do_action textures with my tool) I think I might have a different idea as to why it becomes so dark.. though I'm probably wrong. Edit2: I were not wrong. It seems I were right. There was nothing wrong with the IA4 conversion. It is simply because your textures aren't entirely white that this happens. IA4 uses only 3 bits to decide the color. Which means that you're limited to only 8 different shades of grey. (including black & white) To be more exact, the allowed values are: 0, 36, 73, 109, 146, 182, 219 and 255. (multiply 0 to 7 with 2*(255/0xE) and then round it. Note that the N64 may display *slightly* different results) The "white (238)" pixels are converted to 0xD. 0xC for the color + 0x1 for the alpha, 0xF would be completely white, and 0xE would be transparent. The black pixels are converted to to 0x1. 0x0 for the color + 0x1 for the alpha, 0x0 would be transparent. In other words, the white pixels which had the value 238 now has the greyscale shade of 0xC when converted to IA4. 0xC*(255/0xE) becomes 219 when rounded. This is what causes the texture color to change so much. So the issue does not lie in the tool. It is simply the game that is limited to 8 shades, which appear to be quite different from what you expected. Though.. shouldn't 255 be closer to 238 than 219...? the tool does not seem to round to the closest color in this case. Anyway, the conversion itself is correct, but the part of my code that sets it to the closest available color seems be be slightly off. Could be a result of it rounding at multiple occassions. Edit3: Located the rounding issue. Basically It would round it to 0xD because that was the closest value. But 0xD is 0xC with alpha, as a result it would become 0xC. It now round to the closest color instead of the closest color+alpha value. (I simply have to divide it by 2, round, then multiply by 2 again) So that will be fixed in the next release. Going to look into the dialog background textures now. Edit4: The Sign & Ocarina backgrounds were set as i4 textures. They are actually ia4 textures. That's what caused the problem. The default & fading backgrounds were correctly set to i4. I was just dumb and assumed that they all used the same format. Edit5: There was an issue with the rgb5a1 import function that I've fixed. There was leftover code from when I thought the game used rgb5a3 which caused the color calculations to be inaccurate for pixels that were transparent. However, since it only affected transparent pixels, the problem wasn't anything that could be seen. The only way to see the issue was to look at the generated hex. Guess it's time to attempt fixing the firefox issue. Edit6: Well, that didn't take long. The very first thing I tried turned out to be the issue. So, basically this tool is based on my z64editor. And it contains a safety check so that if an image isn't loaded into the browser yet, it simply skip the conversion of that texture and then does the check every cycle until it is loaded, so that it can be converted. HOWEVER, this code is present in my tool, and is still set up exactly the same way. If the image isn't loaded into the browser, it is skipped. Problem is that my tool doesn't have a cycle or something so that it can just try again.. instead the image is just skipped entirely. So if the browser doesn't load the image in time, it will be skipped. I need to set it up so that it waits for each image to be loaded. I have a feeling that I will need to rewrite a big chunk of code. Unless I just add a new portion to the import that loops through every image of the pack and waits for all of them to be loaded. Edit7: I was wrong. It was very, VERY easy to solve the issue. I fixed the problem with a simple check. The import functions were already set up to return false if the texture wasn't loaded, so I just had to check if the return value is a boolean. (it returns true if the texture format isn't recognized) If it is false, the loop will simply check the same texture again until it is loaded by the browser. Seems like firefox simply was slower at loading the images, which is why it was most common on firefox. https://dl.dropboxusercontent.com/u/6440063/OoT/modding/texture_packer_fixed.png Current 2.3 changelog: Solved an issue that caused textures to not get imported if the browser didn't load them fast enough. If changes didn't apply when importing a pack before, it will most likely work now. Solved an issue that caused the ia4 importer to round the colors incorrectly in various situations. Solved an issue that caused the rgb5a1 importer to set colors incorrectly for transparent pixels. Updated two textures in the OoT Debug generator which were incorrectly set to i4 instead of ia4. The textures were sign_background and ocarina_background in the message_static folder. Going to do some more testing before uploading the new version, but I have been able to properly import my mods texture pack using firefox now, and judging from my console messages, everything works properly. Edit8: So, I decided to add a bunch of error catches and checks in my code, and add some proper console messages that tells you about them. Trying to prevent any kind of errors and crashes that can appear if you provide incorrectly formated things in a pack. Pointers outside of bounds, addresses outside of bounds, missing folder/file name parameters, etc. New changelog: Solved an issue that caused textures to not get imported if the browser didn't load them fast enough. If changes didn't apply when importing a pack before, it will most likely work now. Solved an issue that caused the ia4 importer to round the colors incorrectly in various situations. Solved an issue that caused the rgb5a1 importer to set colors incorrectly for transparent pixels. Updated two textures in the OoT Debug generator which were incorrectly set to i4 instead of ia4. The textures were sign_background and ocarina_background in the message_static folder. Incorrectly named folders and images as well as attempting to read/write outside the bounds of the ROM should no longer cause the tool to crash and instead provides an error message in the browser console. Edit9: Version 2.3 is out. You can use it online or download it on my website. 2.2 & 2.3 is *not* available on the-gcn. I will uplaod 2.3 when I'm certain that there aren't any serious issues in it.

Hotdogs. because it has dog in its name. and I don't like sandwich. Final Fantasy VII or Final Fantasy X?

Indeed. There are some clear limitations. You can see the result by importing a custom texture, then exporting it again using the texture packer. Due to these limitations, I made my best to have it set the colors to a *somewhat* good result. I prefer doing it this way over sending error messages saying that incorrect colors are used. I don't actually remember HOW I do this, but I believe it's some horrible method. Like, if you provide and RGBA image and import it as a greyscale alpha image, it'll just use the red channel for all 3 color channels. However, this doesn't seem to be what causes â–²ChriisTiianâ–²s problem. And if you do decide to look at the source code, I have to warn you that it isn't pretty. Since it was built on the texture feature from my z64editor, which was built to work with individual OoT Debug ROM files, and has been modified to instead work with entire ROM files, etc. So I made a messy code even messier. Not to mention that I learned lots of things will writing this tool, so it is probably extremely unoptimized. It is quite a mess, and not really something I'm proud of. I tried it out, and you're correct. the import of IA4 textures does not appear to be perfectly accurate. My guess is that it doesn't divide by the correct value, resulting in the colors being slightly darker than they should be. I'll sort it out for the next release. I'll take a look at the other formats as well to make sure that there isn't some issue with the divisions. And I'm glad to hear that the tool actually works after reinstalling the browser. So I guess it does work on up-to-date browsers. I didn't have time to look into the firefox issue today, but I'll probably do it tomorrow. If I can solve it, this may fix the issue in other browsers, without needing a reinstall, heh. Edit: Also, about things not working when entering 0x at the beginning of an address. The reason why it doesn't work is simple. It's an incorrect syntax. It doesn't recognize the first parameter of the file name, since it expect it to be 8 symbols long, and not have some kind of prefix. I COULD make it so that it regonize addresses prefixed with 0x as well, we'll see.

All browsers except Firefox works for me. I tried Chrome, Internet Explorer & Opera today to make sure. I do however keep my browsers up to date at all time, if that makes any difference. Internet Explorer is by far the slowest browser when it comes to importing textures. Like others have suggested, no changes seems to be applied when using firefox. That firefox doesn't work for me is actually a good thing. It means that it is a problem that seems to happen to everyone, which makes it easier for me to try and locate the problem. It is very possible that fixing it on firefox will also fix it in chrome for you. I will look into it later tonight if I have time.

It sure works for me. No problem at all. (put it over my mods ROM though, as I already had it right in front of me) So I guess that rules out there being a problem with the pack itself. It's either the ROM (I'm pretty sure this is not the case), or the browser (seems likely considering other have had the same problem with firefox). I am really starting to wonder why the textures aren't applied. Like.. this shouldn't be possible.. The ROM is provided and stored in a variable. This variable is being edited, and after a texture has been imported, it moves onto the next texture.. When all textures are added, the very same variable stored when dropping the files are used to then download the new ROM. So, the only possibility is that for some unknown reason, some browsers do not apply any changes at all, which is very, very, odd.

I have no idea at all how that can possibly happen. It works perfectly for me. And it worked on my laptop as well, so it's not like it's my computer that makes it magically work. I tried generating a new pack, changing one single texture, and then applying the pack again, and it sure did work for me. I've never had a problem with it in chrome. I just tried my local version, the online version, the offline version. I've applied 2 different packs to two different ROMs, they all worked perfectly. It's so weird that these issues happen.. because the tool is basically extracting and importing stuff the same way.. except in reverse... Why would it be able to extract but not import? The only thing I can think of is that you use some very old version of chrome or something, but shouldn't it cause an error if that's the case.. Another issue would be if you moved the files in the .zip pack or something. you have to place the texture folders within the /pack folder in the zip, and you can't place the files outside of the folders they were in originally, unless you create a new folder that points correctly. And you obviously have to keep the first 2 arguments in the texture filenames, or the tool won't have a clue as to where it is supposed to import the texture and just skip it.

Oh crap. I totally forgot about the Firefox issue. So the tool even has the false statement saying that it does work in firefox. Truth is, I only *fully* test the tool in chrome. Reason is because I use the tool every time I recombine my mod, and since chrome is my main browser, I use that for it. When I test the other browsers, I only make sure that no errors appear, and that a new file is generated and downloaded, I do not usually try them out. However, it seems to be a firefox exclusive issue, I will look into it later (possibly today) and see if I can solve the problem, as it is quite a serious one. This *should* be the only issue with the tool. I am not aware of any other, since I've resolved the issues related to the convertors I've written. Well, I am certain that there are other ways to cause the tool to throw exceptions, but as long as you do what you're supposed to (do not attempt to write past the boundary of a file, provide properly named files in the packs, etc.), that shouldn't be a problem.

Version 1.1 is now released. The patcher should no longer cause the browser to freeze when comparing two files. You can now provide multiple patch files at once by using .zip archives. Many new commands are now available, and other improvements have been made to the parser, such as support for tabs, comments at the end of lines, etc. You can read more about the new commands that are available here: http://cloudmodding.com/applications/rompatcher/patch_format.txt