Jason777

Here's what I would do... Apply this patch: http://z64.googlecode.com/svn/n64/misc/a+cinterface/a+c.ppf Do a file compare with the patched ROM and a normal clean ROM. See what changes were made in order to achieve that effect. In the end, it likely has to do with changing the contents of a register in assembly.

Will you be uploading the source for this mod, too?

That's what I was originally planning... I was going to make a few modifications here and there to en_arow_trap (remove the timer, remove proximity check) and then I was going to write a custom actor with collision, aiming, and a model which spawned en_arow_trap through its initialization function. Currently, both are done but the custom actor is running into some problems upon compiling. EDIT: Alright the problem with collision is that nOVL seems to be handling virtual addresses as out-of-bounds memory addresses. I was under the impression that it should only be doing that for addresses that are less than or equal to 0x807FFFFF (within the range of absolute RAM addresses). As for spawning, I don't quite know why that isn't working correctly, yet. As you can see in the picture below, nOVL starts by looking for relocations in the main function and then proceeds to look for more in the display function. Upon finishing its search it encounters a function call to func_8005dc4c and crashes upon scanning the delay slot. I say the delay slot because it follows immediately after the function call... that's a guess though. Yeah... writing the custom actor in assembly seems like the only option at this point. EDIT 2: Funny. I commented out one of the AVALs in the display function and the actor compiled. However, looking at the log given off by nOVL still shows how messed up it is: Well, apparently the function prototype for the spawning function was incorrect. Spawning may be possibly fixed now; nOVL recognizes the function call to 0x80032458, but I have yet to test it. EDIT 3: Alright well it turns out that spawning was working correctly but XYZ placement was not. The only thing that this actor lacks is collision... How does a progress video sound to you all?

This sounds surprisingly similar to mod idea that I had always wanted to create... I will definitely be keeping a close eye on this!

What are you talking about? Savestates?

(*(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 // returnTaken from: http://spinout182.com/mqd/En_Arow_Trap.S

Macaroni... Dat cheese.

You and Flotonic collaborating will probably lead to some very interesting things

Tasty...

Honestly, I think I may have to straight-up write the actor in assembly; I'm experiencing issues with both nOVL and GCC's MIPS C compiler that I think can be avoided if I just choose not to write it in C. I think that in the end it may be an issue with nOVL and relocation data so I don't know if I'll be able to fix it entirely. Maybe there's something I'm not doing correctly here... Any of you who are experienced in writing actors in C might be able to find somewhere where I messed up. There are a lot of commented out things that I was mainly using for testing purposes. For some reason whenever I try to save the pointer that is returned by func_80032458, spawning no longer works correctly. There's also the issue of nOVL crashing whenever I try updating collision sphere placement... This is where it fucks up: Here are macros that one may need to know: ... And here's the modified en_arow_trap actor with its timer removed (for those who care):

I love you, DeathBasket. Well, now that I have aiming working correctly, I have encountered one last problem: collision. While implementing function calls to initialize collision (DeathBasket, you sent me a PM on this a while ago), nOVL simply crashes when I try converting the ELF to an overlay. There are no error codes, etc; nOVL just "stops responding".

I think a cool thing to add to this would be a small guide on how to import the MIDI into the ROM.

That's what I meant when I said that inverse trig functions have yet to be found. We have normal functions like sin, cos, and tan... but the locations of arcsin, arccos, arctan are still unknown.I know of no straightfoward to way to find angles that aren't already defined in the unit circle.

Well, I finally set aside some time today to work on the custom actor to utilize en_arow_trap. Everything works at this point except for one thing... aiming. I barely realized that inverse trigonometric functions have yet to be found in OoT I tried to work around this by having the actor copy Link's rotation and then apply a complete 180 degree turnaround to be facing Link. However, I don't think that would be effecient because if Link simply faces away from the actor then the actor is no longer facing Link... On a related note, would anybody be willing to create a simple custom model for the actor to use? I'm currently planning on replacing the beta vase model. I was thinking of something along the lines of a scary-looking totem pole.

That's just some random guy who is trying to create something well beyond his capabilities. And I'm pretty sure Flotonic isn't actually part of that... He probably just joined the forums to see if there was anything interesting and then never went back.

Fuck.

Nothing?

As soon as I get some other things done, xdan, would you mind guiding me through the source code of SharpOcarina so that I might correct certain bugs? I imagine it would help relieve some of the weight of expectations people have for you. EDIT: Well, this is all assuming that I'm knowledgable enough to fix said issues.

I'll be sad to see you and your work go, xdan. Good luck with your other endeavors.

Keep 'em coming, Strati.

Sorry for the late reply; I have been rather busy this week. However, I do have time tomorrow so I would just like to get a couple of things straight before I begin writing the actor... So I would have to change the arrow actor's variable that is spawned to 0000? Or are you saying that I have to spawn ovl_En_Arow_Trap with a variable of 0000? I noticed that 0x50 (80) frame timer, too. Simply getting rid of the timer get's around this issue, yes? Here's what I'm getting from this: I would need to spawn ovl_En_Arow_Trap only once to avoid Link being scewered by multiple arrows... I assume I would be using the normal ActorSpawn function (0x80031F50) or would I use the actor dependent one? (0x80032458)Aside from that, I need to add aiming...I hope you don't mind all the questions, I'm just making sure before I start writing it tomorrow.

Sonic X-Treme has been brought back from the dead!

Great job on the map. The only thing that needs a little tweaking is the Deku Tree's leaf textures; they look low-quality compared to everything else.

I could add in the functionality for the trap to aim at Link if anybody wanted me to. I could even write an actor which utilizes it. Would anybody be interested?