spinout

Jason777 hit the nail on the head. The data isn't stored in ROM, it is built in RAM. Changing assembly is needed - I wish I still had the source to the patch Jason777 linked to.

If anyone has savestates with maps/scenes/whatever you want ripped, I can be of assistance.

Jason777, do remember that nOVL 'skipping' an address isn't a bad thing - it only handles addresses within the actor's VMA.

z64tables support? I posted in the topic a quick way to check for the hack.

Try to avoid using variables in that manner (Collision and En_Arrow_Trap) - they end up in the .data section. Instead, use the AVAL macros on whatever space isn't used in the actor panel. EDIT: Also try running nOVL with maximum verbosity - command line -vvv option. It may give you more insight as to why it is crashing.

Uh, GANONdork123 is site owner. Flotonic and JohnnyBoy146 are admins, with 'Link' and TJ the HedgeScout as moderators. Seems like an arm of maco, perhaps? Definitely not the original URA team. Also, required registration for the forums? What is this, 1984?

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.

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.

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.

I think the idea was: if( lost_woods ) { behavior_a; } else if( kokiri_forest ) { behavior_b; } Unfortunately for us, they didn't code it: if( lost_woods ) { behavior_a; } else { behavior_b; }

I *believe* if you change the value at 0xE4E9D0 in ROM (0x1BB4 in En_Ko) from 0x5061 to 0x1000, and the value at 0xE4EE48 in ROM (0x2028 in En_Ko) from 0x1041 to 0x1000, they should load in any scene. These two instructions basically change beq (branch if equal [to scene number in this case]) to b (branch unconditionally). If you'll notice, the previous instruction sets the scene number to load them to - this instruction is now useless. The offsets to change for the lost woods kokiri are 0x1AF0 (0x55810020 => 0x00000000), 0x1B94 (0x1061 => 0x1000), 0x201C (0x1041 => 0x1000), 0x242C (0x55C1000B => 0x00000000). Add 0xE4CE20 to all these offsets to get ROM offsets. Warning/Disclaimer: I haven't tested this, and it should be thoroughly tested with all potential variables. Based on the code, it looks like some variables yield different results depending on the scene number (e.g. a kokiri in lost woods is different than one in the kokiri forest even with the same variable!)

ZLE 1 also edits landscapes. It's where collision_fixer.exe comes from. xdaniel, some simple features missing from current editors is exit modification and entrance index modification (start pos : room # list)

Is the data properly loading into RAM?

Do the animations reflect the changes made to the hierarchy? Animations are hardcoded based on how many limbs are in a model.

I'll take a look at the scene file. EDIT: I've been working with this for quite some time now, seems I finally figured it out... The game somehow knows approximately or exactly (?) how many collision triangles are supposed to be in a particular scene. I changed the number of collision triangles in the collision header to exactly as many as the Kokiri forest has and - it loaded right up. That good feeling when you get something other than a black screen after pressing 'a' on level select, after hours of frustration... EDIT2: If the function at 0x8003BF18 returns 1, the map will not load with all the triangles. If it returns 0, it will load fine (?) EDIT3: this function is definitely a switch case case case case default function: EDIT4: This function was definitely handwritten in MIPS assembly by someone in Nintendo - someone who didn't know their stuff. A few instructions are completely unreachable unless there is stack smashing or other nefarious activity going on. And it shows that this function is poorly written - it's callee has many special case handlers which print out debug text (how I wish I had a proper m64+ setup!)

SanguinettiMods, what actor are you using, and what are the original and new hierarchy offsets? Or is this a more general question?

The entrance index is automatically generated by SharpOcarina, it sounds like. Does your map have multiple entrances? Do they have an equivalent in the Kokiri forest? Or is it just a test map? Try putting in 12 starting positions and your map *should* load

It isn't cutscenes that's plauging the game. The engine is loading the wrong data for the entrance index list. Try adding more start positions, or edit the exit table so that the entrance you're using is start position #1. Kokiri forest has at least 11 start positions. First, the engine is reading false data for the entrance index, then trying to load random data from the link positions list.

xdaniel: if( u32(rom_data, 0x1238) == 0x0C00084C ){ regular rom...} else { extended tables... } New release in a few minutes. Or something. EDIT: http://spinout182.com/ar/z64tables_r2.7z

Thanks for the comments. xdaniel,in the next release I'm planning on moving the hack into 'code', where the now-unused tables are. I think that'll take care of CRC issues as well. EDIT: also, xdaniel, as far as hack presence or not, a quick and easy way to check is by checking the JAL to my code - will provide some more details in a bit.

b-b-beautiful. I haven't seen textures so good from a sketchup model in quite some time.

Hello! I haven't made a release (or let alone worked on Z64!) in a while. Today was different. I dropped into #z64 (on freenode, you should check it out!), and wareya was looking for some space to put his assembly. I told him to put it in code, over debug text, but he didn't like that answer. He wanted me to extend code. An hour or so more of research showed that loading anything more into code broke the game; the save file is loaded right after it and the rest of the game is coded around code and the save file being exactly where they are. So how do we fit more into code? I went back to an old idea I had about adding more scenes: move the scene table outside of code. But why stop there? Might as well pull the other tables out too! A bunch of research finding all the pieces of code which reference all those tables, some good ol C and python, and the rest of the day later, I got the game to run using tables loaded via an alternate method. What does this mean? It means: Up to 819 scene files. MQ Debug, by default, only has 109. Up to 1536 actor files. OoT, by default, only has 470 actors. Up to 512 objects. OoT, by default, only has 401. Okay, I can up that if you really need more. Up to 31,744 exits! OoT, by default, only has... 1556. (Note: Cendamos told me the engine rolls the number over after a certain point, if so, I will fix this in a future release.) Up to 32.7kB (that's kilo-bytes) of whatever you want to always have loaded! It also means that the tables for these can be modified as individual files, which will certainly make ROM hacking easier. Willing to check it out? [EDIT: Release 2]

If well coded you could just keep throwing in little features, but the idea of starting out with something barebones is a very good idea.

While I do understand there is interest in this hack, it is not at all practical in it's current configuration. OoT was designed to have one screen, one link actor. Anything else brings up undefined behavior - look at the action button in any 4 player OoT video. That being said, good luck to anyone and everyone who works with the hack I made.

I wish I had this kind of motivation and time. It's looking awesome, and I bet it will continue to. Projects don't get this big without good code; once they are this big they can usually continue to develop in a sane manner. My only wishes would be source and linux compatibility but hey those don't really mean adaptation by a community of modders/hackers. Flotonic, keep it up. Your hard work will pay off.