xdaniel

Oops, I never released any builds that supported transition actors like doors... try this one: http://magicstone.de/dzd/random/SayakaGL-v011x.rar It should work fine, but it's incomplete etc. and the last "should be stable but who knows" build I ever did, so no warranties!

Part of the variable IIRC, which Sayaka does support: http://wiki.spinout182.com/w/Modification_and_Addition_of_Switches#Standard_Door the "XX" there being the flag I believe?

The EO series maybe isn't perfect, but I really like them. Or, well, the first one at least, as 2 and 3 never came to Europe, and while 4 has been announced with a vague "Spring 2013", it's not even clear yet if it'll be retail or eShop-only. Anyway, I don't really know how I'm keeping track of everything myself. I guess I tend to keep the rough outline of each program in my head, while details are kept in comments in the code, for ex. things that need to be added/fixed are listed as big, fat "TODO TODO TODO"s...

When fed up with and/or bored by Zelda, I'm messing around with this: The program is currently just a simple map layout viewer - "Floor Appearance" and "Events" do nothing - as there's still a lot of research to be done (hur hur). Been messing around with scripting last, and I can so far at least give myself obscene amounts of money... and crash the game hard.

I think this summarizes a lot of mine: <3

After playing, uh, "not so legal" variants on and off since Beta 1.7 or so...

Hah, I bet there's a ton already. There's a ton of fanart for everything. Oh, and on-topic: Malon.

80s movies? Back to the Future. Well, mid to late 80s... and Part 3 was 1990... but my point still stands!

I'm not Jason, but I can at least tell say it looks like the program fetches the data correctly - those are the first scene and room header of Hyrule Field. (Also disregard/be wary about my comment regarding 64 actors, 16 objects... Hyrule Field has 73 actors. Where did those numbers come from then? <.<)

Yeah, so, remember that "Wii mini" thing that's been released in Canada, a Wii without GCN support - like the previous redesign the Wii received - and without online support. Edit: And without SD card slot and composite video only. It's seeing release in Europe in March. Amazon Germany lists it at 109.99 € and it comes with console, WiiRemote Plus, Nunchuck and the other usual cables. Who is gonna buy this if they can get a black, GCN-less but online-capable Wii with WiiRemote Plus, Nunchuck, cables, Mario Kart Wii and wheel for just 30 € more? Like with the Canadian release before, just what is Nintendo thinking, putting out another and heavily gimped Wii, when they should be pushing the freaking Wii U?

Room headers do not equal rooms. Rooms (or maps if you prefer) are those "####_room_#" files you see if you extract the ROM or if you're using ex. SayakaGL. Hyrule Field only has one room, spot00_room_0 to be exact, so I assume that a, well, "choice" of only one room there is correct. A room can contain multiple "configurations", the headers, which are what determine ex. adult/child Link actors. Edit: Apparently, multiple headers aren't supported yet considering "Be able to go into alternate map headers." under Possible Future Updates in Jason's first post.

Both scenes and rooms can have multiple headers, the one being using depending on adult/child Link, day and night, or the cutscene that's supposed to be played. And that said, I believe Hyrule Field has around 10 or so each, not 17, and certainly not 17 rooms.

The developers probably just forced the items on in the default file, without bothering to (or not being able to?) set the correct event flags. I don't know which flags are set by default in the file, but it appears like they just stopped playing normally after opening the Deku Tree - considering how the "first entering" cutscene for Inside the Deku Tree played when entering, just like with every(?) other scene in the game - and just gave themselves all items via the inventory debug menu or so.

IIRC there's a limit of 16 objects and 64 actors per room, which we encountered with SM64toZ64 - http://code.google.com/p/ozmav/source/browse/trunk/sm64toz64/main.c#88 - you might want to double-check this again to make sure, tho. Besides that (and that I haven't actually tried it...), good job with the program! Adding actors and objects to existing rooms has always been a bit of a problem

Not scene file, but scene header. Try selecting a different "Object Set" and hope that UoT supports changing the BGM on a per-header basis, and not just actors.

We have a desktop thread, where we post screenshots of our current desktops... but what about ones from years before that might still lurk on your HDDs or webspace or so? Let me show you some 800x600 goodness from almost 9 years ago, which still were on my members.aol.com account until they closed the service for good a few years ago. From either February 3rd or March 2nd 2004 - probably the first as Mozilla Firebird was renamed to Firefox on February 9th 2004 with v0.8 - according to the original filename: Going by the same logic, this should be from March 4th 2004 (featuring Firefox): ...while this is, for sure, from August 27th 2004: I don't think I can go back any further. I do remember one specific desktop screenshot I took (2002 maybe?) that had a somewhat messed up screenshot of one of the Child Link dungeons from OoT, as played by Daedalus v0.07b or so, with some replacement shell, uh, replacing the normal Windows task bar... That screenshot's probably been lost to time, tho.

Something you create using SharpOcarina. Create a new scene, then add your collision model, then your room model(s). You save the configuration you make in SO (actors, etc) to an XML Scene File so that you don't have to redo all that stuff over again if you happen to quit the program.

As he appears to be using SO v0.6 (thus r17), line 275 of ObjFile.cs should be: StreamReader SR = File.OpenText(Filename); What? Not to mention, File.OpenText isn't even supposed to throw an IndexOutOfBoundsException! EDIT: Alright, got the map, gonna try and debug this... EDIT 2: Okay, two things: I have no idea what build of SO he's using. On my local source, it bails on line 362, which is also line 362 in r17 (= v0.6) on the SVN. Next, the .obj file does something that's apparently valid, but that I hadn't seen before: f 95/121/3 96/122/3 97/123/3 98/124/3 99/125/3 100/126/3 101/127/3 102/128/3 103/129/3 104/130/3 105/131/3 106/132/3 107/133/3 108/134/3 109/135/3 110/136/3 26/137/3 25/138/3 28/139/3 27/140/3 30/141/3 32/142/3 31/143/3 34/144/3 36/145/3 35/146/3 38/147/3 40/148/3 39/149/3 42/150/3 44/151/3 43/152/3 46/153/3 48/154/3 47/155/3 50/156/3 52/157/3 51/158/3 54/159/3 56/160/3 55/161/3 57/162/3 59/163/3 58/164/3 60/165/3 61/166/3 6/167/3 4/168/3 111/169/3 112/170/3 ...it's got a whole lot of indices on a single face definition line, which the triangulation code doesn't like; namely three temporary arrays with 16 elements each, used for vertex, texture coordinate and normal indices. Haaa, I guess I'll see about pushing out one final "this isn't in development anymore!" SO update -.-

Red Z-targeting markers, too:

Hm, seems like I'm able to reproduce the "missing actor cubes" bug somewhat, on my mom's PC: She's currently limited to an on-board GeForce 6150 as her previous card died, so I'm guessing there's a problem with OpenGL in some way... curiously combiner emulation works fine, so I probably messed something up in the actor cube's GL display list. I'll double-check the actor cube code once I'm back home, maybe there's some stray fragment program stuff in there or something...

Model2N64: http://www.the-gcn.com/topic/1815-n64zelda-hacking-tools-dlist-conversion-etc/

Give it to the people reading this thread, including the author of SharpOcarina (myself). And I presume haddockd means I should've caught it in the program's code, using a try-catch statement which can catch those exceptions and deal with them internally, so that the user doesn't get a mean dialog box like that. Which he's right about, I'm using try-catch far too little...

Couldn't you run ZSaten2, tho? That's also targeting 4.0 and even uses the same interpreter/rendering library Sorata uses. I could see about targeting 3.0 in general, tho, if I'm not using anything that's exclusive to 4.0...

Object 0x00C5 is the file object_os_anime, which contains animations (and hierarchies? not sure) used by several different actors, not just the Kokiri. I take it she uses that file for her animations and/or hierarchy and doesn't load if it's not loaded as well. See also http://www.spinout182.com/mqd/ and the objects page in particular.

Ahhh, it's not even broken, it's byteswapped. There's at least two different ways a N64 ROM can have its bytes ordered, and at least my own tools only work with big endian or "z64" ROMs - the ones where you can read the game's title at offset 0x20 -, because it's much more logical and easier to work with. There's tools that can convert between byte orderings, ex. "Tool64" or something like that, which you can try to use if you encounter such a ROM again. In fact, I should see about adding some kind of detection mechanism and maybe offer the user to convert the ROM to big endian for them...