Jason777

A newer version of spinout's OBJ importer is OBJN64Tool. Perhaps you should try using that instead of wotf. You can find it here: http://wiki.spinout182.com/w/Libobj

I don't know if anybody has noticed, but version 1.4 has been released (for over a week now). Video Download Link http://www.maco64.com/download_page.php?download=2

Lol... I have it. I also have the source code for MMMusic2OoT. I'll be uploading it shortly. EDIT: Here you are... "zis.exe" is included within the zip file. I would upload the source but I'm not sure if sanguinetti would approve; you'll have to ask his permission for that. Anyways: download

I have never heard of it...

C or C++ would be a good language choice.

Petrie911: http://glitchkill.proboards.com/index.cgi?action=gotopost&board=ootmod&thread=2568&post=41198 You can find some more things on free space on that last few pages of this topic: http://glitchkill.proboards.com/index.cgi?board=ootmod&action=display&thread=2568

Nice job with the release haddockd! This will definitely be of great use to noobies. Hopefully we'll see decline in the amount of pointless "Q&A" topics that ask for things such as "Where do I get [insert program name here]"

Nice! I'm curious as to how you find some of these RAM addresses.

Ahhh, I thought you were talking about regular cutscenes. I did not take into mind that you were talking about the introductory cutscenes for dungeons. Now that I think about... the same thing may be applicable for boss actors.

Cutscenes are part of alternate scene headers and are pointed to by the 0x17 header command.

Try removing the check and see what happens.

http://wiki.spinout182.com/w/Code_notes

I just noticed the trailer, giadrosich. Well done! The music really adds to the overall excitement

Why not post a video of everything you do when you're making the modifications and then we try to see what you're doing wrong?

UoT assumes that an occurence of an E7 command is the start of a display list. While this logic may work for some, it will not work for all display lists; 0x2CB48 is the true start of the display list.

You're only supposed to be changing the object table pointers; file table pointers are a no-no (leave them as they originally were).

This is going to be really useful to Project Antiqua Thanks for the info!

Hex editting would be unreasonable to do advanced hacking. If anything, hex editting is used for the simpler things. To start advanced hacking, you would use tools such as disassemblers/assemblers, compilers, and debuggers such as the one built into nemu64. It takes a long time to get the hang of.

Airikita, you only need to change the pointers to object_link_child and object_link_boy in the object table. Right now you're modifying the file table pointers. Object Table Code Notes - Object Table A quick way to get to the object table pointer for a ZOBJ on an unmodified ROM would be to look for the start and end offsets of the ZOBJ as a hex string and land on the second occurance from the start of the ROM.

If you guys can locate those offsets in the RAM, I could do a hack similar to the one I made for Young Link being able to use the bow.

Think of things you know are possible with the tools available. Don't be thinking about all new items or enemies as that requires C/ASM hacking. You can replace the models for enemies and items, sure, but you can't change their general function without getting into some really advanced hacking. The only errors that people tend to run into when they're only replacing models/maps are problems with event triggers/flags, exits, and cutscenes.

The gameshark code that DeathBasket is talking about is this: 8015E69E 0001... However, I want to be able to just get the Biggoron's Sword out of a chest. I actually think I can make a hack to do that without having to track down that flag which tells whether or not you have completed the quest. I'll try writing it tonight.

There's probably a flag that tells whether or not you've done the trade quest. I'm having the issue, too, so I'll probably end up trying to track that flag down.

How do these sound as arguments for ZAO-ADD, haddockd? ZAO-ADD.exe [ARGUMENTS] -s [sCENE NUMBER] : Specify a scene number (if used as the only argument, it'll return the number of maps as a string) -m [MAP NUMBER] : Specify a map number and doesn't return anything if it is the last argument (use in conjunction with -s) -a : Returns the amount of actors in the specified map as a string (use in conjuction with -s and -m) -o : Returns the amount of objects in the specified map as a string (use in conjunction with -s and -m) -aa [ACTOR ADD] : Specify the amount of actors to add (use in conjunction with -s and -m) -ao [OBJECT ADD] : Specify the amount of objects to add (use in conjunction with -s and -m) -off [OFFSET] : Manually specify an offset to inject at (use in conjunction with -s, -m, and -aa/-ao) -ft : Try to fix file table offsets if possible (use in conjunction with -s, -m, -aa/-ao, and/or -off). For example, say you wanted to find out how many maps were in scene 109: ZAO-ADD.exe -s 109 Say you wanted to find out how many actors were in scene 109 map 0 (the same could be applied for objects using the -o argument): ZAO-ADD.exe -s 109 -m 0 -a Say you wanted to add 2 actors to the actor list in scene 109 map 0 (the same could be applied for objects using the -ao argument): ZAO-ADD.exe -s 109 -m 0 -aa 2 Say you wanted to add 2 actors to the actor list in scene 109 map 0 and inject the map at 0x35CE040: ZAO-ADD.exe -s 109 -m 0 -aa 2 -off 0x35CE040 Say you wanted to try to fix the file table entry as well: ZAO-ADD.exe -s 109 -m 0 -aa 2 -off 0x35CE040 -ft How does that sound, haddockd? You could take the strings that program returns to set up bounds of some sort in your GUI.

Hmmm... I'm guessing it's trying to load a file from the "relative root" like you were talking about in your program thread?