Jason777

I'm liking the tutorials thus so far, but I have one thing that you should probably change Actor - the code or AI for the enemy, NPC, tree, rock, or basically the model. Variable - These vary between actors. It is used the specify the attributes of that particular actor, such as whether it is invisible, small, mini-boss, etc. Group/Object - The actual model and (usually) animations of the enemy, NPC, tree, rock, or any other type of actor. Only one object is needed to be loaded if there is more than one actor that uses it. Basically, the game loads the object into a segment (just think of it as general storage in which all the actors that use that object have access to) then whenever an actor needs some model data or animation, it grabs from the loaded model and uses it to fulfil it's physical or visible needs. So let's say you wanted three Stalfos; you would place three Stalfos actors and one Stalfos object, not three Stalfos objects and one Stalfos actor.

Nah, my program only adds objects and/or actors and places them at coordinates of (0, 0, 0) with an actor # of 0x0008 and a variable # of 0x000C. I think it would be redundant to write another actor placement tool... Well, it is preferred that you use it with SayakGL or OZMAV, but I'm about 99% sure that you can use it with UoT, ZAP, or ZLE since I don't see any reason why it wouldn't work

ZAO-ADD (v1.1) Download: http://www.mediafire.com/?8c3umdr9ptqbs1y ^^ Use WinRAR or 7-Zip to extract I believe I've taken out most of the bugs present in the initial release. You're able to specify whether or not you would like to update the file table pointer if possible (since that can lead to bugs). It automatically updates the ROM CRC if you choose to update the file table pointer. You can specify what object values to add. It gives all default added actors the value of "Magenta Flame". Things that are going to be present in the next release:The ability to navigate and add actors/objects to alternate map headers. Addition of 0x01 or 0x0B commands if they aren't present in the map header. Once I'm finished implementing everything that I had hoped to have in this program, I'll turn it into a JAVA GUI to make it look cleaner and less intimidating Oh yeah, I've decided that I won't be releasing the updated source code until the final release.

Alright, guys, I've spent a good amount of time trying to sniff out all the problems (why it only works with one level like Sutaru and not one like Hyrule Field, why the Z-buffer is all messed up if you load the map right away without changes, why the game crashes immediately upon loading if you make any changes to Hyrule Field, why fixing file table pointers was a dumb idea, etc)... And I believe I have worked them all out! I basically spent the day conducting manual tests on maps like Hyrule Field, Gerudo Valley, and Lost Woods in order to see what I was doing wrong... I found out that it was a problem with what the program wasn't coded to do! Basically, I neglected situations that might arise such as a map having alternate headers whose actor or object list pointers point to the (now empty space; 0x00) original actor/object list or the fact that having object repeats can lead to crashing. You should be a expecting a proper update either tomorrow or saturday where I address a lot of issues.

Did you make sure to fix the ROM CRC? I imagine you're trying to use PJ64 as emulator. If you don't want to bother with that then you'll have to use nemu64. The game seems to like throwing curve balls, eh? I should probably make sure the program pauses before closing when encountering an error, huh... You could always manually define an injection offset (0x35CE040 will do). Once I finally do get home I'll get to work on it right away. Man! I was so sure that the program didn't have any bugs when I first released! It's kind of embarrassing to find out immediately afterwards that there seems to be problems... lol. An update where I remove the file table pointer fixing is definitely coming soon. Thinking of it now... it was probably a dumb idea to have put into the program.

Giadrosich, try running the program in detailed/verbose mode, type in "81" (not "081") as the scene and then take a picture of the program's output up until the map choice. I'm going to see if it grabs the data correctly. If anything, I'll go home after class today and look at the program's source and play around wth Hyrule Field myself.

Knowing what room to select would require knowledge on the user's end. However, Hyrule Field has 17 maps? 0.o That's new... I'll look into that later today after school. And don't worry about asking too many questions- I want to get this program to a state where you can use it without complications!And thanks, Three_Pendants! I'll probably be updating it later today to help with the things giadrosich is having trouble with.

Yeah, the other Link is the default actor whenever it adds on to the actor list... I should probably change that to avoid Z-buffer issues. And in the other case, scene 81, you just tried adding 2 new objects or actors? I can find out what's going on right away. Heh, I knew I was forgetting about something... Alternate headers and the default actor number/variable!

You're aware of chest flags right? I'm about 99% sure that's in an issue with the chest flags... but you say that you started a fresh file... You should probably check it out: http://wiki.spinout182.com/w/Modification_and_Addition_of_Switches#Chest_Flags

Currently only for OoT Debug ROM Tested using Nemu64 and PJ64 Okay, I tried to make this tool as noob-friendly as possible! Let me give you a run down of what this program does... I think it's safe to assume that every has needed to add a few more actors of objects to a map file but just couldn't get the hang of any tutorials. Well, this tool completely obliterates the need to learn those tutorials and even the need to know how to inject the map file into the ROM. Basically, it does everything for you without you even needing to know anything about the format of the map file, how to fix pointers for the actor list, or where free space in the ROM is. Everything is done for you. List of features: The ability to add actors or objects to a map file The ability to automatically search for free space in the ROM If you don't trust the automated space-finder, you can manually define the injection offset The ability to automatically inject and fix all pointers pertaining to the map file The ability to choose between verbose and non-verbose "modes" Writes important data concerning the modified map file to a DAT document Possible Bugs: If the map doesn't contain a 0x01 or 0x0B header command I haven't added any code to insert a new command; the program just closes. The automatic free space finder isn't terribly thorough or advanced. It looks for the highest offset found after searching through the scene table, actor table, object table, and general file table; it doesn't try to "squeeze" the map file between other files if there is enough space. Even though the though ROM doesn't need it, it updates the file table with a new pointer to the map file. I can see that this may lead to issues if someone tries to compress the ROM since I seriously doubt that the "virtual offsets" and the "physical offsets" should be the same. I wouldn't recommend choosing the automated injection offset finder if you happen to have ASM hacks laying around in the ROM after 0x35CE040. NOOBS: If you don't like a bunch of information spewing on your computer screen, I would recommend running the program in non-verbose mode. You would do this by typing 'n' when the program asks you "Do you want program's output to be detailed? (y / n) : ". I included a verbose mode for people who want to see if the program is grabbing information correctly or to learn just exactly what is going while we modify the map file. It's useful for finding errors/debugging. Also, the program creates a DAT file after it's done making changes to the ROM to let you know where the map file is in the ROM and what space is now free for general use. The only thing that the user is required to do besides input in the program is to go fix the CRC of the ROM afterwards if you want to use it in an emulator like PJ64 and to specify the actor number, variable, XYZ position, and XYZ rotation using a program like SayakaGL or Utility of Time. Anyways, here we go! Downloads! (v1.0) Downlaod: http://www.mediafire.com/?p6f2ei616bz11me (v1.0) Source (Developed with Code::Blocks): http://www.mediafire.com/?ghd5jyrgfmeiffy (v1.1) Download: http://www.mediafire.com/?8c3umdr9ptqbs1y (v1.2) Download: http://www.mediafire.com/?0zpncm2ll7bwey8 ZAO-ADD v1.3 Download: http://www.mediafire.com/download/xew8rgxrcjcdbzp/ZAO-ADD_(v1.3).zip ZAO-ADD v1.3 Source: http://www.mediafire.com/download/bd43ybd41dnk11d/ZAO-ADD_(v1.3)_Source.zip ^^ WinRAR or 7-Zip to extract Possible Future Updates: Add in code to add 0x01 or 0x0B commands if they aren't present in the map file. Be able to go into alternate map headers. Automatic CRC recalculation. Possible removal of the file table pointer fixing if it causes people too much trouble. Possibly make a Java GUI for the program and have detailed data be displayed on a seperate console window. This will be a seperate GUI from haddockd's that I will personally develop. Update log: Sunday, March 03, 2013 Saturday, April 27, 2013 Friday, July 19, 2013

I'm curious, what would be the purpose?

First columns and the eighth column. I totally understand what experienced people mean when they say that it's no longer easy to explain things in simple manner for newbies. You know what? I should probably make a video on this if you're still having trouble.

Well, there's only one 0x15 command per scene header. The arguments of some commands could even contain the value ot 0x15... That's why look for a 0x15 after every 8 bytes. After the header there could be any number of occurences of 0x15. The 0x14 command signals the end of the header. For more commands, follow the link I posted awhile back. Here's another tutorial that a friend made if you don't quite understand me: https://sites.google.com/site/flotonic65/modding/n64zeldatut/mc

"0x" is a prefix to tell you that it's a hexidecimal number I could just write "15 in hex" but I prefer to just put that prefix. 0x15 = 15 in hexidecimal. Basically, I'm telling you to look for a 15 after every 8 bytes with the beginning of the file being where you should start at. You would go like this... "Is the first byte (offset 0x0) 15? Nope." "Is the the ninth byte (offset 0x8) 15? Nope." "Is the seventeenth byte (offset 0x10) 15? Nope." "Is the twentyfifth byte (offset 0x18) 15? Yes!" Because every command is 8 bytes long, you would look at the first value of every 8 bytes. If that value is 14 then you've reached the end of the scene header.

Skyward Sword Link.

Alrighty, I guess this is where you should probably get acquainted with the format of maps and scenes. Back when haddockd gave those little tips he didn't exactly know about the formats and the scene/map "header commands"... so I'm guessing that you're probably modifying the wrong things. Visit this page and follow along with everything that I'm saying: http://wiki.spinout182.com/w/Maps_and_Scenes To start with, open up your scene file in a hex editor. We'll be looking for the 0x15 scene header command. The thing about scene/map header commands is that they are always 8 bytes in length. So you'll want to scan the beginning of the scene file for a 0x15 every 8 bytes. If you encounter a 0x14 on one of those bytes then you've gone too far. You should be able to find a 0x15 command since scenes are required to have a music command to even be playable. Once you find it we'll change the track number. Every scene/map header command contains their own different "parameters" or "arguments". In the case of the 0x15 music command, this is it's layout: 15 XX 00000000 YY ZZXX - ReverbYY - Playback optionsZZ - track numberWe'll only be wanting to pay attention to the "ZZ" argument of the 0x15 command (located 7 bytes away from the 0x15). Changing that part to the desired track number should be all that is needed. Remember that everything is in hexidecimal. Now do this for every scene header in the scene file.

Malon. I don't really approve of crossing species...

Sweetness. I'm curious, is the double Helix sword considered an "item" in these tables?

Looks pretty good! I like the things you did with Lon Lon Ranch.

Well from reading your reply it seems you're already headed in a good direction; not only do you have manual text editting, actor placement, and exit modifications down, you also have basic puzzle implementation worked out (clear triggers). You would be surprised when I say that you don't see a lot of people creating event triggered areas. Kudos. Also, knowing the format of map/scene files will take you a long way: http://wiki.spinout182.com/w/Maps_and_Scenes

I'm pretty sure I wrote a little mini-tutorial on this... Thankfully, I remember where I posted it. Keep in mind that I wrote it in about a couple of minutes so it's not too detailed: Original post: http://glitchkill.proboards.com/index.cgi?action=display&board=mod34&thread=5139&page=2#50163 Also, I guess the point that haddockd is trying to make when he says "To be honest you are going to have to experiment and do some leg work for yourself. The "step by step or I won't get it" mentality wont get you far in the modding game." is that you won't be able to advance to the areas of hacking where nobody is really able to teach you anything if you keep asking for help on everything. I'm not trying to sound harsh at all, I'm just trying to see the truth behind what he says. By looking at all the documentation on the Z64 Wiki you should be able to piece together things that should be changed when you're trying to modify i.e. exits, entrances, or the exit table. It is good to understand what all is going on and what all is happening by experimenting yourself. It is important to know why you have to change certain things.

Why don't you try to make permanent textures instead of hi-res texture packs? Besides that, he looks pretty slick.

What's the difference between RAM offsets for the Debug ROM and USA v1.0? I know conversion doesn't work in most cases but I've found a GS code for the Debug ROM that has information on everything I need to write the actor.

Hmmm... so you want an actor to load up the boss room instead of the collision polygon type? I'm pretty sure I could write something like that for you in a matter of minutes but first I would have to test out a few functions. If you look at the RAM Map in the Wiki there is a function that spawns a scene; I would be testing that function out as well as finding it in 1.0.

The Battleaxe is looking awesome.