xdaniel

Looking at the code, it seems to throw that exception while trying to form the path to the XML actor definitions. It uses part of the game ID for that, the two middle characters, which should be "ZL" for all OoT ROMs and might be characters that can't be used in a path in your ROM. Mind opening it in a hex editor and telling me the game title, ID and version byte? Those are at offsets 0x20, 0x3B and 0x3F, respectively. Or maybe just take a screenshot of how the beginning of your ROM file looks (both the hex values and ASCII text), where it should say "THE LEGEND OF ZELDA" - kinda like this (from my working Debug ROM):

You did select a specific room, right? Because actors don't, and aren't supposed to, show when all rooms are rendered at once. Then again, you must have selected a room because otherwise you couldn't scroll through the actors on the Room Actors tab... Uhm, so after selecting a room, the actor selection under Room Actors is set to "(None)" and no actor cubes show (at which point they should show). Once you scroll down to an actual actor, the cubes and the selected actor's axis marker render. Am I getting this right?

Aya Hirano, because Konata and Haruhi. Emiri Katou or Chiwa Saitou?

Non-MQ Debug ROMs aren't really supported yet, especially vanilla ones that haven't been expanded/decompressed. I just tried it with a normal 32MB NTSC v1.0 and it didn't find any scenes, while any actor gives me the exact same error message. MQ Debug ROMs should work fine, regardless of their name... What error message do you get there?

First "mouse mode build": http://magicstone.de/dzd/random/SorataVSE_test2-14022013-0246.rar Switch modes with the mouse wheel or by clicking the label in the lower right corner; camera mode just moves the camera, room selection mode allows selecting rooms by left-clicking them, actor editing mode allows selecting actor cubes by clicking (all buttons right now) and moving them around by holding the left (left/right/up/down) or middle (left/right/into screen/out of screen) mouse button. All movement is sped up by holding Space and slowed down by holding Shift. Forgot what else has changed. Also, you will encounter instances of the GUI not updating, mainly when dragging actor cubes around, I know about that - there's a bunch of //TODO TODO TODO [...] in the code, some related to that. Feedback about mouse control & co. is welcome! Edit: Also didn't ignore you, Mallos Right-clicking an actor cube will eventually open a context menu, I'll add a "Render actor" menu entry or something that'll jump to the actor viewer. As for knowing what actor is what, that's what actor definitions are gonna be for, the things that build the actor editing interface (as seen for switches and treasure chests already) which also contain a short description.

(First things first, holy crap this post is yet another long one <.<) Heh, glad to hear you aren't disappointed about that, because I myself actually am a bit Kinda makes me wonder how Nintendo's own editing tools displayed actors in rooms, too. Anyway, something else feedback-wise, that might be a bit long-winded: Already before the last screenshot, I started overhauling the mouse controls. With actor editing starting to take shape, including picking them and eventually moving them via mouse, etc., I starting re-thinking how to approach the user's mouse-based interaction with the program, the 3D view in particular. Previously, the mouse was used only for camera control and selecting rooms by right-clicking, as mentioned before. Now I've started to implement "mouse modes" like UoT and Sayaka use, that control what the user can interact with and what not in the given mode. This is something else I'd like to get feedback on, as I'm not completely sure about the most intuitive way to do this. There's three modes currently: Camera only, room selection, and actor editing. Camera works like you'd imagine, looking around with the mouse while holding the left button, and moving around with WASD. Room selection is the same, but will additionally select any rooms that are under the mouse cursor when the user left-clicks. Meaning, you click on a room, the room is selected, and if you keep holding the button down, you can still look around. I can see this being a bit problematic if the user accidentally clicks outside of the room while trying to maneuver around. Actor editing is currently the same way, with actors being selected by left-clicking, in addition to camera movement. About moving and selecting actors: I feel like UoT has that down pretty well, so I'm thinking of emulating its mouse control behavior for the most part, including the camera locking onto the actor cube and the mouse cursor being locked in place while moving an actor. In addition to that, I wonder if I should add keyboard modifiers that change on which axis the actor is moved? Like that if you hold Shift, the actor will only move on the X axis, or if you hold Ctrl it'll only move on the Z axis or so. Thinking of keyboard-based modifiers in particular as you can just activate them by holding a key, as opposed to having to click somewhere on the GUI or somesuch. However, will that potentially "scare away" people, having to press keys for certain things? I'd rather not use the mouse wheel to select the axis, as I'm using it to switch between mouse modes (camera, rooms, actors), but I could switch to using that if you think keyboard modifiers are the worse idea. Not sure what else I could ask about regarding this, until after I've made a build that incorporates any suggestions you'd give me. One more thing to report: I cut down ROM loading time for the MQ Debug ROM by a bit over a second, by rewriting how the ROM loader fetches names from the filename table. That brings the time down from ~2.6 seconds by now (with ex. searching for scene, actor and object tables, and reading them) to ~1.4 seconds, which is about what it was before I added support for the actor and object tables.

Leaving actor rendering aside for a bit, not least because of Saria's beard (<.<), here's a new screenshot of Sorata's level viewing and editing side: The Return of the Actor Cubesâ„¢ - soon in cinemas near you! Well, no, in all seriousness: As wonderful as proper actor rendering in rooms would be, I have decided against doing it and there's two reasons for that. The first reason is simply how horribly incomplete actor rendering is, and how I can't see too many improvements to it short of writing a proper MIPS interpreter core, which would have to emulate each actor's code as well as any functions it might call elsewhere. There's actors whose hierarchies or animations cannot be found, there's actors whose display lists cannot be found or no distinction can be made on which of them are actually supposed to be rendered by the given actor with the given variable, there's actors whose scale for rendering cannot be found, etc., etc. All this would result in ex. actors that appear many times bigger than the room they're actually in, or actors, dungeon-specific ones in particular, who render each and every display list in their object file in one place. The result would simply not be up to the standard I'd like to have - either go all the way, which in this case isn't something I'd be able to do, or don't go at all. The second reason is far more simple, while at the same time probably even more important: performance. While everything is still rather unoptimized, I am not sure how far I can optimize ex. Nanami's display list parsing and rendering code, considering the design I've chosen for the whole thing. Of course I'll push for optimization when the time comes, but as it stands now, rendering ex. Ganon alone drops the FPS down to 38, with other actors not faring much better. Now imagine 20 or so demanding actors being rendered in addition to the room they're in. I can't see this working well enough to warrant implementing it.

Oh god, did you have to remind me? I thought so too when the texturing came out like this...

DISCLAIMER: A big, bad hack where I check every instruction if the simulated registers contain enough data to form a valid gSPSegment command where the base address is inside the object RAM segment (0x06).. The good... or rather okay: The bad: The ugly:

A note inside reads "Don't try to eat me!"

Average-looking girl then, that's easy. I do want a bit more than just good looks, as alluring as some extremely good looks might be. Newspaper or internet?

I'd guess the only additional thing you'd need to do is fix the addresses that the Mtx commands used for the joints point to... I don't have them in my head right now, but her and Link's hierarchies don't match up perfectly, I assume, in terms of which limb number is which limb... Like that ex. their left upper arms have different limb numbers, say ex. Saria's would be limb 5 while Link's would be limb 7, and their left shoulders would be limb 4 and limb 6 respectively. If you port Saria's left upper arm and shoulder over Link's, the arm that previously needed the matrix of limb 4 (shoulder) for the connecting vertices would now need those of limb 6, because that's where Link has his shoulder. Then you'll need to fix the Mtx command that loads the matrix for the vertices connecting the upper arm with the shoulder, so that it now loads the matrix from the address of limb 6's matrix, instead of limb 4's. I guess that those Mtx command fixes are all that need to be done for the connections to work properly. Hope that wasn't too confusing, it's kinda new to me as well, and it's 4:30 am here by now Edit: In fact, if you could make a Play as Saria patch where the connections are broken (or have that old one still lying around; I'm lazy I admit), I could try to fix it.

What exactly it'll be able to edit is still up in the air in general, so I'm open to suggestions. I'll try to implement editing for as many things as possible. As for matrix data porting, matrix data is generated on-the-fly according to the current animation frame, meaning the current position of the limbs - there simply is no matrix data to port. For specific vertices of a limb, the game uses the position of another limb instead of the one the currently rendered display list belongs to, then for the remaining vertices used by the display list, it uses the current limb's position. As far as I can tell - and someone with a deeper understanding of all this please correct me - everything is actually positioned using matrices "internally" (for my lack of a better word right now) and the game generates them as needed. Actors are positioned in a room like that, doing the N64's equivalents of glTranslate and glRotate, each actor's limb are positioned that way, the camera is positioned that way, and so on. There are base matrices in certain room files, used by some elements of the room in question, but even those are in turn modified by the game to ex. make Jabu-Jabu's walls wobble, and are only a part of a grand chain of matrices anyway - from the screen's projection matrix, to the skybox, to the rooms, to (for example) Link, to Link's limbs, to the dust Link kicks up when rolling. The only things that IIRC aren't done this way are TexRects, which are what make up most of the HUD, but even those are probably affected by the projection matrix, I'm not sure.

Badly maintained overhead power cables? I would guess they can have loose connections or something, too, but I'm no electrician.

Canned tomato cream soup and toast, maybe have a yogurt as dessert. Kinda feel like going to Subway, McDonalds or something for a change tomorrow, it's been mostly canned foods for me recently...

Ahh, yeah, a known bug in SharpOcarina regarding file locations... Open up the "Demo Scene.xml" file in Notepad and look for the line "<CollisionFilename>collision.obj</CollisionFilename>". Add the full path to where that file is on your computer to that line. I'm guessing from the error message that it's at "C:UsersSairugothDocumentsNEW COMPUTER REBRITHHack&CrackLOZooT editorsSharpOcarina-v06democollision.obj". If that's correct, edit the line to read "<CollisionFilename>C:UsersSairugothDocumentsNEW COMPUTER REBRITHHack&CrackLOZooT editorsSharpOcarina-v06democollision.obj</CollisionFilename>". You'll probably have the same problem with each of the rooms' .obj files, so you need to fix their paths as well. That should hopefully fix it. Also, let's continue the talk about SharpOcarina in its thread http://www.the-gcn.com/topic/675-sharpocarina-zelda-oot-scene-development-system/

SorataVSE new build: http://magicstone.de/dzd/random/SorataVSE_test1-09022013-0342.rar No support for Link right now, many actors don't load or don't load correctly (particularly static ones, and everything using "non-standard" hierarchies/animations), some actors don't render correctly (ex. missing or errornous texture mapping, some have display lists that load but don't render for some reason, like the Zoras), some actors are simply out of view by default and you need to move the camera to find them ( ; check "Display lists active" in the bottom left corner if something's supposed to render or not), etc., etc. Also note the aforementioned improvements regarding room selection; right-click a room in a scene to select it, right-click outside of it to deselect it. You tried loading the demo scene via "File" -> "Open Scene", right? If the error's the same one you posted before, you should get a long log of the error if you press "Details". Mind if you post that here, preferably in spoiler tags as it's likely quite long? As for loading your own exported .obj files, you did create a new scene ("File" -> "New Scene"), then went to the "Rooms" tab, then clicked "Add Room", and then you still had a black screen after selecting and loading your model? That might be because it's too small. Try increasing the "Scale" option on the "General" tab; if that makes the model show up, you should scale it up in SketchUp. There's a guide by Flotonic that lists the correct sizes for things like doors and such, that should help you make everything the correct size.

I know there's no tutorials for my Model2N64 tool, and I'm not sure about the whereabouts of those for other importers like spinout's... If no one else knows, you could try looking around either here on the forums or on the wiki, although I'm not sure if there's any on either. Promoting the site and Zelda 64 hacking in general sounds pretty cool - IMO it's about time the Ura project becomes more well-known outside our circles As for Sorata... ...aaaaaand I just noticed a problem with unnecessary texture loads that fill up the cache... well, still a whole lot to fix and improve and implement... Edit: Turns out the cache had a problem with textures at invalid addresses (meaning ex. the missing facial textures), and kept adding more and more yellow dummy textures to the cache instead of reusing the existing one. Changed it so the dummy doesn't get cached anymore, forgoing the cache in the first place - makes more sense anyway

Saria. Ruto's just... nah. Don't like her. Kid Icarus: Uprising or Mario Kart 7?

Still a bit unstable and missing a lot of functionality, both on the end user's side (no UI whatsoever, besides the actor list you can see) and in the code (hierarchy and animation scanning, etc). Will post another early WIP build once that's been improved.

Yeah, in fact I guess I'm kinda like that, too... only difference being, I keep looking around and trying before I settle on "It doesn't work! Who's responsible for this?" Being on the subject of usability, human-readable room names might not be that big of a problem. I just added room selection by right-clicking a room in the 3D view. So someone who wants to find a room can just let the program render them all (which is the default for scenes with more than one room anyway), then fly around the scene and right-click the room. It'll get selected, so only this room will be rendered, actors will be displayed, etc. Edit: Oh, right, and you deselect the room by simply right-clicking outside of it.

What is it with no one reading the Readme file? You need to export your model from SketchUp into an .obj file, which the Pro version can do by itself I think, while for the normal one there's plugins; SharpOcarina doesn't support any other formats. Plus, you don't open them from the menu, but add them in the appropriate places on the "Scene (General)" and "Rooms" tabs. Please don't take this the wrong way, it's just that I've had many questions before that can be answered simply by looking into the Readme file. SorataVSE will be easier to use (but will not be an importer, mind you), but for SO you... just have to get used to it, I guess.

Exactly. Basically, what you have here in ZSaten2 will be a tab in Sorata, next to the scene and file system lists. You select an actor from the actor table, the program will load everything the actor needs, look for hierarchies and animations, etc., - pretty much like "ZSaten1", only with a proper GUI and eventually editing.

Hrm, do we know how the in-game map system works? Then I could try and make it find, read and use that data... Visualizing it would be something else still, but having access to that data would be helpful anyway. Thanks for the comments As for SharpOcarina and Model2N64, you don't need to extract anything from your OoT ROM, as both of them are supposed to create entirely new content - they don't even load anything from the ROMs in the first place. You need 3D models saved as .obj files, which you can load into the programs, which will in the end create N64- and/or OoT-compatible data.

Ohhh, "Cannot load to segment by filename; no filename table found", I guess? Yeah, gonna change that and post another build later. Link still won't work without a filename table tho, as "gameplay_keep", "link_animetion" and "ovl_player_actor" are hardcoded, and I probably am not gonna change that; the program's meant to be a proof-of-concept after all, not an ongoing project as such.