by Psi-Hate at 12-11-2017, 02:31 AM
This mod allows up to 4 Links to solve a series of dungeons. The dungeons are themed like the original 3 dungeons of OoT. First is the Deku Tree, then Dodongo's Cavern, then the Ice Cavern. 
You start out in a hub area. The 2nd and 3rd dungeons are blocked off, requiring items that you get in the previous dungeon to obtain access to them. 

This mod is not hardware compatible, but for wiiu/emulators, it is compatible. (Emulator MUST be NEMU or PJ64 1.7!!)
The download for the full package lies in the description of the trailer (includes Rom and Emulator).

MAKE SURE TO DELETE ANY PREVIOUS SAVE DATA BEFORE PLAYING FOR THE FIRST TIME!


Screenshots

Trailer:




Credits:
Psi-Hate - Maps, planning, editing, etc
MelonSpeedruns - Maps, Camera, importing, etc
z64offline - Hub concept
TyroneAnderson - Ideas and Help
ThreePendants: Exits and stuff
Spinout182: Four Swords Mod
JMan: GS codes
by Psi-Hate at 12-11-2017, 02:14 AM
Modifying the entrance table is a must when connecting your new (or even just modified) world together. Without editing the entrance table to abide by your changes, you won't be able to connect your maps and spawns the way you want. 

Explanation

The entrance table can be thought of as a big list of all possible locations that Link can spawn at; it also controls certain aspects of map transitioning.

Every scene has at least four entrances per spawn: young!day, young!night, adult!day, adult!night
This is because every single scene has at least four states, corresponding individually to the time and age of Link. Some scenes have more entrances because of cutscenes.

Below is an example of an entrance:

"01 00 41 02"

Every entrance is formatted like so:
Code:
XX YY ZZZZ

Where XX = Scene || YY = Spawn/Entrance ||  ZZZZ = Variable

So for example...

[Image: B0xEwPr.png]

"3B" being the scene number in hexadecimal, "01" being the spawn, "4102" being a bitpacked variable.

Bitpacking means that a variable is made up of smaller variables that are only a few bits long. These are packed into one variable which is represented in hex.

Each entrance can be represented by an index. Think of an index as the position of an entry in the entrance list. All indices are in hexadecimal, meaning the first entry would be "0000", and the tenth entry, for example, would be "000A". 

How-To

The Entrance Table starts at 0x00B9F360 within the ROM.

1. Take the scene you want to create a entrance for, and convert it's scene number from decimal to hexadecimal (for example: scene 108 would translate to 6C in hex)

2. Write "XX YY ZZZZ" (inserting your own values into the placeholders), making sure to write it 4 times total for each spawn.
(for example: lets say we are exiting from fishing pond and are entering the first spawn of our custom map injected to scene 108, we'll write "6C 00 41 02" and write it a total of 4 times down the line).

3. Since you now have edited your entrance table to whatever extent, you'll need to edit your scene to accommodate these changes. Edit the scene's exit list and write the index of your entrance, making sure the order of exits in polygon types correspond to the order of indices in the exit list. For example, a polygon type with exit 04 would correspond to the fourth index in the exit list. 

Example

4. Review and think through your work. You should be able to look at the entrance table you made and figure out what the destination is and where specifically it'll take you within the scene. Make sure you don't get anything mixed up as it's a hassle to debug, so keep track of every edit you do.


That's about it!
by Psi-Hate at 12-10-2017, 11:38 PM
The default camera angle of a scene is a third-person behind-the-shoulder view.  The current tools out there don't allow you to easily change the camera settings, so you'll need to use a hex editor. This can be a bit difficult if you're not sure what you're doing. 

Do not fear, for I am here!... to write tutorials of course!

Anyway, let's get to business.

Explanation

On CloudModdingWiki, there is a page over the scene format in which there's a camera function that you'll be able to manipulate using the criteria and documentation listed there. For those who aren't familiar, I'll be showing the process and explaining what each important detail is.

1. Find the 0x03 scene header command in your scene file (Search "03000000"). This points collision header. 

2. The 0x03 command begins with  0x03 (sets up the command and tells the game this will point to the collision header), followed by three bytes of padding (useless 0s), and ends with a four byte segment address. The segment address is what the game will be reading to find where the collision header is located.

Segment addresses have two parts: a segment ID and an offset. The segment ID references a table of start addresses kept track of by the CPU, usually corresponding to important files in memory. The offset is then relative to these start addresses. There are 16 segment IDs in total. 

Segment Address Table

For example: "0x02000069" has a segment ID of 0x02 and an offset of 0x69. This means that the game will jump to the start of the current scene (Segment ID 0x02 = Current Scene) and move 0x69 bytes forward. It will then read data from there on. 

Knowing this, go to the segment address defined in the 0x03 command.

3. After you go to the specified offset, you'll find the collision header. It is formatted like so:
Code:
bbbbcccc ddddeeee ffffgggg vvvv0000
aaaaaaaa pppp0000 llllllll tttttttt
xxxxxxxx wwww0000 mmmmmmmm

This is what it may look like in the file:

[Image: ViRvjRJ.png]

"xxxxxxxx" is the segment address for where the camera variable is set. 

4. The segment ID in the picture above would be 0x02, and the offset would be 0xC770. This means that we must go to that offset and write the camera option that we want. There are many undocumented camera options, so in the future this tutorial will be updated with a more comprehensive list. However, here are some currently discovered options: 

Camera Options
 
That's about it! Here's a basic rundown: 

1. Open the scenefile in [Preferred Hex Editor]
2. Search for "03000000"
3. Find "0200xxxx"
4. Copy xxxx and go to that offset
5. Find "0200yyyy"
6. Copy yyyy and go to that offset
7. Write the camera variable you want set
8. ???
9. Profit!
by aroenai at 12-10-2017, 09:53 PM
Mirror download links for a few programs:

Wareya's ndec program (properly handles MM):
http://www.mediafire.com/file/od4y72l0r57d7tl/newdec.7z

Usage (command line):
ndec [input rom.z64] [output rom.z64] /clean


Zoinkity's Aegh rom compressor:
http://www.mediafire.com/file/5o97uendasqtusy/Aegh.7z

Usage (GUI):
Open an original compressed retail rom and use the Export Table function. Use ndec to decompress the rom, make your changes. When you're ready to re-compress your rom, open the decompressed retail rom, select Open Exception Table and select the file you created previously. Click compress and wait.

Exception table for the OoT Debug rom:

Code:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 942, 944, 946, 948, 950, 952, 954, 956, 958, 960, 962, 964, 966, 968, 970, 972, 974, 976, 978, 980, 982, 984, 986, 988, 990, 992, 994, 996, 998, 1000, 1002, 1004]


rn64crc2:
http://www.mediafire.com/file/towca6keik...64crc2.zip

Usage (command line):
rn64crc2.exe [input rom.z64] -u
by Nokaubure at 12-10-2017, 09:34 PM
If you don't already know, SharpOcarina is an application made by xdaniel in 2011/2012 to create custom maps for OoT. I resurrected the project by bringing 0.70-0.93 versions with big improvements.

So, after a long waiting I'm glad to release 0.93 version!

Download (+ source): Here


Sadly, I had to cut cutscene editor from this version, but don't worry you will see it in the future!


[Image: 2xCMqa6.png]
More images:

show

[Image: btn_donate_LG.gif]

Changelog 0.93

Improvements and new stuff

- Now you can use vertex color and transparency at the same time

- More types of animation are now available. Do note that SO will force the mesh to follow the rules of the selected animation no matter 
what you choose, for example if you assign an opaque texture animation to a transparent mesh, it will become opaque.

- Addded a checkbox to enable continual inject (will make SO behave like HT and injecting the room after the scene). Setting the same inject offset for scene and room does the same effect.

- Added a new setting in groups: metallic textures (a.k.a spherical textures). This setting is skipped when you use texture animations.

- Added an option to update the crc everytime you inject a scene

- Same textures used by 2 or more rooms are not written twice or more times

- CI4 / CI8  textures using the same palette no longer write the same palette more times (including between rooms)

- DList are now culled ofcamera ingame. This increases the room size a bit so I also added an option to disable it.

- Group highlight now only appears when the selected tab is "Rooms"

- Added entrance cutscene table editor. Its only purpose is to disable cutscenes from playing since cutscene editor is unfinished.

- Added a 64-bit version of the executable

Bugfixes

- Fixed a bug were only 1 pathway was saved

- Fixed a bug were entrance table used decimal numbers instead of hex, which was not the intendeed behaviour

- Fixed a bug were unused materials were written in the room files 

- Fixed a bug were fog distance and draw distance were not saved unless you pressed enter key

- Fixed a bug were entrance table saved entries in a bad order if you sorted it, messing the whole rom table

- Fixed a bug were transition actors switch and cam fields weren't duplicated with the duplicate button

- Fixed a bug were transition actors switch and cam fields were filled with garbage values when using the add button

- Adjusted the mouse hitbox and axis so it matches the custom door model. Doors that aren't transition actors will also be displayed with the door model now.

- When the crc is updated, now it displays the succesful command line

Debug features

- Actor filling is now inside debug tab

- Added an option to render actors (very experimental, you can only render very few actors, unless you update the XML, note that variables are ignored right now)

- Added an option to create a pathway that surrounds the selected group


Changelog 0.91


Improvements

- Added an option to disable waterbox movement

- Now you can save the options in a .xml, they will be loaded everytime you open SO

- Added an option to clear the dma table of a rom. Use this if you experience crashes ingame. (this also updates the crc)

Bug fixes

- Auto-add objects no longer crashes when saving scene

- Sticking actors to ground/ceiling now uses Z/X keys to prevent shortcut bugs

- Entrance table now refreshes the scene name column more often


Changelog 0.90


Improvements

- Fields are now saved when losing focus. Enter key is no longer required.

- Hold shift while adding or duplicating an instance to create it in front of the camera

- Added room selection for waterboxes. Default value is 3F which enables them on all rooms

- Now its easier to tell where the instance is facing (light-green extreme = front of the instance)

- Transition actors are rendered as rectangles of the same size as ingame doors

- Use mouse wheel after moving an actor to rotate it. Waterboxes will change their size instead.

- Use up and down keys while moving an actor to stick to ceiling/ground


New stuff

- Actor database added for actors, transitions and spawns. Click on the blue button next to actor number to open it. You can type a word to filter actors. 
Note that if a variable contains the word, the entire actor will be displayed. You can also use special filters like #Transitions and #Monsters.

- Added entrance list. SO auto-generates it based on where you place the spawnpoints. The entrance number is the same as the order of the spawns, so the spawn 2 will be the entrance 2.

- Added support to vertex colors. You must replace the export_obj.py of your blender 2.7x with the one in the blenderscripts folder.

- Added an entrance table editor. This editor is independent so you can change the entrance table without injecting anything in the rom.


Bugfixes & tweaks

- Greatly improved the lighting of the imported maps by fixing a bug related to normals

- Fixed a crash that involved moving an instance outside room boundaries

- Fixed bug where maps made with blender couldn't have vertex groups

- Fixed a bug where you could not save polytype assigned to the first group in the first room

- Fixed a crash when attempting to delete the last polytype of the scene

- Fixed a crash when typing on room offset when there's no rooms

- [Temporal fix] animated opaque textures will be injected as transparent to avoid crashing

- Reduced byte padding (less kb per scene)

- When importing .obj, groups with 0 triangles are ignored

Changelog 0.8x

show

Changelog 0.7x

show


Have fun!
by Spire at 12-10-2017, 05:29 PM
[Image: 3rd-quest-logo-dec-2017.png]

June 2013. Three people came together after some formative discussions to begin a Zelda 64 Modding Project. CDi-Fails, CrookedPoe, and Spire launched a daring effort to create a full-conversion mod of Ocarina of Time with the initial goal of creating an entirely new world. How hard could it be?

...

Four years pass and the Third Quest team has solidified after many molten lineups. We honor those who contributed in the past and are no longer with the team, so to whatever you may have contributed - if you are reading this, thank you. Otherwise, the team is seven-strong and we are:

CDi-Fails, CloudMax, CrookedPoe, Evan20k, Ideka, Jhreamer, Spire

To address Third Quest, what it was, is, and what it can become: We are scientists and artists collaborating in an effort to change the experience of a game we love so that in time, we may provide you with something you've never quite known, and furthermore—something you never knew you wanted. Third Quest is an experimental effort to break the bones and unravel the nerves, to tear the muscles and to extract the organs of Ocarina of Time, carefully keeping it on life support while meticulously reshaping the legendary beast into something we hope Nintendo would be proud of.

Over the past 4.5 years, we have built an entirely new world for the essence of Zelda 64 to seep into. Thousands of hours have been poured into this project between discussion, research, and development, and we still have a long way to go. Making a AAA-budget game ca. 1995-98 standards with a team of seven people can prove challenging, and as such, we have learned many lessons from working on Third Quest. It is essential not to become too obsessed with any one aspect of the game world—or the game world as a whole. It is easy to get lost in the micro and macro and as such, a piece of wisdom we have gleaned from our time with 3Q is that maintaining a balanced sway between those things small and grand is essential to discovering and learning about the world you are developing.

Remember one thing: Zelda is about Exploration, Puzzles, and Combat. This is the crux of the series. Every opportunity you can imagine to subtly and naturally guide the player will pique their adventurist imagination and keep their attention. You must maintain an air of interest and curiosity so your players do not grow bored with the experience you convey. A good rule of thumb is: if you design an environment that is compelling to just stand in, to listen to the music and sound effects that generate an atmosphere of magic and to watch the dawning and dusking sun over the horizon, then you're on the right path.

Third Quest has had a quiet history of public display, having released a demo on Halloween 2015 following a moderate social run with teaser trailers leading up to launch and since then, an eager following. Though we rarely post anything, even updates, the project is very much alive and always has been. Like anything, it has slowed at times with various members requiring reprieves to focus on other endeavors, but its heart beats as it always has. Another lesson we have learned is that preemptive showcasing can satisfy the creator(s) enough that their motivation to further develop wanes. In the words of David Bowie from the song 'No Control' on his 1995 album Outside, "Don't tell God your plans," meaning, don't tell anyone your plans. Even the trees are listening. It's okay to discuss certain things you are exploring within your project, especially if you're trying to build a team or gain critique from a respected other, but outlining an end-goal and over-sharing with people will most likely diminish your drive and thus, it is imperative to keep most things to yourself. Secrecy is okay if what you're hiding will ultimately benefit humanity. If you are passionate about something, you know you are excited at the idea of sharing your finished work with people. If you share your plans before finishing your work, odds are your audience will support you with some degree of enthusiasm and that can be enough to satisfy the creative hunger. Preemptive over-sharing is a major project-killer. Tend to your garden with quiet love and care. The fireworks can wait for release!

As of now, we have nothing new to show for Third Quest, but we will update this thread accordingly when the time comes... So, any discussion surrounding the project as you know it and as you don't is totally welcome. There is much to say about our time with Third Quest, as we have individually and collectively learned a lot. Between the members of this team, we have accrued a lot of knowledge and insight into the inner-workings of Ocarina of Time, Nintendo as a creative entity, and ourselves as creators. As such, it's time we open discussion a bit and step from the shadows to talk with you.

Thank you for taking the time to read.
by Killgore52 at 12-10-2017, 05:11 PM
Hello everyone, I would like to formally present Project Mystic.  What it is essentially is an OoT mod with the goal of creating a new overworld, new story, new dungeons and new models to OoT that will work on the N64.  Think of OoT with a fresh coat of paint.  As an effort to maintain the experience of surprise, I will only be showing select screenshots of the overworld.   Thank you all for reading and I hope to see love for Project Mystic.

[Image: D0ll7Ub.png]

[Image: evohz53.png]

[Image: I3qFO2p.png]
[/spoiler]


https://www.youtube.com/watch?v=sl-pJkQ7gzI

https://www.youtube.com/watch?v=ClzE7Kl2yTI&t=14s
by Ideka at 12-10-2017, 11:05 AM
NOTE: This tutorial is far from finished, and as such many explanations are incomplete and potentially misleading to some extent. It will be updated over time, but for now it does at least cover some of the fundamental concepts of MIPS assembly.

You want to learn how to "do ASM" for N64 games? Even though this task seems to be considered nearly impossible by some, it actually isn't very hard once you get the hang of it. Beware though; to actually get the hang of it, a decent amount of discipline and patience will be required.
 
Let's start with the very basics: what is "ASM"? ASM stands for “assembly”, which is a type of programming language. Just like with "normal" programming languages (such as C, Java or C#), there are many different assembly languages. For the N64, the assembly language to code in is called "MIPS r4300i" - we'll get back to this soon. First though: what is the difference between assembly programming languages and "normal" ones?
 
Well, when you code in ASM, you code directly for the processor(s) of the machine in question. This means that you only can use the instructions which are used in the processor itself when coding. Assembly is basically the machine code of a processor (which is actually just patterns of binary data; lots of 0s and 1s in other words), translated into code readable by humans. While you code in a language like C however, you often don't have to care much about how the processor you're coding for works - that is handled by the compiler.
 
What this means (in simpler words), is basically that when you code in assembly, you’re “speaking” directly to the machine with your code. When you code in high-level languages like C# or Java on the other hand, you’ll have to “translate” your code through a compiler for the machine to understand it.
 
The CPU (Central Processing Unit; the ”core” processor of a machine) of the N64 is the “MIPS r4300i”. Therefore, the specific assembly language to code in for N64 software is also called “MIPS r4300i” (it’s often just referred to as “MIPS” in the context of the N64 though). So, to “do ASM” for any N64 game, you’ll first need to learn how to code in the MIPS r4300i assembly language. This is exactly what this tutorial aims to introduce you to, even if you have no prior experience of programming.
 
It is often said that the first program you should write in any language is a “Hello World” program, which simply prints the words “Hello World” on the screen. Therefore, we’ll explain how that could be done for the N64 in this tutorial. We won’t hack some game to print these words though – instead we’ll use an application of our own. This is because hacking games often requires more than just understanding the MIPS language. You have to have some basic knowledge of the game’s inner workings and structure too, in most cases.
 
Writing a “Hello World” program is very easy to do in most high-level programming languages. Here’s an example of how it usually is written in C:
 
Code:
#include "stdio.h"

int main(){

                             printf("Hello World");
                             return 0;

}

As this isn’t a tutorial about learning C programming, you won’t have to worry about most of this. Just know that the program starts reading code from the “int main()” segment, which is a function. 

A function is a piece of code that often has a very specific task; like printing text on the screen or calculating certain values for example. Functions can be executed from anywhere in a program's code, even if they aren’t "close" to the code that "calls" them (when using a function, you say that you "call" it). The “printf” function that is called in the above C code for example, is a function that outputs the text string it has been supplied with.

What you see in the parantheses following the function call (the text string "Hello World), is what is called an "argument" of the function. When calling some functions, you can provide them with arguments. The values of the arguments aren’t pre-determined in the function itself, so their value can vary based on the circumstances of the call. In C’s “printf” function for example, the text string to print is an argument (since you want to be able to print different text strings; if this wasn't a variable, the "printf" function would only be able to print one constant string of text).
 
For the N64 however, it won’t be as easy, as we basically will be designing our application from scratch. In the above C example, “printf” (the function which is called to print the words) is an existing function which is found in the file “stdio.h”. The programmer doesn’t need to write this piece of code themselves, or even understand how it works - they only need to know with what argument(s) to call the function.
 
When coding in MIPS for the N64, we won’t have the privilege of a pre-written piece of code that will print text on the screen for us – we’ll have to make one ourselves. Since this task would be quite complex for beginners however, I have already written a function that works very similarly to printf, but for the N64 instead. And again, you won't be doing anything with this code yourself yet, aside from looking at it and trying to learn from it.

Like printf in C, this function needs to be called with arguments. I designed it to utilize four arguments, but only one is needed to actually print the words (which is the only result we want for now). We’ll discuss the rest of them later. Here is a short overview of the function (what we need to know for now, anyway):
 
Code:
N64 print function:
Argument 1 (A0) = RAM address of text line to print
 
This might seem confusing to you right now; what does “A0” mean?  What is a “RAM address”? Let’s explain it all.
 
“A0” refers to the “register” in which the argument will be stored in. A register in MIPS is basically a variable; a little piece of memory that can store any value that fits in it. There are 32 different registers in MIPS, and some of them have specific purposes.  There are four registers which specifically are intended to store arguments before function calls: “A0”, “A1”, “A2” and “A3”. We’ll discuss the concept of registers further later, but for now this should roughly be what you need to know about them.
 
It is very important to understand what “RAM” is in order to code in almost any assembly language. “RAM” stands for “Random Access Memory”; you might also have heard of “ROM”, which stands for “Read Only Memory”. This might not tell you much right now, but we’ll explore it further.
 
Read Only Memory (ROM) is precisely what its name implies; it is memory which only is read (loaded). In games for the N64 for example, “constant” game data like code, models and textures are always stored in ROM, which in turn is what is stored on the game cartridge. There are other types of game data though; consider Mario’s health in Super Mario 64 for example. This isn’t a constant value, since you can lose and gain health. In other words, it’s a variable (a value which can vary), which cannot be stored in ROM as data stored in ROM can only be read (once again, precisely what its name implies), not written/altered.
 
But where are variables such as Mario’s health stored then? This is where RAM comes in. In RAM, data can be actively and dynamically altered while the application is running. The N64 actually only uses data in RAM to run the game, even if it uses ROM data to set up everything in RAM. This means that all the “constant data” located in ROM (like code, models and textures) can also be found in RAM with N64 games.
 
Aside from this unaltered data directly transferred from ROM, data types like variables are also stored in RAM as they can actively be altered while the game is running there, unlike in ROM. In most games, these include variables such as player health (like we discussed using the example of Mario’s health in Super Mario 64), player position and countless more. 
 
A “RAM address” refers to a location in RAM. You could visualize RAM like
 
All this means that we can print the words “Hello World” in our own application, by using this relatively simple piece of code:
 
Code:
.ORG xxxx
LUI A0, 0x8000
JAL PRINT
NOP
 
Of course, this piece of code alone won’t print anything on the screen; you need to have the function as well.
 
Now, let’s go over what the code actually does and how it works.
 
Code:
LUI A0, 0x8000
 
You can say that there are three parts to this instruction. The text “LUI” is the “opcode” (operation code), which determines what the instruction will do. It stands for “Load Upper Immediate”, which we’ll get to later. You’ll find that all opcode names in MIPS actually are acronyms for what they do.
 
The next “part” is “A0”. This is a register, as we discussed before. Just to make sure that we’re all on the same page, though: A register is a little piece of memory in RAM that can store any value that fits in it, a variable in other words. Their value is assigned by opcodes, which also use them in their operations. There are 32 different registers in MIPS, and some of them have specific purposes. Register A0 is intended to be used for storing argument values before calling a function, for instance.
 
And now finally for the last component of this instruction: “0x8000”. This is a so-called immediate value. An immediate value is basically a value that the processor doesn’t store in any register or other similar section of its memory, so it’s only used in the instruction that it’s found in. Immediate values are mainly used to set the values of registers or manipulate them in other ways, such as decreasing or increasing their values. One important thing to remember about them is that immediate values only can be a maximum of 16 bits (2 bytes) long.
 
And by the way, the prefix “0x” before the “8000” simply means that the value after it is stated in hexadecimal. If you’re not familiar with this, I’d advise a quick Google search, as I’m fairly certain that you’ll be able to find far better explanations than I could ever provide you with.
 
So, what does this all mean then? What does the instruction “LUI A0, 0x8000” do in the end? Well, it loads the (immediate) value of 0x8000 into the upper bits of register A0. This might be hard for you to understand, but I’ll try to help you visualize it.
 
A MIPS register basically consists of 32 bits, or 4 bytes if you will (actually, they have a capacity of 64 bits, but you won’t need to concern yourself with that unless you need to store a REALLY big value). We could visualize an empty register set to 0 like this:

Register A0:
Byte 4:               Byte3:                Byte2:                Byte1:
00                      00                      00                     00

As we know, an immediate value is 2 bytes long. This means that if we’d want to set A0 to a value bigger than 2 bytes, we’d not be able to store that value with other opcodes usually used for assignment, such as adding. Here’s an example:
 
Code:
ADDI A0, ZERO, 0xFFFF
 
This instruction will add the immediate value 0xFFFF (the maximum value which can be stored in 2 bytes) to A0. To be more precise, it actually adds 0xFFFF to the register “ZERO” (a register that always is set to zero) and then stores the result in the register A0. ADDI stands for “ADD Immediate” as you might’ve guessed, we’ll discuss this further later.
 
After executing this instruction, the register’s contents will look like this:
 
Register A0:
Byte 4:               Byte 3:               Byte 2:               Byte 1:
00                      00                      FF                      FF
 
So, even when we stored the largest immediate value possible into the register (0xFFFF), it won’t affect “byte 3” and definitely not “4”. To assign an immediate value to these bytes, we’ll need to use another opcode – LUI.
 
Just like its name (Load Upper Immediate) suggests, this instruction loads an immediate value into the upper “contents” of a register – its upper bits in other words. This means that after executing an instruction such as this one:
 
Code:
LUI A0, 0xFFFF
 
The register’s value will look like this, assuming that it was empty (set to 0) before the instruction was performed:

Register A0:
Byte 4:               Byte 3:               Byte 2:               Byte 1:
FF                      FF                      00                      00
 
So after the first instruction in our source code (LUI A0, 0x8000) is executed, register A0 will look like this:
 
Byte 4:               Byte 3:               Byte 2:               Byte 1:
80                      00                      00                      00

So in summary, the result of executing the instruction “LUI A0, 0x8000”, is that the value of register “A0” is set to 0x80000000.
 
Now, let’s move onto the next instruction. This one will be a lot simpler to explain, and hopefully also to understand:
 
Code:
JAL PRINT
 
You could say that this instruction consists of two components: “JAL” and “PRINT”.
 
“JAL” is the opcode, it’s an acronym of “Jump And Link”. This instruction is used to call functions in MIPS. The instruction “jumps” to the RAM address given to it by the following value, and begins executing the code found at that address. In this case, that address would be "PRINT"... But wait, isn't "PRINT" a string of text? It's not a value that classifies as a valid RAM address, right?

Well, it's what's called a "label". Labels are very useful for assembly programmers; they allow you to reference a RAM address without having to type out the exact value of it.
by Psi-Hate at 12-10-2017, 08:54 AM
OcarinaAutoInjector is a multi-purpose injector made by MelonSpeedruns that allows you to easily write many different files into your ROM, including scenes, rooms, objects, textures, and patches. 

ROMs

You need a ROM named "ZELOOTMA.z64" placed in the /ROM folder
The resulting ROM after injection will be in the root directory named "ZELOOTMA-MODDED.z64"

Scenes/Rooms

The scenes and room files must follow the criteria that they are to be named after the scene number they are to be injected to. 
For example: "85 (Scene).zscene" & "85 (Room 0).zmap" would inject to Kokiri Forest.

1) Put your scene & room into /Files/Scenes

Done!

Patches

Patches come in the form of the file extension "zpatch".
A zpatch is made using an empty file named "x.zpatch" (x being the offset you'd like to write at) and writing the bytes you want to pastewrite to the rom.

1) In a hex editor, make a blank file 
2) Write the bytes that are to be written (example: FF FF 00)
3) Name it <offset>.zpatch (example: B9D1A8.zpatch)


Objects

1) Place your edited .zobj into the /Files/Objects folder
2) That's it. 

Textures

You can find the offsets of the textures that you want to replace in Texture Explorer

1) Name the texture <offset>_<imageType>_<palette_offset>.png (example: 01A32000_ia8.png)

Injection

1) Make sure everything is in the proper folder and is named properly.
2) Open "OcarinaAutoInjector.exe" and press enter to automatically inject everything to the proper place in the rom.

Image
by Psi-Hate at 12-10-2017, 08:29 AM
So you want to reveal your beautiful work of art to the world. You make a thread and post a chunky block of text, standing proud as... one (1) person reads it and... wait, where did they go? Did you do something wrong? Why aren't they interested? Is your project not good enough for the world?

Nope. Ya' did it wrong, dude.

All presented projects need a hook, line, and sinker. You gotta make everything appealing-- breathe life into your world! Here are some surefire ways to maximize your project's appeal (and these are the rules, stick to em').

1. Description Is Key

Describe what your mod is. People don't want a random screenshot or an attached file-- this isn't some grab-bag presentation. Describe its key characteristics, what it changes, what to expect, etc.

2. Screenshots

The best way to show off your accomplishments is to.. well.. show them!? Who'd've guessed?
Neatly organize and present your content, giving a clear representation of what you've done.

3. Accountability

If you have grandiose ideas and potentially one of the best mods ever planned out in your mind, boy, you must be good. Real good. 

Essentially, have some proof of experience-- don't ride your ambitions blindly without sticking to reality. Modding can be hard, so don't overwhelm yourself. If you haven't done any previous modding, be sure to try small things first and work your way up. Staff have full authority to remove project posts that are blatantly unaccomplishable. If you have complaints, make more progress and remake your thread (or fight to the death with a mod, your choice).

4. Credits

Don't take credit for other people's work, and make sure to list all team members (if there are any) so everyone gets the recognition they deserve. It's not necessary that you list the tools that you used, but it'd be appreciated. 

That's about it! Get to making your mods and show us what you got!
Welcome, Guest
You have to register before you can post on our site.
Username/Email:

Password


Login
Search Forums

Forum Statistics
Members: 239
Latest member: Crownjo
Forum threads: 53
Forum posts: 129
Online Users
There are currently 6 online users.
0 Member(s) | 6 Guest(s)