Jason777

What are you using to generate collision? I assume it's not a huge problem with the display lists considering you're using xDaniel's Model2N64 command-line tool...

It would be cool to dive into Unity using this project as a playground...

Instead of replacing the old map file with the new one, you take the display list(s) within the new map and overwrite the old map's display lists. Same thing goes for map collision.

Warning: I have not yet tested this method, but, in theory, it should work just fine. â–²ChriisTiianâ–² asked me how to use this a couple of days ago. I figured I might give a little mini-tutorial on how to patch GS codes. Keep in mind that once my program is complete, this won't be the way things are done: I'd imagine it would get quite tedious when patching long GS codes so I think I'll cook up a quick program later today that takes a text file of GS codes and spits out a binary that is ready to be placed at 0x036000FC. EDIT: According to â–²ChriisTiianâ–², the method is a success!!

I look forward to this. It's always nice seeing something that's hardware compatible

The contents of the folder are absolutely fantastic! It's a shame that your project fell through, but I thank you for releasing the source.

Geez, you must have showcased around 30 different levels so far... what's the status concerning completion?

How big do dungeons have to be (i.e. number of rooms)? I have a mostly complete custom mini-dungeon (5 rooms total) that I'd be willing to submit. Also, no one here is an expert at map making but I would tweak the scaling down for some of the maps and increase texture dimensions so that you don't have too much repetition on a single surface. EDIT: Check your PMs, JSA.

I really need to start working on that gameshark code patcher... I've had university-sponsered research keeping me busy this summer.

Fuck modding, right? Seriously, awesome job.

Mmmm, yummy source code... Yay, it's in C too! Great job on the program, man

Tell me, how difficult is it to work with Unity?

I'm thinking we should make a general custom item or ASM thread -- those are the things I look forward to seeing the most of and this mod is full of em'.

https://www.the-gcn.com/topic/3026-water-animation-generic-texture-transition/?do=findComment&comment=47700 That thread seems to have all the information and links to all other threads that contain information so far.

This documents how playing SFX work in audio debug: http://www.cs.utexas.edu/~jason777/Izou_Zelda/Misc/Hacking%20Notes/Audio_Debug_PlaySound_800F2C34_800F2CA8.txt According to my notes, SFX numbers are decided like this: ((SE HD << 12) + SE No. + 0x0800) & 0xFFFFRelevant RAM Addresses found on: http://www.cs.utexas.edu/~jason777/Izou_Zelda/Misc/Misc_NOTES.txt 80210B2C 0001 - Audio Debug Enabler 80131F20 (Audio Debug - SE Parameter Change) 0x0 (2 bytes) - SE HD 0x2 (2 bytes) - SE No. external_func_800F738C(u16 sfx_id, void * a1, u16 a2) // "PlaySound" used by Audio Debug external_func_8002F828(u16 sfx_id, void * actor) // PlaySound used by regular actors (wrapper for 800F738C) external_func_8002F7DC(u16 sfx_id, void * actor) // PlaySound used by Link (wrapper for 800F738C) 8016BAB8 - Controller 4 Buttons (Audio Debug Input)

Oh damn. Them memory leaks... Or is it supposed to be that demanding on memory?

What would the tutorials consist of? I.e. how would it be broken down into parts? I could seriously throw something together on Sunday. Beginner Tutorials: Part 1: Getting All The Necessary Tools Part 2: Familiarizing Yourself With SketchUp Part 3: Compatibility With Textures Part 4: Choose Your Poison (Injecting With Tools) Advanced Tutorials:Part 1: Texture Tricks Part 2: Organic Modelling With Sandbox Part 3: Converting Display Lists Part 4: Exporting/Importing Original Maps as OBJ Part 5: Making Hardware Compatible Maps Tool Specific Tutorials:Part 1: SharpOcarina Part 2: Hylian Toolbox Part 3: Obj2Area Part 4: Model2N64 Part 5: ObjN64Tool Part 6: Z64Anim EDIT: xDaniel, which do you think is better to use for display list generation? SharpOcarina or Model2N64? Strictly speaking on the output, of course -- not the usage of the program.

I'm mostly aware of how the damage chart works; I had, however forgotten that there were separate entries for different sword's and their spin attack (oh well, less checks!). The point was so that you wouldn't have to go modify each actor's damage table in ROM. I'm a little confused. What way were you proposing to add the fire/ice effect to the Biggoron's Sword replacement?

Taking advantage of damage table pointers in RAM actor instances should help you greatly instead of going through each individual actor modifying the damage tables in ROM. You can find the damage table pointers located 0x98 bytes away from the start of the RAM actor. Here's a little hack that added the flame effect to the Biggoron's sword slash attack (GNU-style to work with Galatea): http://pastebin.com/s046hj7b RAM addresses used: 0x80213C50 : list of currently used actors 0x80213C50 + 0x28 : number of currently loaded "enemy" actors 0x80213C50 + 0x2C : pointer to first loaded "enemy" actor RAM Actor + 0x98 : pointer to actor's damage table RAM Actor + 0x124 : pointer to next actor in the same category Damage Table + 0x11 : Fire Arrow entry (turns out it's not needed) Damage Table + 0x0A : Biggoron Sword Entry Damage Table Entry & 0xF0 : Effect (split into bits) Damage Table Entry & 0x0F : Damage Using that hack as a reference (my hook is crap though), it shouldn't be hard to detect the sword currently in use and modify damage table entries for strong and weak spin attack accordingly.

Something that people should be aware of when following your tutorial is signedness in assembly. Thankfully, when setting that scene/entrance table offsets, you used ORI for the lower 16 bits which interprets the value given as unsigned. However, the ADDIU to set the lengths of the scene/entrance table, if given values after 0x7FFF, will be a negative number and result in FFFF being placed in the upper 16 bits of the register. Perhaps an ORI should be used in place of the ADDIU. Nonetheless, great job! EDIT: Not that anyone would use that many scenes... just food for thought, I guess.

Nice one. Did you find that code by yourself or were you using spinout's hack as a reference?

Exactly. However, if you wanted to make "new" animations for textures to use, DB commands would be the way to go. The only part where I'm a little stuck is the placement of the DE command in relation to other commands in the display list.

From what I remember, you can set RAM segments up with DB commands (though one commonly uses "DB06"). You can find more information about it in the z64-tex-ext hack made by spinout. It also makes much use of segment table at 0x80166FA8, the current display list command pointer at z_ctxt + 0x2C0 (0x802122E0), and the other z_ctxt + 0x2D0 (0x802122F0) where z_ctxt is 0x80212020. Although z64-tex-ext does successfully implement an animated texture hack, I wouldn't recommend using it because it isn't too flexible; you can't have multiple animating textures in the same map using the hack and you are limited to using only a single texture. Also, from my experience with writing an automated tool that compiles, modifies, and inserts the hack for you, it doesn't work reliably with all maps. However, the hack is a great thing to study concerning the subject of animated textures. Links of interest: z64-tex-ext: https://bitbucket.org/ottehr/z64-tex-ext/wiki/Home Look specifically at the functions "set_segment" and "dl_write" contained within this source file -- they setup RAM segments by adding display list commands: https://bitbucket.org/ottehr/z64-tex-ext/src/f4efd2eb0fc098185c029a787ce47b97bcb3be67/run_code/run_code.c?at=default Some information on DB commands: https://www.the-gcn.com/topic/1089-would-it-be-possible-to/ A long time ago, I had asked Flotonic how he got animated textures working in custom maps. I would have to dig up the old chat log (I know I still have it), but the gist of it was... Replace a scene that already had animated textures (this was probably done so that the original scene configuration as scene in the scene table would still have references to the animation code) Make the texture you want to replace part of an entirely separate display list... try placing the display list at the end of the map file so you can make modifications/insertions without disturbing other pointers within the map Insert a "DE 00 00 00 XX 00 00 00" where XX is a RAM segment 08+ somewhere after a definition of the texture. You might have to play around with the values in order to get it working Any other information is probably linked to by xdaniel in the other topic you made about animated textures. EDIT: Also, if you're trying to find special graphical effects in actors, I would recommend looking for instructions that utilize z_ctxt or contain opcodes like "lui 0xDB06" or "lui 0xDE00", etc. EDIT2: Not much else and I'm sure you're well aware of this topic... but just in case: https://www.the-gcn.com/topic/2883-water-animation-mystery-solved/

What happened to the chainchomp?

Nice job! I wonder, is there any documentation on how the camera switches between the different VR images? I would think it has to do with collision data.