Jason777

Hey all, it's been quite a while. I've generally only posted in topics related to modding, but (as anyone can tell) I haven't been around. It's always nice to know that this place is still here though. Anyhow, how's everybody doing right now? What're you up to in life? Anything you have to look forward to? Anything that's been bothering you?

 

As for me, I'm almost done acquiring my bachelor's degree in computer science (one more semester to go) so that's been taking up most of my time. Thankfully, my time in college has just gotten better and better and my future is looking brighter and brighter. I'm at the point to where I've just interviewed for my dream job and I may move to the one city that I've dreamed of living in since I was 12. It's funny, I only got into computer science because of this place and modding OoT in general. So, in a way, I kind of have everyone here to thank for how my life is turning out. Say what you will about the venomous and competitive nature that the modding "community" has always been haunted by, but it's what drove me to discover my passion for acquiring knowledge, reverse engineering, and programming. It's weird of me to post things like this, but I just really wanted to let everybody here know how thankful I am to have gotten meet you (either through collaboration, skype, IRC, etc.).

 

Seriously, thank you.

 

If I forget your name, you know that I mean you, too. Shout outs to: Flotonic, Vexiant, SanguinettiMods, !Tommy, Shade (Armos), SoulofDeity, xDaniel, spinout, Airikita, john_smith_account, Dark_Link-77, Xu Yuan (Three Pendants), Heavy1390, CDi-Fails, and Okami Amaterasu. Everyone

Shit.

 

Please don't play with me like this....

 

Do you have the reddit topic where he originally posted this?

Yes, when i get the thing a more bit complete, i can do that, also, i have send you about a long time ago a PM asking for a map render for the editor... -.-

That was email was a while back and pretty much forgot about it... Anyway, the sooner you get everything on GitHub, the sooner I can contribute.

Cool, having it on GitHub would make collaboration easier. Can you post the link here?

Well, you have to admit, if something as simple as a bit of text is already nearly identical in wording to that in another program, it's not much of a stretch to think that other parts of the program might have also been copied.

 

If you've really coded it all by yourself, then that's great! OoT/MM hacking could use some more, capable coders, and this is looking pretty nice

The only reason I can think of as to why the text is copied (other than plagiarism) may be that he no longer has to sit there and think of translating what he wants to say into English. ChriisTiian, do you mind putting up your source code on a version control website like GitHub, bitbucket, etc?

Good luck on your endeavors, JSA! If anybody can pull of getting a mod done it's you. Also, I don't know what all has been going on in your life lately, but I'm sorry that it's happening to you.

Oh definitely, that sounds useful. I was originally for that idea, but I didn't want the patch causing any conflicts with other mods that might have been placed in free space. Anyways, If you post it then I'll just modify the opening post to include a link to your patch as well.

Original topic: http://forums.zelda64.net/index/

 

 

I had noticed a lot of people were asking for the spider to be extracted from the original Izou Zelda mod and released as a standalone patch for people to use. I had worked pretty closely with Flotonic when making this enemy (I was in charge of practically all changes related to enemy AI and he was in charge of model/animation creation) so I knew what all needed to be ported.

 

Thankfully, none of the files that were modified exceeded the original file size. This makes thing quite easy for any modder who wants to use this enemy in without risking overwriting anything you have in free space. Enjoy!

 

Download the PPF patch

View detailed information about the Izou Zelda spider

 

As a note, this spider replaces the ReDead actor. As such, in order to use this enemy you must place actor 0x0090 on a map and ensure that object 0x0098 is loaded.

Actor and Object replacing empty slots (does not overwrite the ReDead actor):

Download Link:http://www.mediafire.com/download/f24reag96ume0zf/patch.ppf

When inserting into maps,

 

Actor ID: 0x3

Object ID: 0x4

 

The files are inserted into the actor table, the object table and the main file table.

They are located just after the final entry in the ROM.

 

If different offsets are needed, I can post another patch.

Looks excellent and definitely has my interest from here on out. Also, the Phantom Ganondorf replacement is a refreshing sight!

I know that Skelux's version of the Obj Importer has tools specifically for replacing the title screen. Take a look at the SM64 hacking subforum at SMWCentral: http://www.smwcentral.net/?p=viewforum&f=64

@@PwnzLPs, try learning C# (or UnityScript which I hear is very similar) or, as SoD suggested, a language like C++. Personally, I would start with C and then make a transition to C++ since it is literally an extension (for better or for worse) of C.

Ahh, no I made a mistake when advising how to check for it. What you should be doing is checking if ((*(u8*)(0x8015E6D0)) & 0x03) is equal to 0x03.

 

So you would change this...

 

andi k1, k1, 0003
bnel k1, r0, magic
lb k1, e693(k0)

To this...

 

andi k1, k1, 0003
ori t2, r0, 0003
bnel k1, t2, magic
lb k1, e693(k0)

Wario as a boss? Hell yes.

 

I've always wanted another Mario game where Wario plays an integral role in the story.

Nice one, for a second I thought it was a remake of TP's magic armor but then I realized that your hack takes its name seriously. Do you have the hack patched to the ROM?

 

EDIT: You should look into using bitwise operations. Usage of ANDI would have greatly reduced your code for checking if the Zora Tunic was equipped by simply checking if ((*(u8*)(0x8015E6D0)) & 0x03) was equal to 3. Also, I see that you handle the case where subtracting from the current magic amount avoids overflowing the byte value by just setting the magic value to 0 if it was less than or equal to 4; one instruction which would help you greatly would be the SLTI (Set on Less Than Immediate) opcode.

 

I know that you realize you code could be shorter, I'm just offering what I think to be helpful tips (I don't mean to come off as a nitpicker).

Whoever dumped it should have taken a screenshot of it running on real hardware

http://bsxproj.superfamicom.org/64dd/dump/NUD-EZLJ-JPN.zip

 

Start digging, I guess. Hope this isn't an April Fools' joke.

Hope this isn't an April Fools' joke.

April Fools' joke.

April Fools'

The date is too convenient to be a coincidence...

For some reason, comdlg32.ocx that Renegade came packaged with was considered a missing dependency and would terminate the application. I ended up using Galatea and got used to it. I did end up resolving the issue with Renegade, but I had already grown fond of Galatea by that point.

First off, this contains a lot of useful general RAM addresses and the structure of certain data within memory: http://spinout182.com/god/zelda64.h

 

Let me make a couple of comments about your hack:

• 0x80166AF0 is indeed one of the many valid controller data addresses so no need to worry about that.
• You are checking for to see if only D-pad up is pressed. You might want to AND the value in T2 with 0x0800 in order to check the bit.
• mzxrules made a very good point when he said that you may be corrupting all the registers because of the place that you have hooked into; try hooking into a function at the very end (temporary registers are no longer needed by this point) by replacing a jr ra to a jump to your code.
• SoulOfDeity may also be correct when he says the memory where you've placed your code may be invalid... Have you tried a different spot like 0x80600000? From 0x806000000 on is free RAM space till 0x80800000.

If it were me writing your hack, I would have written it like this (Renegade style)... 

.ORG 801064B0 ; This is the function return from WriteDCacheBackAll, if I remember correctly... this runs every frame
J 80600000 ; Jump to our hack

.ORG 80600000 ; Free space in RAM!
LUI T0, 8016
LH T0, E694(T0) ; Load rupee amount
LUI T2, 8016
LHU T2, 6AF0(T2) ; Load controller button input
ANDI T2, T2, 0800 ; Grab the bit corresponding to D-pad up to see if it is pressed; if it is then T2 will be nonzero
BNEL T2, R0, Exit ; If D-pad up is pressed then execute the delay slot before jumping to Exit 
ADDIU T0, T0, 0001 ; { Delay slot: increment rupee amount (only executed if the above statement is true) }

Exit:
LUI T2, 8016
JR RA ; Return (this will execute the delay slot (the instruction immediately below) before returning)
SH T0, E694(T2) ; Delay slot: Store potentially new rupee amount

GS code:

 

 

 

Also, you should try using Galatea to assemble your hacks. It worked fine for me on Windows Vista, 8, and 8.1. However, most other debugging tools that it includes do not work such as hooking in emulator process memory.

 

This might be a good reference for encoding instructions but I haven't looked over it too much. It seems to be accurate when encoding JAL instructions at the very least: http://www.mrc.uidaho.edu/mrc/people/jff/digital/MIPSir.html

 

If you wanna try to use Galatea to compile/assemble your hacks, make sure your assembly follows GNU syntax. Take a look at this hack I made as an example of how to write it: http://www.cs.utexas.edu/~jason777/Modding/Zelda%2064/Fire_Sword/Galatea_FireHack.S

 

EDIT: Updated the small rewrite I did to be assembled by Renegade64.

The shards were not made with hardware-compatibility in mind, I think.

NO, you can't, both converters have to convert each mesh differently. Map mesh and zobj mesh are NOT synonymous at all.

 

Huh, that's news to me. I'm just curious and maybe a little misinformed; how are they different besides what RAM segments they typically use? Do you mean to say that the "proper" order of F3DEX2 instructions seen in models tend to differ for maps?

 

Also, the source for Model2F3DEX2 was released. Actually, fkualol used Model2F3DEX2 to convert a display list to be used in a hardware compatible map for MM so that makes me think that Arcaith may be right when he suggests using that instead.

This has everything on the GBI: http://n64.icequake.net/doc/n64intro/kantan/step3/index9.html

 

This one seems to be slightly better: http://n64devkit.square7.ch/

 

Or maybe even this downloadable PDF: http://www.jax184.com/projects/ultra64/Nintendo%20Ultra64%20Programming%20Manual+Addendums.pdf

 

Shit, man: http://level42.ca/projects/ultra64/Documentation/man/n64man/tools/gbi.html

 

Plus, if you have an N64 SDK, you can just peek at gbi.h.

 

But here's a port someone made in C++: https://github.com/emudeveloper/N64-Player--Mupen64plus-/blob/master/main/jni/gles2n64/src/GBI.h

If anyone else still needs help... https://www.the-gcn.com/topic/2078-zao-add-z64-automated-actor-and-object-adder/

 

The program takes of everything automatically.

EDIT:

New patch that allows cutscene values to specified in the Z-rotation: http://www.cs.utexas.edu/~jason777/Modding/Zelda%2064/warp_exit/warp_exit_v2.ppf

Notes and relevant data have been updated: http://www.cs.utexas.edu/~jason777/Modding/Zelda%2064/warp_exit/

 

I just exchanged some messages with Airikita briefly, and we extended the hack to where it reads cutscene values from the Z-rotation.

 

Apply the original patch and then write these next changes to the ROM:

 

@ 0x00D531D4 in ROM write...

10 00 00 2C

@ 0x00D531EC in ROM write...

10 00 00 26

@ 0x00D53244 in ROM write...

10 00 00 10

@ 0x00D5325C in ROM write...

10 00 00 0A

@ 0x00D53264 in ROM write...

86 2F 00 B8
14 22 00 03
86 38 00 B6
24 18 01 0E
24 0F 00 00
3C 01 80 22
A4 38 3E 3A
3C 01 80 16
A4 2F FA 72
3C 04 80 9A

A patch will be made if you all really need it.

I think 0x03 is for backface culling and 0xFC is for modifying combiner settings.

The tutorial haddockd linked to should explain everything that you would need to know.

 

Just keep an eye out for hacks that utilize memory at 0x80600000; those are not patchable unless I rewrite where the routine is loaded.