I challenge everybody...

[john_smith_account]

*REMOVED*

[john_smith_account]

I really never dreamed the last two actors would be so difficult.

[Airikita]

I think that's part of why they're still sitting there. Something is wrong with them, so we could never activate them as-is.

[Airikita]

Behold, ovl_Bg_Pushbox:

 

Needs to be changed from group 0003 to 0082 (object_pu_box), which requires modification to make it work, but it's a 2-byte change.

 

It can't be pushed, but it's the proper object file, like it should be. I was running my mind crazy when it was such a small change.

[Three_Pendants]

Fantastic work Airikita! Only one more to go now and the Actor List will be complete!

[john_smith_account]

*Chants*

 

ONE MORE TO GO!!!

ONE MORE TO GO!!!

ONE MORE TO GO!!!

 

:D

[xdaniel]

UoT... Oh well, someday we might be able to move on -.-

 

Regardless, good job uncovering Pushbox and the others!

[spinout]

UoT... Oh well, someday we might be able to move on -.-

 

Regardless, good job uncovering Pushbox and the others!

This is how I feel when I read 'group' instead of 'object'. To a lesser extent though...

 

Re: En_Scene_change: I rewrote it in C. It doesn't seem to be much more than a fancy graphics allocator - it allocates 120 (120, as in 120. NOT 0x120!) display list commands, puts them at the end of the next frame's display list as segment 0x0C - and doesn't do anything else. Of most interest is it's object number, 0x0040 - object_jj - Jabu Jabu. Why does jabu jabu need 120 display list commands, in segment 0x0C? I don't have a clue. Jabu Jabu doesn't seem to have a spawner for this actor either.

 

sauce

 

EDIT: OH SNAP JUST NOTICED

A few of the functions called have line numbers (for debugging purposes). My RE'd copy, very heavy in comments, had fewer line numbers than the disassembled actor supposedly had. Meaning the original source file (the one at Nintendo) has a lot of comments - probably most of them code, which was therefore code omitted from OoT builds.

Edited June 6, 2013 by spinout

[Three_Pendants]

While reorganizing the wiki page for the Complete Actor Listing to provide actual Representation I happened upon several more skipped over and uncertain actors.

 

First will be the skipped over actors as I think these have the most potential. 

 

 

0048 (0x0030) 00D75660 00D76290 809BC030 809BCC60 0019 3.0468 ovl_En_Bdfire              King Dodongo's Fire

 

0030 is a skipped one on the list and is only summoned by King Dodongo shooting a burst of flame. Now in an attempt to find their variable I changed them into Treasure Chests and the first treasure chest he loads causes the game to freeze when opened meaning that it it likely a 00 (or above 13) FC,FD,FE, or FF. The rest of the chests were large grab chests meaning that their variable was likely 00. There are more empirical ways to test those, but I wasn't thinking straight apparently, heh.

 

Secondly is one I could not figure out...

 

0109 (0x006D) 00DC5E50 00DC8810 80A0F260 80A11C20 005A 10.437 ovl_En_Fhg_Fire - fHG is the name given to Phantom Ganon's Horse, but at no time during the battle does it actually attack. I switched the actor with an easily identifiable spawn (Flame) and saw that it was spawning at the Very Top of the real Phantom Ganon painting when Phantom Ganon chooses his paintings anew, but I saw nothing unusual and the fight went on as normal. This is a hefty file at 10.5 KB roughly so I can't just believe that it has no function. This is definitely worthy of more exploration.

 

That covers the unlisted actors completely now (ironic they would all be boss spawns)

 

Finally there is OE2 which shouldn't just be a Lock-on Blue Spot,considering it has a group called OE2, But! It's file is so extraordinarily small that may be the only functionality it has left.

 

0079 (0x004F) 00E74710 00E747D0 80ABE6A0 80ABE760 0035 0.1875 ovl_En_OE2                 Lock-on Blue Spot? (Unknown)

 

So we are technically either 2 or 3, rather than 1 away from completion as of the moment.

[john_smith_account]

 

UoT... Oh well, someday we might be able to move on -.-

 

Regardless, good job uncovering Pushbox and the others!

This is how I feel when I read 'group' instead of 'object'. To a lesser extent though...

 

Re: En_Scene_change: I rewrote it in C. It doesn't seem to be much more than a fancy graphics allocator - it allocates 120 (120, as in 120. NOT 0x120!) display list commands, puts them at the end of the next frame's display list as segment 0x0C - and doesn't do anything else. Of most interest is it's object number, 0x0040 - object_jj - Jabu Jabu. Why does jabu jabu need 120 display list commands, in segment 0x0C? I don't have a clue. Jabu Jabu doesn't seem to have a spawner for this actor either.

 

sauce

 

EDIT: OH SNAP JUST NOTICED

A few of the functions called have line numbers (for debugging purposes). My RE'd copy, very heavy in comments, had fewer line numbers than the disassembled actor supposedly had. Meaning the original source file (the one at Nintendo) has a lot of comments - probably most of them code, which was therefore code omitted from OoT builds.

 

 

That's incredible work, and probably the only way to figure out a problem actor like this one. 

 

Still, I feel defeated.  Maybe I'm not understanding but, it sounds like we will never have a clear idea of what this actor does or did?

 

Are we sure group 0040(OBJ 0040, happy?) is really the correct group?  I hate to end with the last actor on the list being labeled as:

 

Broken,  original function unknown

 

[xdaniel]

Are we sure group 0040(OBJ 0040, happy?) is really the correct group?

According to the actor itself, yeah. Says so right in its header, see near the end of spinout's C rewrite. And, out of curiosity, I checked NTSC v1.0's files and that version of Scene_Change - file 0056_00B60080-00B60170.dec in an OZMAV2 dump; file #56 in DMA table, zero based - is even shorter than the Debug ROM one (0x130 bytes vs 0x1B0) and uses the same object number, 0x0040. *goes back to semi-lurking*

[spinout]

 

Are we sure group 0040(OBJ 0040, happy?) is really the correct group?

According to the actor itself, yeah. Says so right in its header, see near the end of spinout's C rewrite. And, out of curiosity, I checked NTSC v1.0's files and that version of Scene_Change - file 0056_00B60080-00B60170.dec in an OZMAV2 dump; file #56 in DMA table, zero based - is even shorter than the Debug ROM one (0x130 bytes vs 0x1B0) and uses the same object number, 0x0040. *goes back to semi-lurking*

 

Likely because it doesn't have the debug text built into it, and the related calls which use it.

[john_smith_account]

 

Are we sure group 0040(OBJ 0040, happy?) is really the correct group?

According to the actor itself, yeah. Says so right in its header, see near the end of spinout's C rewrite. And, out of curiosity, I checked NTSC v1.0's files and that version of Scene_Change - file 0056_00B60080-00B60170.dec in an OZMAV2 dump; file #56 in DMA table, zero based - is even shorter than the Debug ROM one (0x130 bytes vs 0x1B0) and uses the same object number, 0x0040. *goes back to semi-lurking*

 

 

I'm not convinced.  After all 2C had the wrong group listed right in the actor.

 

UPDATE:

 

I have more supporting evidence it's pointing to a group(OBJ file) that changed during development.

 

003B : 0120A000-0120C130 : object_oA3  003C : 0120D000-0120E730 : object_oA4  003D : 0120F000-012106B0 : object_oA5  003E : 01211000-01212A00 : object_oA6  003F : 01213000-01214550 : object_oA7  

 

0040 : 01215000-01220AC0 : object_jj   

 

0041 : 01221000-012227B0 : object_oA8  0042 : 01223000-01223520 : object_oA9  0043 : 01224000-012280E0 : object_oB2  0044 : 01229000-0122D490 : object_oB3  0045 : 0122E000-0122F870 : object_oB4

 

Doesn't anyone else find it more than coincidence that we're dealing with a potential broken actor which calls a OBJ that lies right smack in the middle of list of obsolete OBJs?  I propose the file didn't originally point to the Jabu Jabu OBJ. 

 

If we're lucky, just like actor 2C, it might be we can re-point the actor to it's lost OBJ. 

 

Feedback?

[spinout]

Even if we do find it's long lost object, it won't do much of anything. The only possible way it may do something is if external_func_80093D18( *(uint32_t*)(ctxt) ); happens to do some sort of trickery to load the object using the allocated display list.

[john_smith_account]

[Airikita]

You guys are thinking too hard about this without trying different things to figure it out.

 

I haven't had time to look at it myself, but breakpoint everything in it, and see if it breaks after execution.

[Jason777]

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.

[Airikita]

Jason777: why not grab Link's position, then use the arrow trap's position to create a line to Link, then rotate it to face parallel to that line? There are trig commands in MIPS.

[Jason777]

Jason777: why not grab Link's position, then use the arrow trap's position to create a line to Link, then rotate it to face parallel to that line? There are trig commands in MIPS.

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.

[Airikita]

 

Jason777: why not grab Link's position, then use the arrow trap's position to create a line to Link, then rotate it to face parallel to that line? There are trig commands in MIPS.

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.

 

Would not a negative value work? I think there's still a way around it... maybe you will need to subtract.

[xdaniel]

There might not be asin, acos and co. available, if the SDK documentation is any indicator - http://naesten.dyndns.org:8080/psyq/man/math/math.html - unless the developers specifically added those to OoT's code.

[Airikita]

I've been looking at Scene_Change, and it seems to handle a lot of graphic-related functions, and effect changes. Perhaps Scene_Change doesn't deal with an object file, but a different reference. 0040 may not even be an object file.

 

Of course, this doesn't make sense either way... in essence, there is no way to tell if this is even a possibility.

[Three_Pendants]

There is one strange thing I noticed but I'm not sure if its an isolated incident. When looking at the info. of the Scene_Change in RAM I had changed the object that should have been loaded with it to another number but there was still a 0040 loaded next to a copy of the Actor and Object reference in the Actor's info. when changed it acted as an accumulator, Changing it to 40, would change it to 80. It always seemed to be a 40+ accumulator and finding the base of that accumulator did not help or change anything.

[Airikita]

There is one strange thing I noticed but I'm not sure if its an isolated incident. When looking at the info. of the Scene_Change in RAM I had changed the object that should have been loaded with it to another number but there was still a 0040 loaded next to a copy of the Actor and Object reference in the Actor's info. when changed it acted as an accumulator, Changing it to 40, would change it to 80. It always seemed to be a 40+ accumulator and finding the base of that accumulator did not help or change anything.

Okay, what were the actual object numbers when the original was changed (without altering it)??

[Mallos31]

Kinda a long shot, but you might see if you can find anything in the code for the Beamos that makes it aim at link. Use that as a reference. 

[Three_Pendants]

The actual Object Number at the time was 3E in the thought that maybe it was trying to use one of oA models.