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]
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!
by Psi-Hate at 12-10-2017, 08:01 AM
Welcome to the Hylian Modding community! 

We're trying to keep everything properly situated and structured around here, and we'll need your help to make this community flourish. The rules presented will illustrate the proper etiquette a member of the community should practice. 

Site & Forum Rules

1. Respect Others

A community shines when all of its members work together and see one another as equals. It's dangerous to go alone, so always stick together. 

2. Spam and Flaming

Don't ever clog up a forum or thread with unnecessary posts! Keeping the site a clean and easy to use experience is a priority, so don't go around ruining it for others!

3. Everything is SFW

There should never be a reason that something inappropriate should be on display. Gore, nudity/pornography, hate speech, illegal material, and other content of similar nature is definitely not allowed. Swearing isn't heavily moderated, but try to keep it in good taste (basically, be friendly!).

4. On-Topic

Keep the discussion centered on the topic at hand; steering away will result in clutter and many unnecessary posts, making valuable information hard to find.

5. Staff Has Final Say

You might not like it, we get you might not like it, and others may not like it either-- but rules are rules. If the staff have made an administrative action in accordance with the rules, there's not much room for argument. However, if the action was made based on judgement alone without rules to support it, community consensus may be enough to override the decision. Keep in mind this is decided on a case-by-case basis, so don't expect the same treatment as someone else.

6. Reporting Posts

While we encourage users to use the report function when needed, reports should not be filed because you dislike a user or their opinion. Unless a post breaks the rules, it stays. 

7. No ROMS!

If you post them, you're getting banned (not really, but we will remove your post).
First time offenders will receive a warning, and repeated offenses will have more severe consequences.

Make sure to keep all these rules in mind when posting.
Welcome, Guest
You have to register before you can post on our site.
Username/Email:

Password


Login
Search Forums

Forum Statistics
Members: 190
Latest member: TheKaziHD
Forum threads: 47
Forum posts: 117
Online Users
There are currently 2 online users.
0 Member(s) | 2 Guest(s)