ROM/RAM documentation/help

[DeathBasket]

Okay, so there is already one hell of a load of good information on the wiki but I feel that there's still too much that is not understood by enough people. I'm not making this thread with the intent of documenting every little thing, it's more of a place to put potentially useful stuff.

 

The point I'm making I guess is that lots of people can easily make almost a brand new game with the relatively small amount of (great) tools that are out there for Super Mario 64 but we do not see this with Ocarina of Time. Yes, it's a lot simpler to work with that game but my point still stands. In my opinion the problem here is not the lack of tools because there are lots of tools out there that work really well, yet I have not seen many people (aside from the obvious ones) making even small hacks for this game in a long time. Maybe that's not going to change but I'd just like to know why it's not being done.

 

So anyway, I'm making this thread with the intent that people can post here about what problems they're having with this game and anyone with information that could help to solve these can post it. I'm mainly targeting the debug ROM since that's the ROM I work with 99.9% of the time but you can post information on others if you want. I guess it can be a place to pool together all the sort of stuff that's stopping people from making their hacks of this game. Need to find a particular value in the ROM or RAM? Need to change where the game starts off? Need to find a certain function or disable something? Post whatever problems you have here and myself or somebody else will hopefully be able to help you out. The ultimate goal is to put together all the kinds of information you will need to start making some proper hacks of this game.

 

I'll try and follow a format something like this, but I'll change it if people aren't comfortable:

ROM/RAM address data variable

So anything in italics will be a value you can change.

 

So to begin with, here's how you can choose where and how to start your game:

 

 

Exit number to start from after starting a new game:

0xB2045C 240F xxxx

x is any valid exit number (see above link)

 

Cutscene number to use:

0xB20468 3408 FFFx

x is the cutscene number, I'll edit this if I remember which value means no cutscene

 

Link to start as:

0xB20460 2408 000x

x is 1 for young, 0 for adult

 

Default file stats (file 2 and 3):

0xBA1680 (start address)

0xBA16A0 default name (8 bytes)

0xBA16AA max health (2 bytes)

0xBA16AC starting health (2 bytes)

0xBA16AE starting magic (2 bytes)

0xBA16B0 starting rupees (2 bytes)

0xBA16B6 Magic meter flag (1 for small, 2 for large iirc)

0xBA16BA Biggoron's Sword/Giant's Knife flag

0xBA16E0 Equipment

0xBA16EC starting boots/tunic equip (1 byte)

0xBA16ED starting shield/sword equip (1 byte)

0xBA16F0 - 0xBA1707 starting item flags

0xBA1708 - 0xBA171F starting item amounts

0xBA1718 starting boots/tunic/sword/shield (2 bytes)

After this is information for keys, map flags, etc. iirc, I'll add more on this section at a later time

 

[Arceny]

Cool, DeathBasket. Cool.

[Jason777]

I was actually thinking of almost the exact same thing not too long ago. There are so many full-game hacks for SM64 and most of them are made by people with absolutely no modding experiebce whatsoever. Granted, the mods made by people who actually know what they're doing are pretty damn amazing (i.e. Star Road, SM74, etc).

 

I was wondering why this might be when I came to the conclusion that it was the quality of the tools available for the game and the complexity of its engine.

 

Not that OoT doesn't have great tools, I just think that the amount of content in the game is overwhelming. There's just so much that would need to be modified to make a decent hack.

 

And we aren't really lacking in ROM documentation; I think all our information concerning RAM and routines being scattered all over the place is a major problem. Without a decent organized archive on RAM, the potential for sophisticated hacks is significantly reduced.

 

Not to mention that high-level or low-level programmers/hackers are almost nonexistant in the zelda hacking scene (besides people who purposefully look for glitches).

[kyrin64]

there are two things that would help me changing links model and geting the bones to work with it and adding animations in.

and getting custom cut scenes to work including the camera and text boxes,having scripted animation to during those cut scenes

i just don't know where in the games code to find this stuff. and changing the function of actors and a good program to hex with

[Guest sakura]

Thank you Jason, you made so many good points. This is something I've been trying to get across for a while now. I even wrote a blog post about it, though I don't know if many people realize The-GCN's blog system exists.

 

There are so many full-game hacks for SM64 and most of them are made by people with absolutely no modding experience whatsoever.

 

This is key. What we want is to enable the amazing artists, 3D modellers, composers and story writers to create content for the game. Right now the technical barrier is still too high for your casual person. They have amazing ideas and give up because they're too difficult to implement. I pointed out an example piece of software in my blog post, it was a command line texture replacing tool. It needs you to already know the offset, type, width and height of a texture before you even get started editing it. Well that's just silly for an artist to have to find information like that from binary data. Or -maybe- get some set of steps like "Open UoT, pick the dlist menu (what's a dlist...?), copy the offset...". You get the idea, this is unacceptable. You should be able to open a file and see the textures, we've known how to get that information automatically for a while now. It's that kind of thing that keeps the skilled people who are making brilliant content from getting it in game, which shouldn't be their job in the first place.

 

I was wondering why this might be when I came to the conclusion that it was the quality of the tools available for the game and the complexity of its engine.

 

Not that OoT doesn't have great tools, I just think that the amount of material in the game is overwhelming.

 

I'd say our current tools aren't working. They are great peices of software, don't get me wrong. I have nothing but respect for the coders we have here. I've seen several people lament that people aren't using their software though, and it's simply because they're not made for the right audience. We don't want to make tools for people who already know how to hack. We want to make tools for people who have other skill sets, like texture work or modelling. This means taking the burden of knowing technical details off of the user. It means good software engineering, like starting from a set of requirements and focusing on what the user really wants to accomplish. It means making sure your software is tested a couple of times by people who don't know how it works before hand, to make sure it's easy to use. I love the analogy I read a while back. A pencil is a good tool, because you don't have to think about it while you're writing. Besides the occasional sharpening, a pencil will get out of your way and let you draw or write. We should strive for our tools to be that way. They should be made for the user. At the end of the day, the best tool is the one that wasn't really noticed, because they were too busy putting awesome content in game.

 

There's just so much that would need to be modified to make a decent hack.

 

While this is true, I think you'll find that people are willing. The enthusiasm is there, but it dies a slow death as the technical barrier to implementing ideas overwhelms people that should never have to run into it.

[SanguinettiMods]

As maybe the youngest one here, I agree with the above statements. It took a lot of work and understanding to get to where I am now, and even though I know how to do it, it is still troubling to go and find information for most tools.

[haddockd]

I always thought the issue was that there are tons of specialized tools out there but very few tools that fill wide area gaps. Like a tool for finding, extracting, replacing and modifying actors, NPC's etc all in one easy to use graphical tool. Sharp Ocarina was a good example of a multi faceted tool that was pretty popular, as was UoT. Many of the other tools tend to be far too specialized and as Sakura pointed out, ask for information that the application *should* likely already know or gather from the data itself.

 

Point being, we may need more "one stop shop" types of tools and fewer command line "this does one little thing" tools. Not knocking any apps out there by any means, just my 2 cents.

[mzxrules]

This helped me locate where this information is stored in the v1.0 rom  

 

Anyway, 0000 is used no cutscene, unless the game state is set to the title screen/demo mode or whatever you want to call it. 

 

Lastly, I'm curious as to what purpose the "random" numbers serve...

[giadrosich]

I can sorta contribute to the problem of starting out in OOT modding.

 

The main problem, hands down, is that it's not newbie friendly, as has been stated above. People like me (new) who want to make a decent game for people to enjoy have to start out with the VERY basic of things. I didn't even know this community existed until a few days ago. I learned everything at the beginning by looking at Hex editor tutorials. I learned how to work ZAP2 from someone who worked on Zelda's Birthday (highpriestfuneral), and even then I had trouble really "getting" it until a few hours later after playing around with it myself.

 

And this brings us to the next problem. The lack of newbie-friendly tutorials. I can read a the tutorial about changing OOT songs/effects, but if I don't have a clue what you're talking about, it's gonna be difficult to do anything. I'm also a very visual person, SHOW me how to do it in a video, and I can do it! This is why I've started documenting everything that I've learned into video tutorials. Also, instead of just telling people what to do, tell them WHY you have to do it this way, and you'll learn how to better do things on your own.

I started by editing text. I then learned (on my own) that 01 means a space. I then learned the colours for the text, how to input the character for the file name, ect. I documented each new step in a video. I was very proud of what I had learned on my own.

 

But then I wanted to do what people could do in Mario64. Edit levels. And then I entered a whole world of complicated programs and terms I didn't even know existed. I'm not a tech-savvy person. But I can learn how to sound like a tech-savvy person if you give me a video tutorial on how to do it.

 

I have 5 programs on my computer that I downloaded in the hopes it would bring me an easy thing to learn. UOT doesn't even work with me, it just gives me an error and I can't find anything documenting said error or how to fix it. ZLE2 I learned how to move stuff, but how the heck do I put collision on the moved ground? SayakaGL is a great tool, but I can't edit objects (aka groups) on them, so I have to use ZAP2 for that, and sometimes that program doesn't save your changes if you don't close out the tool in the right way!

 

I have no idea how to add actors to the game for an area. All I can do is replace them, and that means taking out another object you can live without to replace it with the object you want to put in. Oh yeah, I read the tutorial for adding actors. I didn't understand a word of it. I go into things like that and see a bunch of numbers and get freaked out, and then the tutorial itself assumes you know what they're talking about.

 

There are exactly four videos on youtube for UOT that I've found. Only three of them are sorta useful, and the video quality is shot. And they're all of the older version. There are no tutorials on ZAP2 or ZLE2. Any search for SayakaGL OOT tutorials only bring up the videos I've posted recently.

 

The point I'm getting at is we need better tutorials for newbies on how to work all of this. Yeah, it's daunting to be sure, as people have said, there's a LOT to be done in OOT hacks. But the problem isn't the tools, or the programs, or even the willingness. It's the lack of simplified knowledge. There's oodles and oodles of pages on this forum that I have no idea what people are talking about, other than the posts that say "Hey, this is great and useful stuff!", because I'm not a hacker. I want to mod, but no one posts simplified stuff to help newbies out.

 

That's my 4 cents worth anyway. I hope I didn't come across as mean. XD Just tryin' to be honest here.

[modman]

giadrosich, on 15 Feb 2013 - 06:07, said:

 There are exactly four videos on youtube for UOT that I've found. Only three of them are sorta useful, and the video quality is shot. And they're all of the older version. There are no tutorials on ZAP2 or ZLE2. Any search for SayakaGL OOT tutorials only bring up the videos I've posted recently.

 

 

this so hard. nobody seems to document what they do, and the ones that do are mostly (if not always) the program makers themselves, and even those aren't all that helpful. it makes me wonder how anyone could have learned this stuff.. it must have been god awfully hard just to wrap your head around it from just reading about it. maybe its just the way i learn, and thats visually so videos is basically reading instructions for me

[Jason777]

This thread should be kept alive... there is great use for it. I guess I'll add something onto it, too. 0x8002D570 - "Kill Actor" Function (RAM Offset)

void func_8002D570(ram_actor * a0)	// Erases specified actor from screen
// A0 = RAM Actor

8002D570 : LW T6, 0x0004 (A0)	// T6 = actor Z-Target status
8002D574 : ADDIU AT, R0, 0xFFFE	// AT = -2
8002D578 : SW R0, 0x0134 (A0)	// Actor display function = NULL
8002D57C : AND T7, T6, AT	// T7 = (T6 & -2)
8002D580 : SW R0, 0x0130 (A0)	// Actor main function = NULL
8002D584 : JR RA		// Return
8002D588 : SW T7, 0x0004 (A0)	// Delay Slot: Update actor Z-Target status

I found this function almost a year ago whenever I was looking into why Nabooru wouldn't load if you were Adult Link (there were no object sets).

[Jason777]

I guess I'll post another thing that is semi-related to the above post... Also, I don't really count this as a double-post because it is adding new information! Well, that and because only new posts show that a thread has been updated

 

Anyways, here is how to load Nabooru up even if Link is an Adult! I should've posted this yesterday while I was on the topic of the "Kill Actor " function, but I guess it deserved a new post...

 

0xE69544 - Nabooru's check to see whether or not Link is a child/adult (ROM Offset)

Go to that offset in the Debug ROM and change it to 00000000 to disable to disable the check

 

If you don't know what had happened, I went to 0x2744 is the Nabooru actor file and changed this:

bne t8, $at, $L000066

... to this:

nop

Yup, super simple!

 

Now here is how I found it...

Well, on a long plane ride to the USA (12 hour flight), I seem to have found the routine within Nabooru that checks if Link is a child or not and decides whether to load her model.

 

So, I believe I can get her loaded up in Adult Link's presence. Now I just need to get her initialized in the standing position... shouldn't be too hard.

 

If you can read assembly, take a look at func_80AB34A8 in her actor; it contains the only piece of code in her actor that reads Link's age and checks if he's a child:

lui v0, 0x8016
addiu v0, v0, -6560
..
lw t8, 4 (v0)
li $at, 1
bne t8, $at, $L000066
nop
..
$L000066:
jal external_func_8002D570
or a0, s0, $zero
..

http://spinout182.com/mqd/En_Nb.S

 

[mzxrules]

petrie figured this one out...

 

B1F43C - sets the Water Temple's starting water level flag. 3C0D 4000 sets the water level to F3, 2000 sets it to F2, 1000 sets it to F1, 0000 makes you sad.

[Jason777]

I think I'm getting close to finding the function that causes an actor to die... I was looking at things that set Queen Gohma's health today when I found an instruction that checks to see if her health is 0. If it is, then it would make a call to a function within the actor (probably a function which plays the unique death cutscene that all bosses have) and then would make an external function call to 0x80032C7C. I believe that this may be the function that actually causes an actor to die... Now for those who are confused and saying "you already found the kill actor function?", that function was more of a routine to "unload" an actor from the game. Anyways, I would look into this function if I had anymore time.

 

???? external_func_80032C7C(RAM_Actor * a0, RAM_Actor * a1) : Possibly causes a specified actor to die?

$L000182:	addiu           v1,v1,%lo(data_80919150)	bne             v1,v0,$L000183	lw              t6,44($sp)	lw              a0,0(t6)	jal             external_func_800635D0	sw              v1,36($sp)	beq             v0,$zero,$L000183	lw              v1,36($sp)	lbu             t7,175(s0)	li              a1,14352	or              a0,s0,$zero	subu            t8,t7,v0	sb              t8,175(s0)	lb              t9,175(s0)	blez            t9,$L000184	nop	jal             external_func_8002F828	or              a0,s0,$zero	jal             func_8091683C	or              a0,s0,$zero	lw              a0,52($sp)	jal             external_func_800299AC	addiu           a1,s0,56	b               $L000185	li              t0,10$L000184:	jal             func_80915F38	lw              a1,52($sp)	lw              a0,52($sp)	jal             external_func_80032C7C	or              a1,s0,$zero	li              t0,10

Taken from: http://spinout182.com/mqd/Boss_Goma.S

[SoulofDeity]

ah sweet, I never noticed this thread before  I've been looking for some debug rom functions to port to 1.0. 

 

btw, Jason, when converting assembly to C functions, are the args passed as a0, a1, a2, sp   or a0, a1, sp?

I know the fastcall convention uses 2 registers, but I'm not exactly sure how that carries over for mips...

[Jason777]

For function arguments, I've always assumed it to be a0, a1, a2, a3, (sp + 0x10), ... and so on.

 

I've never heard of fastcalling

[SoulofDeity]

excuse the messiness of this code, I've been pulling my hair out trying to find the problem and am wondering if maybe someone else can point it out.

 

EDIT:

lol, nvrmind. brainfart. I was nop'ing out the sequence number. >.<   I'll posted the fixed code and assembled versions in my OoT 1.0 (U) notes topic

[Jason777]

I was messing with speed values today and I seem to have found travel speeds within RAM actors or "actor panels".

 

(*(f32*)(RAM_Actor + 0x68)) : Actor speed (not to be mistaken for animation speed) (RAM Offset)

 

I found this by looking at some old documentation that zeldazelda had made on changing the speeds within the Iron Knuckle. There were a few speed values that were being read from the rodata in the actor so I was looking at the instructions that utilized it. After reading the speed value into a2, it would usually make a call to this function...

void external_func_800A51A0(RAM_Actor * a0, void * a1, f32 a2, uint32_t a3) // I don't actually know what all the arguments are for sure besides a2

^ I assume that this function has to do with setting the speed of the actor. Alternatively, you could set the speed for the actor by going to float word at 0x68 bytes away from the start of the RAM actor and changing it there. For actors that are using an animation that doesn't have them move foward, the value at this is offset is 0.

 

Hmmm... I seem to have found an efficient way of looking up speed values. These are my notes that I have taken on it today. For those who care for it, it may be kinda hard to read:

 

// RAM_ACTOR + 0x68 = Speed?
// 00E2AEF0 = IRON KNUCKLE ROM START
// 80A74310 = VIRTUAL START
// 00E2F5C0 (ROM) = IRON KNUCKLES WALK SPEED
// 46D0 (in actor)
// (In rodata... used right before $L000028...)
data_80A789B0:	
.ascii "En_Ik_inConfrontion_Init : %d !!!!!!!!!!!!!!!!n000"
data_80A789E0:	.single 0.900000

// 00E2C00A (ROM) = PULLING AXE AWAY FROM SIDE HIT
// 111A (in actor)
// (In func_80A753D0...)
lui             a2,0x3fc0
li              a3,0
jal             external_func_800A51A0

// 00E2BD86 (ROM) = PULLING AXE AWAY FROM FRONT HIT
// 0E96 (in actor)
// (In $L000056...)
lui             a2,0x3fc0
li              a3,0
jal             external_func_800A51A0

// 00E2BA6E (ROM) = FRONT AXE SLICE
// 0B7E (in actor)
// (In func_80A74E2C...)
lui             a2,0x3fc0
jal             external_func_800A51A0

// 00E2B74A (ROM) = RUNNING WHEN ARMOR IS OFF
// 085A (in actor)
// (In $L000028...)
lui             a2,0x3f80
li              a3,0
swc1            $f18,16($sp)
sw              $zero,20($sp)
jal             external_func_800A51A0
swc1            $f4,24($sp)
or              a0,s0,$zero
jal             external_func_8002F828
li              a1,14783

// (@ 85A in actor...)
lui             $at,0x4020
mtc1		$at,$f6
nop
swc1            $f6,104(s0)

$L000029:
lh              t8,182(s0)
lui             a1,%hi(data_80A74BA4)
addiu           a1,a1,%lo(data_80A74BA4)
or              a0,s0,$zero
jal             func_80A74390
sh              t8,50(s0)
lw              $ra,44($sp)
lw              s0,40($sp)
addiu           $sp,$sp,48
jr              $ra
nop

Oh yeah, this is zeldazelda's post: http://glitchkill.proboards.com/index.cgi?action=gotopost&board=ootmod&thread=4766&post=49807

[SanguinettiMods]

Jason, this is great stuff. Didn'y you have a method for looking up damage tables as well? Could you post that information here, too?

[giadrosich]

To document things I've found out with deathbasket's help for others.

 

The new file starting offset is at 0xB1F774

 

24 0C XX XX

 

X= exit list number

 

To make the game start out in a cutscene from another part of the game, use the first exit number in the list. For example, if you want the game to start out in Kakariko Village at the burning village cutscene, then set the offset to "24 0C 00 DB"

 

To make the cutscene play, you must go to the cutscene offset which is at 0xB20468 3408 FFFx
 

We can see in the debug that cutscene 0 is the burning village scene. So change the FFFx to FFF0.

 

And there you go, the game starts you in the village as it's burning. And then you can edit cutscenes from there.

[Jason777]

Sure thing, Sanguinetti.

I'm writing this on my iPod so I can't really elaborate... I fix this post up a bit when I get home.

 

Tutorial by Jason777

 

I went and looked at the disassembly of 5 different actors whose damage charts have already been mapped out and I seem to have found a way to locate damage charts in the actor file and in the RAM (if it has one)...

 

In the RAM, an pointer to an actor's damage chart can be located 0x98 bytes away from the start of "actor panel" or RAM actor structure.

 

In the ROM or actor file, it requires a bit more work to find...

[*]Take the disassembled actor file and do a search for the integer of 152 (0x98 in hex), you should get very few results.

[*]Look for a result which stores a word of a registers contents at an offset which is 152 bytes away from the base register's value. For example, in dark link's file (En_Torch2.S) we find this instruction:

sw t1, 152 (s0)

[*]Check the instructions before to see if the base register (in this case, s0) could hold the offset to the actor panel. If you're not sure, then it may still do you some good to continue to the next step.

[*]If so, check to see what the contents of the register that was stored (in this case, t1) by looking at the instructions before. For example, in dark link's file (En_Torch2.S) we find these instructions:

lui t1, %hi (data_80B1FA08)..addiu t1, t1, %lo (data_80B1FA08)

[*]Take the value (it should be a virtual offset) and do a search for it (in this case, we would be searching for "data_80B1FA08"). Or, you could just go straight the virtual offset in .data section.

[*]And there you have the damage chart in the disassembled actor (in this case, 0x80B1FA08). The next 0x20 bytes are all part of the damage table.

To find the damage table in the assembled actor file (.zactor or .ovl)...

[*]Grab the actor's virtual entry point from this list (dark link's is 0x80B1D980): click me

[*]Take the virtual address of the damage table and subtract the actor's virtual entry point from it. The result is the offset of the damage chart in the assembled actor file.

I'm pretty sure this has been found before... Anyways, this is in response to this thread: click me

 

I also do not take full credit for this tutorial since this topic seems to already have been coverred quite well by Xu Yuan and the Z64 Wiki. Some credit goes to DeathBasket for the help he gave me concerning disassembled actors.

 

There's actually two ways to go about searching for the Damage Table (as well as other common attributes of actors i.e. health, speed); I have named these methods as actor panel attribute referencing and attribute setting function calls

 

The first method is where we would just search for specific integers that are relative to the actor panel. For damage charts we would look for 0x98 in decimal which is 152, for health we would look for 0xAF in decimal which is 175, and for speed we would look for 0x68 in decimal which is 104. We would specifically be looking at results who follow the format of storing data (opcodes using sw, sh, swc1, etc) at a specified offset which is 0x98, 0xAF, or 0x68 bytes away from the base offset in another register (usually s0). This will let us know that whatever register we are storing at the address specified contains a pointer or value for that specific actor attribute. In the case of damage charts we merely look up a ways for the occurence of a pointer to the .data section within an actor being stored within or register; for health or speed we will most likely have immediate values being stored within our registers. It is possible for our speed or health values to actually be stored within the .data section (although highly unlikely) of the actor so you will have to watch out, too. In the end, you really just have to watch for whatever is being stored into our register before the registers contents are stored at the address (0x98, 0x68, 0xAF, etc) in the actor panel.

 

The second method, which will most likely provide more precise results but may also give you the possibility of being farther away from where the register is set, is to look up external function calls to functions commonly used by actors when setting common attributes. In the case of damage charts we would be looking for calls to 0x8005C364 (jal external_func_8005C364) and for speed we would be looking for function calls to 0x800A51A0 (jal external_func_800A51A0).

 

... So those are the methods I usually use when looking up actor attributes. I usually start with actor panel attribute referencing and then, if I'm having trouble, I move on to attribute setting function calls.

 

More information on damage charts.

[HeavyZ]

I have no idea how to add actors to the game for an area. All I can do is replace them, and that means taking out another object you can live without to replace it with the object you want to put in. Oh yeah, I read the tutorial for adding actors. I didn't understand a word of it. I go into things like that and see a bunch of numbers and get freaked out, and then the tutorial itself assumes you know what they're talking about.

 

 

All you have to do is use the ZAO-ADD to add actors, use the program like you would to add an object/group number, but instead press 1, and then go in and change the actor with another program. The actor will be a purple flame by default. You will have to add a group/object number as well, unless there is one already in the area. The purple flame's object number is 0001, so there was no need to add a group number to get the flame into the area.

 

@ Jason777 if you're reading this maybe you could implement a feature to be able to choose what type of actor you can add. It would cut down time on using other programs, or having to repeatedly use the ZAO-ADD for one area. I don't even use the ZAP2 anymore I just use the ZAO-ADD, and then I change other things with the SayakaGL.

 

Back@ Griadrosich, you already know I've been having a tough time learning things. I would have never opened my mouth and said I was going to take on a full zelda hack project if I knew what I was getting myself into. Not only did I have to learn how to use a new program every day for a week, but I had to learn hexing. I was so thrown off because I would look up an offset like CE2EA6 and when I looked it up I got 00CE2EA60. Not knowing what the 6 meant in CE2EA6 I thought I had the wrong number. Yeah there are video tutorials for hexing zelda, but google OOT hex editing, or type it up in youtube. Try "Hex editing ocarina of time" only so many videos show up, along with any useful information, none of it is really noobie friendly.

Alot of people will give you an offset and not even mention how many bytes you should change or what bytes are for what, which is really bad if you are trying to edit colors, or values for other things. The only reason I've learned so much is because of this website, glitchkill, and the awesome people here who helped me out, no matter how dumb my question might have been, or if it took a really long explanation. It's almost like the more I learn the more I realize how much I don't know.

[Jason777]

(*(f32*)(RAM_Actor + 0x90)) : Proximity (distance from actor to Link) (RAM Offset)

 

Or...

 

 

AVAL(a, f32, 0x90)

I came to this discovery by looking at En_Arow_Trap. Airikita had said that the actor only fired arrows if Link was close enough and the only checks that the actor made to decide whether or not to spawn an arrow was if a timer had reached 0 or by checking a float value at 0x90 bytes away from the start of its actor panel to see if it was less than or equal to 400.0f.

 

data_809B3830:	addiu           $sp,$sp,-56 // make space on stack	sw              $ra,52($sp) // save return address	sw              s0,48($sp) // save S0	lui             $at,0x43c8 // AT = 400.0f	mtc1		$at,$f4 // F4 = 400.0f	lwc1            $f6,144(a0) // F6 = AVAL(a, f32, 0x90) (proximity)	or              s0,a0,$zero // S0 = RAM Actor pointer	c.le.s		$f6,$f4 // (proximity <= 400.0f) ? FP = 1 : FP = 0 	nop // nothing	bc1fl		$L000000 // if (FP == 0) goto L000000	lw              $ra,52($sp) // { Delay slot: restore return address }	lw              t6,336(a0) // T6 = AVAL(a, u32, 0x150) (timer)	addiu           t7,t6,-1 // T7 = T6 - 1	bne             t7,$zero,$L000001 // if (timer != 0) goto L000001	sw              t7,336(a0) // Delay slot: timer = T7..$L000001:	lw              $ra,52($sp) // restore return address$L000000:	lw              s0,48($sp) // restore S0	addiu           $sp,$sp,56 // fix stack	jr              $ra // return

Taken from: http://spinout182.com/mqd/En_Arow_Trap.S