john_smith_account

I don't think it would cause a noticeable drop in performance. After all, the retail versions are compressed, and we can't a difference in performance between those and the Debug ROM right?

The rumor that the order has to be correct is just that, a rumor. DMA problems were blamed for early attemts to compress the debug ROM failing, when it turned out in the end to be the faultof the compression tool we were using. It might be true that the table can't have gaps in the compressed entries, and it is certainly true there can be no over laps in mapping values. The order does not have to be correct ...BUT... the DMA map will automaticly end when it reaches the first zeroed out entry, 00000000 00000000. We didn't know that at the time. Therefore, as a work around, the first compressed debug ROM has repeated DMA values within the table to over write DMA entries of files that were removed. Sloppy, Sloppy Sloppy. But it proves file order does no have to be correct. The DMA issues are simple to over come, and are best fixed up as a final step of releasing a ROM mod. To make it simple to mod the ROM, use the patch I posted long ago. It ends the DMA table early(directly after the last address you absolutly need an entry for), and also fixes the CRC of the new table. This removes almost all the mappings you can do without. Without the table, the game reverts to using whatever actual physical address you give it. When you mod is complete, then you can make new entires in the DMA tables for new files. Then you fix the CRC, and *BOOM* your mod is ready for real hardware/picky emulators. As a side note, the retail ROMS will accept decompressed entries as long as you fix the CRC, and as long as they fit within 32-megs. The orginal translations of the level select menu proved that. P.S. I'm still feeling like death warmed over(sadly very literal), so if you write me don't expect a fast response.

EDIT: OK, feeling better now, here goes. I'm having serious health problems. My doctor is in the process of figuring out what the root cause is. I've been in a ton of pain, and they still don't know exactly what the cause is. They have a general idea, and have even had some success treating it. I'm in much less pain for now, but I've been warned the current treatment will not last. I posted "I might die" earlier. I apologize. Though I am in a lot of pain, and my condition *is* life threatening "I might die" is so much drama it's stupid. But I am very, very ill, and I do have to get this figured out, and treated. I haven't been around, and I might not be around in the future. I'll try to lurk like I always do, but honestly I feel like crap and I can't concentrate like I used to. Say a prayer for me if that's your thing, if not wish me luck. Thanks, and happy hacking everyone. john_smith_account

Like I keep saying, I'm very dissappointed in the cutscene format. I was expecting direct control over animations of cutscene actors. Oh well, I guess we can write new animations for existing cutscene actors easy enough.

YAY!

Any luck with 0024 0040 ? (ovl_En_Scene_Change) Uses Jabu Jabu Obj yet?

Ah, well that cannot be fixed in code but there's already a way around it. Set your debug cam up, and toggle it on before you start selecting actors. That way, your view point will remain within your control. I works out much better when you do it this way most of the time. You'll know when you've selected the correct actor, because the actor which current has the point of view will have a "virtual" camera fixed on it. I'll get a pic up later. Anyone have the page on setting the Debug ROM setting along with debug cam option?

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?

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

*Chants* ONE MORE TO GO!!! ONE MORE TO GO!!! ONE MORE TO GO!!! :D

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

Alright then. How are 0024 0040 ? (ovl_En_Scene_Change) and 002C 0003 ? (ovl_Bg_Pushbox) coming along? I thought I saw someone in shout box talk about using another actor to spawn 24.

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. Actually I was wrong about the variable... arow_trap is finnicky. Not only does Arow_Trap trigger randomly on a timer (which can reduce the chances of activating it, which is stupid) the trap is also proximity activated, meaning if Link is too far, the arrows will never spawn. The reason I thought it needed FFFF was because of when it worked during a test. If you get rid of two conditions, it will work all the time. It's stupid, and Nintendo really messed it up. I agree! We should request they fix it so we can use it in mods.

As usal, Three can find anything in the game he wants. Good job.

Keep it up, and you're going to have me hounding you to modify Adult Malon's event checks(and there's plenty of them) for the ZB2 project.

Yes, Yes... YES!!!! This may go down in Zelda Modding history as the best week ever. Great work, and congratulations to the both of you.

Xu(Three_Pendants), how could you have forgotten this? You showed me this long ago. Ovl_Effect_Ss_Blast Is spawned by any actor that blows up. ovl_Effect_Ss_Stone1 Is the deku nut stun. *You* taught *me* this stuff, it might even be in those notes I sent you. Don't you remember it at all? Fantastic work! You've most likely discovered the very last beta actor there is to be found. The fact that it might be useable is icing on the cake. I can't watch the vid right now(dialup), so *is* the modified version usable?

*REMOVED*

Um, uh, um....I didn't mean to....I was just, you know....I didn't mean it to .... ... Sorry if I came off as rude. I meant it as funny. I don't take any of this too seriously, so I don't expect anything I say here to be taken too seriously either.

Well, I guess if Dark_Link-77 ever gets time to come back, he could port all of MM into OOT now. Great work as always spinout.

WRONG!!!! You're creating a map prone to errors. You fail OOT map making 101! From my notes, that type is 012 for easy reference: When importing the map in Sharp Ocarina, at the desired collision set, select "Killing Quicksand" and change the Raw Data "18" to "12." Correct! A+ Thanks for posting the correcting value, you really helped me out too.

I find this interesting. A heads up in case it's not documented yet, some actors are damaged by throwing actors 0110 crates at them, but I don't know if all actors are. You might want to check on this in your research. It would be nice if we could mod the rocks, and pots to damage foes like in lttp.

Eh Gads! The shop keeper you're using had pre rendered background (set via a "skybox") to create his shop. This afforded the programmers to be able to pull some tricks with the perspective that won't work on a regular map. I don't think you can "fix" this. Sorry.

Footprints On My Ceiling - Social Distortion