Jump to content

Updates for Zelda OoT Actor List...

Airikita

By Airikita,
in Modifications

 Share

Recommended Posts

Airikita Mentor

Airikita

Posted
Posted (edited)

I've wanted to edit the Wiki and input this... but I'll just post my notes here:

 

Ganondorf:

 

Ganondorf Actor code:

017A - FFFF - 0153 + 017E (Will crash during cutscene without other group codes)

Other group codes: 0060 + 00E1 + 014F + 0048

 

- Ganondorf is a buttmunch with the group codes, but the useful ones are Zelda's group code and 00E1 (which I believe is Ganondorf's stuff).

- Zelda's group code is 0060, her actor code is: 004D - XXXX - 0060 (where XXXX can vary depending on the scene involved... she works like Malon in a way)

 

Also this is needed for Ganondorf's full cutscene:

0106 - 0023 - 00E1

- This is the controller for Link's, Ganondorf's, and possibly Zelda's actions during the cs.. it's a remote control for Ganondorf's battle cutscene, otherwise Link is able to move freely before the triforce appears on his hand.

 

I found that the organ MIGHT be necessary... I have not confirmed this:

00E8 - FFFF - 00E1

 

Multiple bosses that normally lag/crash under normal circumstances:

 

While some bosses will crash if their variable is not set to FFFF, bosses like Morpha and Gohma can be set to 0000, 0001, etc... Having one boss as FFFF, and the other ones set to 0000 or 0001, you can pile in multiple bosses without an expected overload that causes a crash or lag.

 

However, this does not mean that you can pile in 4 to 5 Gohmas (this has been tested) without a crash.

 

NOTE: I believe Bongo Bongo MIGHT have different variables that will work.. I remember from an old test when I found that he works with the drum if his hand's variable is set to FFFF was that there were other variables that caused a similar reaction to his hand (without the drum). From previous observations, I vaguely recall other variables caused a atmospheric change in the map he was in with certain variables other than FFFF (with the battle fully functional). Most variables with Bongo's hand and drum will cause a crash usually.

 

As far as I know/remember, Bongo Bongo only worked properly with FFFF, but possibly FFFE might work too (needs to be tested)...

 

Flame Circle Actor:

0049 - 6F03 - 0001

- if you pair up a flame circle with this variable, and add actor 0187 - 0FFF - 0001 to the map, when all enemies are killed, the flame circle will disappear with a victory sound. (MQ Only)

 

Nov 11, 2012

 

With my discovery of normal item drops (actor #0015), variable 00FF is confirmed to control seeds and magic pot drops:

 

This means 0015 - 00FF - 0001 will possibly generate a random inventory collectable such as seeds, magic potions, and maybe even arrows (according to theory).

 

Nov 16, 2012

 

I'm actually surprised this is not documented... however, in Z64, the actor 0189 is listed as "?". It is below the cursed family (skulltula form) and has not been updated. Looking at the House of Skulltula in UoT, I noticed that it's listed as the cursed family's human form:

 

Posted Image

 

I have not tested them in other areas, but I assume they use a unique group number too... may need to look at the House of Skulltula and use the group codes with actor code 0189 until one of them appears (needing more than 100 gold skulltula tokens to activate some).

 

More to come...

Edited by Airikita
  • Like 7
Link to comment
Share on other sites
Airikita Mentor

Airikita

Posted
  • Author
Posted

I've seen DeathBasket load up 3 Ghoma actors at once, but I was almost certain multiple different bosses would be impossible to get working because of conflicting cutscene data--looks like I was proven dead wrong. Very nice work, Airkita!

 

Yeah, 3 Gohmas isn't unlikely, it's just that the usual lag has been reduced from it.

 

There's some conflicts with Barinade being paired up with the other 2, but only when Barinade is freed from it's tendrils, and starts spinning. However, this is because both Barinade and Bongo Bongo share the FFFF variable, but neither will work without their variables set to FFFF.

Link to comment
Share on other sites
Airikita Mentor

Airikita

Posted
  • Author
Posted

This doesn't mean it's possible to make Bosses regular Enemies now...Does it? (!)

 

No... that would be a different issue involving AI hacking/manipulation. It's possible there's a command that can be seperated from its cutscene functions that can make it move freely.

 

Although, it DOES make them seperate entities.

Link to comment
Share on other sites
  • 4 weeks later...
  • 3 weeks later...
petrie911 Contributor

petrie911

Posted
Posted

"Flame Circle Actor:

0049 - 6F03 - 0001

- if you pair up a flame circle with this variable, and add actor 0187 - 0FFF - 0001 to the map, when all enemies are killed, the flame circle will disappear with a victory sound. (MQ Only)"

 

This is because 0187 0FFF 0001 links the clear trigger to switch flag 03, and flame circle 6F03 is attached to switch 03. If you want a flame circle attached directly to the clear trigger 0FFF works fine.

  • Like 1
Link to comment
Share on other sites
Jason777 Mentor

Jason777

Posted
Posted

This is because 0187 0FFF 0001 links the clear trigger to switch flag 03, and flame circle 6F03 is attached to switch 03. If you want a flame circle attached directly to the clear trigger 0FFF works fine.

 

Petrie, so if I'm understanding this correctlly, any puzzle-based actor (gates, doors, blocks, etc) can be added to clear trigger simply by adding in this actor to the map and adjusting the variables of said actors accordingly? If so, that's exactly what I've been needing for awhile.
Link to comment
Share on other sites
Jason777 Mentor

Jason777

Posted
Posted

Most of the basic actors can be. And, of course, any that can't can be forcibly attached through actor 0187.

 

Alright, one last question. What part of actor 0187's variable specifies which switch flag its attached to? The variable doesn't give away a whole lot but I imagine it's something like XXFF + (??00 * N) where XX is the switch flag... Or is not even within the variable but the XYZ rotation/coordinates?

Link to comment
Share on other sites
Jason777 Mentor

Jason777

Posted
Posted

That I haven't entirely worked out. It's not an obvious part of the actor variable. I'll look into this, though, as it does seem rather important.

 

Also, if you want to know about attaching actors to switches, you might want to read this

http://forums.zeldaspeedruns.com/index.php?topic=419.msg9465#msg9465

 

I added that document to the Wiki awhile ago and have slowly been adding onto the puzzle actor list...: http://wiki.spinout182.com/w/Modification_and_Addition_of_Switches

Link to comment
Share on other sites
Airikita Mentor

Airikita

Posted
  • Author
Posted

Airikita, the wiki should be usable now if you use OpenID.

 

I wish I could just say "I'll get right on it", but I'm close to exams, and my task skills are lacking. Although I have plenty of spare time, the stress of college has been getting to me lately... I also have some other things I need to do before I get back to hacking, and I plan on starting a new project during the winter holidays while there is plenty of time to learn something new.

 

That I haven't entirely worked out. It's not an obvious part of the actor variable. I'll look into this, though, as it does seem rather important.

 

Also, if you want to know about attaching actors to switches, you might want to read this

http://forums.zeldas...msg9465#msg9465

 

I found some code bits in actor files that link them to switches and clear triggers... but I do not remember if they are all co-related. Some I have found within the actor's assembly data, some of them have lines placed in a free slot after their assembly codes.

 

It's possible that the flag is linked to an address that determines the number of enemies to consider as actual enemies to use as a counter. I made the Iron Knuckle have a green target at one point, and killing it did not activate the barred door to open, but switching the ik back to normal allowed the door to react to the ik.

 

It's useless, but it may point to the location of the flag for that; I could give you that part of my notes if you're interested.

Link to comment
Share on other sites
Jason777 Mentor

Jason777

Posted
Posted

I seem to have figured actor 0x0187's variable and how to have it attached to a switch flag. I haven't yet tested it (I'm in school), but after looking at the disassembly of the actor's initialization function for a few minutes I'm pretty sure this is correct.

 

After all this arithimetic, the Variable should be equal to the switch flag of your desire...

(Variable >> 10) & 0x3F = Switch Flag
OR...

 (Variable >> 10) = Switch Flag

For example, variable 0x0FFF attaches to switch flag 0x03...

(0x0FFF >> 10) = 0x03
(0x03 & 0x3F) = 0x03

If anyone wants an explanation of how I figured it out, I can post a complete disassembly and commentary on the initialization function. Anyways, I'll update this post later today to see if it works.

 

EDIT: Yup, it works.

 

So here's how you should set up actor 0x0187's variable... Only a little bit of math is required:

(Everything should be in Decimal Format)
XX = Switch Flag
((XX + 1) * 1024) - 1 = Variable

Why do we multiply by 1024? Well 1024 is equal to 2 to the 10th power. We simply reversing the rightward bit-shift of 10 bits. 

(Approximation)
Variable >> 10 == Variable / 2^(10)

(Reverse)
Variable * 2^(10)

Why do we add one to the switch flag at the very start and subtract one from the result at the very end? Well, this is to take care of floating point issues since were only using unsigned 16 bit integers.

 

In the end were basically reversing the arithmetic to solve for the variable:

(Variable >> 10) & 0x3F = Switch Flag

Convert the variable back to hexidecimal and you should be good! For example, let's say we wanted to attach switch flag 0x38 to a clear trigger. We would play actor 0x0187 in the map and then set our variable to 0xE3FF...

0x38 = 56 in Decimal
56 + 1 = 57
57 * 1024 = 58368
58368 - 1 = 58367
58367 = 0xE3FF in Hexidecimal

SOURCE

 

Disassembly of actor 0x0187's initialization function with comments:

data_80B9CFD0:
    sw              a1,4($sp)  Preserve a0 in stack + 0x04
    lh              v0,28(a0)  v0 = Actor Variable
    li              $at,1023  $at = 0x03FF
    lui             t0,%hi(data_80B9D054)  t0 = upper part of address of function_80B9D054 in RAM
    andi            t8,v0,0x3ff  t0 = (v0 & 0x03FF)
    sh              t8,28(a0)  Actor Variable = t8
    sra             t6,v0,10   t6 = (v0 >> 10)... sra is used for signed variables
    lh              v0,28(a0)  v0 = Actor Variable = t8
    andi            t7,t6,0x3f  t7 = (t6 & 0x003F)
    sw              t7,336(a0)  Actor + 0x150 = t7
    beq             v0,$at,$L000000  if (v0 == 0x03FF) goto $L000000
    addiu           t0,t0,%lo(data_80B9D054)  Delay Slot: t0 = lower part of address of function_80B9D054 in RAM
    slti            $at,v0,601  $at = (v0 < 0x259)... I do not know why this matters
    bne             $at,$zero,$L000001  if ($at) goto $L000001
    li              t9,600  Delay Slot: t9 = 0x258
    b               $L000000  Default: goto $L000000
    sh              t9,28(a0)  Delay Slot: Actor Variable = t9
$L000001:
    sh              v0,28(a0)  Actor Variable = v0
$L000000:
    jr              $ra  return
    sw              t0,332(a0)  Delay Slot: Actor + 0x14C = t0

I basically was paying attention only to arithmetic was that performed on the variable and noticed how the original value of the 16-bit variable was shifted to the right 10 bits... which left only 6 bits to take notice of. I then realized that the highest value possible out of 6 bits is 0x3F which happens to be the last switch flag available. Then I noticed that t7 held the value of the switch flag after all the arithmetic was performed and stored it at (*(uint_16*)(Actor + 0x150)). Really, the arithmetic of (t6 & 0x3F) was unnecessary so t6 actually holds the final value. Also, (*(uint_16*)(Actor + 0x150)) seems like an area of the actor that holds what switch flag it's attached to and (*(uint_16*)(Actor + 0x14C)) holds a conditional function jump?

 

EDIT2: Variable arithmetic in hexidecimal...

 

XX = Switch Flag
YYYY = Variable

((XX + 1) * 400) - 1 = YYYY
Link to comment
Share on other sites
Jason777 Mentor

Jason777

Posted
Posted

Jason, you should post video examples of how this could be used, I am really interested, and this is too much information for my mind to handle at once.

 

Heh, this all you need to know to be able to use the actor:

EDIT2: Variable arithmetic in hexidecimal...

 

XX = Switch Flag 
YYYY = Variable 

((XX + 1) * 400) - 1 = YYYY

I do plan on making a video, though.

Link to comment
Share on other sites
Jason777 Mentor

Jason777

Posted
Posted

I have a few more actors I've catalogued that I haven't put in that post. Is there a chatroom associated with this site?

 

There is indeed! If you haven'g noticed the bar at the bottom of the browser which tells who is online, there is a chatroom you can log into there.

Link to comment
Share on other sites
petrie911 Contributor

petrie911

Posted
Posted

I was thinking more along the lines of an IRC channel. We have one set up if you're interested.

 

Anyways, the Water Jet actor from the water temple, in all its glory.

 

015F YZZZ

 

Y is 1 for lowering and 0 for raising.

ZZZ = XX WW

 

XX is the 6-bit switch flag.

WW is the 5-bit chest flag.

 

Raising jets have no chest variable, and you should use 0x1F for them. Lowering jets disappear when the relevant chest flag is set.

 

For lowering jets, the X rotation is the height of the jet, in 40 unit intervals. The Y rotation is the timer, in seconds.

 

For raising jets, the jet always rises 400 units and has a timer of 15 seconds.

 

For both jets, the Z rotation is the size of the jet. This is a signed value. Negative sizes do not push Link upwards, while positive sizes do. Jets get very large quickly. Sizes above 10 not recommended.

Link to comment
Share on other sites
spinout Rising Star

spinout

Posted
Posted

A long, long time ago, before model importers were conceived, I made a dungeon. I took 119's second room (the one I use in test videos), and copied it about 16 times, each time making a different room. I did doors and reworked the scene and collision and everything. It was jawesome. (Golrious UoT shot)

 

Anyways, at one point I tried having a puzzle that required the water to be horizontal. Now I finally know why it didn't work. Awesome info, get it on the wiki!

Link to comment
Share on other sites
Three_Pendants Rising Star

Three_Pendants

Posted
Posted

I'm surprised a Zelda 1 Remake hasn't been attempted with OoT yet. In Essence it doesn't seem too complicated. A few things would need added or removed and some things just wouldn't apply (The raft comes to mind). However there's a lot of potential in the old Zelda 1 room layouts. They're simple but a lot can be added within and they're much easier to work with than a normal 3D dungeon.

Link to comment
Share on other sites
Jason777 Mentor

Jason777

Posted
Posted

I'm surprised a Zelda 1 Remake hasn't been attempted with OoT yet. In Essence it doesn't seem too complicated. A few things would need added or removed and some things just wouldn't apply (The raft comes to mind). However there's a lot of potential in the old Zelda 1 room layouts. They're simple but a lot can be added within and they're much easier to work with than a normal 3D dungeon.

 

JSA did recreate the Eagle dungeon in OoT :P But yes, I imagine that a Zelda 1 mod would be a lot simpler than any other mod.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.

  I accept