xdaniel

SceneNavi v1.0 Beta 10 pre-release. Expect Majora's Mask and potentially breakage. More detailed changelog here. My motivation and interest in OoT/MM is going near zero, so before ex. the partial MM support just keeps collecting dust forever, have a build that should basically work, but might have undiscovered problems and such.

About the carpenter, I don't remember their exact behaviour on collision, i.e. regarding walls, floor, etc., but you could try changing their path using SceneNavi ("Waypoints" tab; also enable waypoint rendering under "Options" -> "Render Elements" in the menu).

Alright, that's an explanation, and an opinion I can respect, even though I also don't understand why that happens for you. As for ETC1A4, I am lurking GBATemp and have seen those posts. Couldn't really say what ALBW might use the data from the alpha channel for instead, tho, either. That said, you could use either of the DLLs just fine, if you make your tools invoke it directly instead of going through the viewer, as I mentioned. Call the conversion function for ETC1A4, then zero out (or rather "0xFF out", I guess) the alpha channel's data after conversion. And regardless of the whole alpha channel situation, directly using that library would be more convenient for anyone who wants to follow your tutorial, as there would be no more need for all the copy and pasting, running the viewer, dumping the model, etc.

You mentioned elsewhere, "The latest version before xdaniel bundled the source with it works for me, but I can't update .NET Framework for the final one.", emphasis mine. From the start, I had targeted the highest overall version of the Framework that VC# 2010 can target, which is .NET 4.0, and I had never changed that, nor do I think I updated my local installation of the Framework while working on the viewer. So if older versions work for you, that latest one should as well. And even if the binary doesn't, there's nothing stopping you from trying to compile the code yourself. Plus, why are you not able to update the Framework in the first place, if I may ask? But all the .NET stuff aside, https://github.com/xdanieldzd/ETC1Lib - that's a somewhat cleaner version of the old ETC1.dll responsible for decoding ETC1 textures in the OoT3D viewer, written - which you'll probably like, considering your apparent dislike of C# and/or .NET - in C++. Even better, that updated library actually converts ETC1A4 textures correctly, unlike the old one from the viewer. You could build that library and then interface with it directly in one of your tools (texturegetter, I'd imagine), cutting out the viewer and silly cmb file hackery entirely.

So, I might as well make a quick post about this here, too, just in case someone here cares about Atlus and/or Etrian Odyssey... Here's Tharsis, a file converter meant for Etrian Odyssey 4 (3DS), but also compatible with other Atlus games (ex. Shin Megami Tensei 4, Persona 3 Portable, ...) because of shared file formats. Builds have so far been posted on Jul, which is also where things happen, basically, regarding this program. The latest build there is a few revisions old, thus ex. still missing support for additional pixel formats in STEX files, but I'll be putting a new one onto GitHub during the next couple of days.

Some flea market pick-ups to report - and actually dating back to ca. 1 1/2 weeks ago, but whatever... R4i Advance (NDS Slot-1 flash cart) GameCube WaveBird controller (sadly w/o receiver) ...and, while not really a pick-up, here's a quick and crappy photo of my crappy gaming setup - but it's MY setup, so I like it <3

...don't get me wrong, and this is nothing against you personally, but this mentality is pretty much poisonous for any sort of ROM hacking scene. Think of ex. the Super Mario World hacks that rely on sound emulation bugs in ancient versions of ZSNES, and just crash on hardware and modern emulators. Or SNES fan translations with graphic glitches, caused by writing to VRAM when it shouldn't be possible. Or earlier hacks of Super Mario 64 being unplayable on hardware because they don't respect proper data alignments. This isn't me wanting to force you to, I dunno, buy an Everdrive 64 and constantly test your mod on hardware, I'm just trying to get people in general to realize that their creations are basically bound to buggy emulators, which will eventually - granted, maybe 10+ years down the line - no longer work on their machines, with ex. 32-bit support disappearing. Emulators will eventually get more accurate as well, properly emulating the N64's hardware, including crashing the system when overflowing the vertex buffer (what Model2N64, and in turn Hylian Toolbox does). Hell, even now and with current emulators, without patching SO as per the above posts, especially translucent surfaces will likely not render properly in terms of Z-ordering, with Link appearing in front of or behind them, forgot what exactly happens under emulation. I feel like I'm starting to understand how byuu - that is, the very accurate SNES emulator bsnes/higan's author - must've felt whenever the topic of emulation accuracy came up, and why it's important... Again, not at all meant as an attack or insult against you, I really, really hope you're not taking it this way. It's just frustating to see this attitude, no matter from whom, and especially because my old work is part of the problem... Instead of trying to improve our knowledge and toolset, we just keep our superficial knowledge and half-broken tools, and keep making things that won't ever work right on the system the original game was made for... (Edit, and sorry for the wall of text...)

/* Write mesh header */ if (MeshHeaderOffset != -1) { List<NDisplayList> opaqueLists = Room.DLists.FindAll(delegate(NDisplayList DL) { return (DL.TintAlpha >> 24) == 255; }); List<NDisplayList> translucentLists = Room.DLists.FindAll(delegate(NDisplayList DL) { return (DL.TintAlpha >> 24) != 255; }); int numEntries = Math.Max(opaqueLists.Count, translucentLists.Count); Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset, (uint)(0x00000000 | (numEntries << 16))); Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset + 4, (uint)(0x03000000 | MeshHeaderOffset + 12)); Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset + 8, (uint)(0x03000000 | (MeshHeaderOffset + 12) + (numEntries * 8))); MeshHeaderOffset += 12; for (int i = 0; i < numEntries; i++) { if (i < opaqueLists.Count) Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset, (uint)(0x03000000 | opaqueLists[i].Offset)); else Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset, 0); MeshHeaderOffset += 4; if (i < translucentLists.Count) Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset, (uint)(0x03000000 | translucentLists[i].Offset)); else Helpers.Overwrite32(ref Room.RoomData, MeshHeaderOffset, 0); MeshHeaderOffset += 4; } } ...probably. Someone would need to check a conversion made using that code on hardware. Also, latest/last version of the source is the one on Google Code: https://code.google.com/p/sharpocarina/ - hasn't changed in the last almost 3 years.

Less issues than HT (and Model2N64), and probably fixable. See also the rest of that thread.