Arcaith

Though her bust is...*ahem*...a little loose. Interesting to see the way the models are divided up. I guess all the physics weighted bones are separated from the main model. Probably something to do with the way the physics and collision calculations are applied.

The game checks the scene number, scene offset and checks whether or not the required object is loaded. The additional object for the different door is merely a 'skin' for the door. The actual door programming has a more exhaustive list with a bunch of entries I haven't documented yet such as those for the 'lobby' area of Ganon's Castle, and the doors used in the upper floors.

The game is expecting you to have a specific object loaded for dungeons. For the Fire Temple it's 002C - Fire Temple Doors. Your doors should be visible with that object loaded on every map.

Here's something you don't see every day. New ingame footage of the Zelda WiiU title What I've posted here is a close-up with original audio, but there's another overdubbed version for english speakers. I just like being able to see it all and hear the sounds of the game.

I really like this one, it's got a fantastic atmosphere and the motifs are strong without breaking the very serene quality it has.

Both Texture Explorer and ZLE2 will make the file the same size when it's converted as long as the type and pixel count is the same.

CloudMAX's Texture Explorer allows you to overwrite existing textures, you can get the addresses for textures not currently in the .ini from a dump by OZMAV (it gives you the addresses in ROM). If you're wanting to inject completely new textures, you can use ZLE2 to convert them to the relevant raw format and inject them with ROMPUT or using a hex editor.

You don't need it, I don't think. But the fact that it's got the correct actor data but is appearing as a Deku Baba points to there being something wrong with your ROM. It might be why you were having issues with the well in Kakariko. I can't think how a ROM could 'break' in such a bizarrely functional way, but it's something you might need to consider.

Hmm...does it behave like a normal Deku Baba after the cutscene finishes? There may be something wrong with your ROM.

Technically speaking, .obj is the most portable format since most, if not all programs have support for it. Having said that, since it seems to be such an open standard, it does come with its inherent drawbacks vis-a-vis formatting, not to mention its lack of support for certain 3d features. I'd suggest plain text .x format, but nobody other than me seems to be interested in making it a standard.

Hmm. I'm going to do some tests with this tomorrow. I'll let you know if I come up with any workarounds.

I just want to confirm something here. Do you want to change where the EXISTING exit at the bottom takes you, or change it so that the surface IN FRONT of the exit takes you somewhere? Because if it's the former, then you shouldn't be getting exited from the map when you just jump into the well.

Assuming that is indeed the case, then it looks like the polygon type definition must have been modified. If the same type is used elsewhere and an exit was added to it, then that would explain the behaviour.

What exactly have you done? If you isolate the steps, you should be able to work out what's causing the issue.

Naming conventions have always been a sticky issue. 'Objects' versus the older 'groups', 'path nodes' and 'waypoints'...etc. It helps to have a good naming convention from the beginning, but ultimately people are going to have their own terms. Having said that, it doesn't directly contribute to the issue at hand. I'd suggest trying much larger/smaller values. If nothing changes, there's something secondary that you're missing, or you're looking at the wrong data.

Thanks again, these will be useful

I think (though I'm not sure) that there might be an entry missing from the scene header (or it's just set up as 00 00 for each entry), the 0x06 command also known as the entrance list which corresponds to and links up with the spawn actors. I'll need to check it myself, but there's a possibility that it's missing.

Okay, first of all, there's no need to add the 1 to the second spawn point, since both are on map 0. You'd only need to do that if it were on map 1. Secondly, I'm not sure what's causing the problem. It's very odd. You might have better luck with a different map, maybe Kokiri Forest.

I think there were more issues with SO's lists than the fact that they weren't interleaved. Here's the post about the differing mesh types. And here's the Model2F3DEX2 source, the models this generates work on hardware.

No dice. It runs, but the depth buffer is still wigging out. Not sure if it's related to the model being mostly one huge group.

Thanks man You accidentally put the ending bracket in the URL, I fixed that for you in case anyone else wants these particular obj files.

I could use Seres, Oren, Irene, Peahat, Ku, Lorulean Spear Knight, Hyu, Octorok and Slarok.

Okay, in SharpOcarina, there's an exit list on the collision and exits tab. Find the map(s) that you want to link up to in this list and put the index number into that listbox. Here's an example. 0191 52 01 41 83 Kakariko Village From Death Mountain Trail 0192 52 01 41 02 Kakariko Village From Death Mountain Trail 0193 52 01 41 83 Kakariko Village From Death Mountain Trail 0194 52 01 41 02 Kakariko Village From Death Mountain Trail 0195 52 02 41 83 Kakariko Village From Graveyard 0196 52 02 41 02 Kakariko Village From Graveyard 0197 52 02 41 83 Kakariko Village From Graveyard 0198 52 02 41 02 Kakariko Village From Graveyard That first value is the number you'd use for your exit list. That's the index of the entry in THIS table. The second number is the index of Kakariko Village's scene in the scene table. You only need to worry about that if you're editing the entrance table itself. The third value again is only one you need to worry about if you're editing the entrance table, it's the value used to determine which of the 'Link' objects Link will spawn at when the map is loaded. The next column is the variable, in these entries it's 41, which is more or less the 'default'. Lastly, there's the 'transition' byte. This is usually 02 for most, but is alternating here because Kakariko has different setups for day and night. Now, there's 4 entries for each possible 'state' Link can be in when entering a map, Kid Day, Kid Night, Adult Day, Adult Night. Generally you use the first entry, Kid Day, in the exit list, and the game does a bit of math to determine if the others should be used. If the map you're overwriting has all the entry points you need, all you need to do is find the correct entry in this index and use it. If not, you'll need to add new entries. You'd do that by finding another one that you're not using, and change (usually just) the second and third values in the list. Make sure you do all 4 variations, too. When it comes to positioning your 'Link' actors as entry points, you'll need to make sure of a couple of things. Firstly, the variable needs to be correct if you have more than one room. The variable is pretty straightforward, xFFF with x being the index of the room the entry point is in, starting from 0. In your screenshot, the entry point in room 0 would need to have a variable of 0FFF, and the one in room 1 would need to be 1FFF. This ensures the correct room loads when Link is spawned. When referencing those entry points, they're just entry points 00 and 01 of whatever scene index you overwrite for the map.

I'm all for having hardware functional hacks if possible, because it actually means they're more likely to run smoothly on emulators too, and there's a far higher chance that the ROM won't become damaged whilst it's being worked on, leading to less headaches for the person doing the work. Plus, I'd love to be able to play them on hardware myself.

With any polishing they're doing, I wonder what they'll do with the saving system - they could keep the original Japanese version, add in the interrupt save or do something completely new.