Arcaith

"Wanna fuse Kinstones?"

As far as I'm aware, it's not possible to check the actual UV values in SketchUp, just how the texture looks on the surfaces.

The one exception to the binding of different rooms to maps can be found in places like the Water Temple and Deku Tree's main rooms. Those are a single room, but they have multiple floors.

I don't believe this has actually been worked out yet. Compared to getting other aspects of modding maps working, it's been quite low on the priorities list.

Cen is a talented guy, no denying that. I'd like to see a release of this before I go crazy over it, though. I'm curious as to how he's managed to get it to work with unmodified emulators. Especially if you need more than one instance of said emulator. Point of fact, I'm hesitant to say anything here until I have more to go on. If there's any drama in this thread, I'm going to be doling out some warnings to ANYONE that participates. So keep your heads cool.

Aphex Twin - Pulsewidth

You'll have to ask in the IRC for the files, the distribution is being carefully controlled, no public links exist.

It's possible, the textures are extracted with the model files as .png files. One thing to keep in mind though is that the texture transparency doesn't always work (the formats need more research) and also that the textures are stored in a far more modern way - there are multiple texture surfaces per texture file, much like (for example) Twilight Princess.

I think that in this case it's just an educated guess based on what he's seeing. In other words, he's not 100% certain, but is offering a possible solution based on a hunch that might be worth looking into. He's also saying he doesn't have the time to or doesn't want to look into it himself. That's all.

I was right then XD It was an issue with the tiling mode. Visual issues like that can be caused by UV values all sharing the one edge of the mapping, or by the tiling mode being set to clamp on the wrong axis, or by the tiling mode being set to clamp and the mapping for the faces having U or V values greater than 1.0 (or 1024, as the N64 doesn't use floats for texture mapping values).

It looks like you have the texture mode set to 'clamp' on the wrong axis. Try adjusting it.

When a texture appears to be oddly distorted, it's usually because the UV values are out of range. Try to keep your UV values within -4 to 4.

They would have probably used it for testing purposes to get the engine working at a basic level before implementing higher level stuff like UI redesigns etc.

Unless otherwise specified, maps generally load on room 00 first. So make sure you're actually loading the correct room in the exit, and change it if required. Secondly, make sure that each door is paired to the correct two rooms, and make sure the rotation is also correct. The 'front' of the door object is the side that is usually barred to a clear trigger with vertical bars (however both sides can be locked if it's a keyed door) and that room is usually the one defined in the SECOND room parameter.

At the library with a new hat.

I think the same bridge actor is used for both of Link's ages, so the age check does actually make some sense.

Surely I'm not shady? Welcome :3

Aren't Navi's display lists dynamically updated with colour changes depending on the z-targeting options available? That might be causing the problem if 1- the texture type is different (I think the exisiting type is an indexed alpha texture, IIRC) and 2- if the number of vertices are changing (specifically reducing), since it's going to be expecting a minimum number of points to change their vertex colour data.

If you're hoping to use the different tilesets to create a dreamlike world where nothing is consistent, this looks good. However if you're not, it's a little jarring.

Okay guys, settle down. 1- If the entire map was rotated on one axis and the orientation of the texture scrolling remains unchanged, then that seems to support my theory that it follows the UV co-ordinates, not a fixed direction hardcoded into the map. 2- I'm assuming that whatever is done with the scene table, it's related to loading the 'macro' that causes the water to flow, as there would be no point in loading it in a scene that doesn't need it. 3- If swapping the scene table entries is causing particular surfaces to move like water, it stands to reason that the 'macro' targets a specific texture definition, or group of polygons by a numbered value and animates it at a fixed speed as defined either in the table somewhere, or in the 'macro' itself, which may be elsewhere in the ROM.

You mean the texture still moves vertically?

I actually think water flow direction is calculated based on texture co-ordinates, specifically which direction is 'up' and which is 'down' (or 'right' and 'left', depending on which values are checked); basically positive and negative UV co-ords. It either shifts it toward positive or negative on one (or both) U and V axes by a factor of 0.9999 (a full repeat being 1.0) (or 1023 (full repeat being 1024) in the case of OOT, since it doesn't use floats for texture co-ords) and then resets the co-ordinates back to their origin as it's shifted it once along the length of the texture. The process repeats, creating the illusion of a moving surface. This also explains how the water in Hyrule Field is able to change direction, rather than using hardcoded pointers. Unless it's using the waypoints in the moat itself.

You use it in a MIDI sequencer or DAW if they support soundfonts. Alternately you can install the BASSMIDI driver and use it with any MIDI device.

Dude, freaking bravo This is coming along really swiftly, and it's looking fantastic.

Looking most awesome my man