N64/Zelda hacking tools (DList conversion etc)

[KEMIKOOL]

http://www.tempfiles.net/download/201211/273417/alienhead2.html xdan try this, if it works, can you please tell me how to replace model parts on an animated model ;P im sure its easy enough, repoint the head limb of the gibdos to the new model right?

[xdaniel]

Got Airikita's .obj as well... For one, that .obj actually does contain a .mtl reference, "mtllib head_blender_obj.mtl", so you should have a material file named head_blender_obj.mtl. Second, the .obj contains the usemtl command "usemtl ", which just like the "usemtl (null)" in Sanguinetti's file might very well be what throws the program/library off - if there's a usemtl command, it expects there to be some materials. Will double-check my assumptions later, it's 3:30 AM here now and I'm off to bed.

 

EDIT: Oh yeah, in the meantime, if you aren't using materials, try to remove the usemtl command as well as any mtllib references from the .obj files and try again. I'll look into this once I'm awake again.

Edited November 20, 2012 by xdaniel

[Airikita]

My texture on the head is invisible no matter what I do... I think I'm pointing to the wrong offset; is there any guide I can refer to for this?

[Arceny]

Oh yeah! .obj and .mtl's usually are bound together in a file...together,,,

[Airikita]

xdan: I found the problem... so I was looking at the offsets for both the Gibdo's head and my new model and noticed how there was 3 lines mixed in the wrong order in the .bin file your program created:

 

Gibdo's head:

 

The .bin file created raw:

 

So I had to re-arrange the 3 lines that your program created to look like this:

 

So it turns out my model was fine, but your program was creating some problems earlier where the Gibdo's head was invisible... but now it works after I fixed it:

 

So this will work for other objects, it just needs to be adjusted.

[SanguinettiMods]

That's never happened to me before, Airikita. Good job with fixing it. xDan's program didn't really produced it "mixed up", in Ocarina of Time, most Display Lists start with an E7 command.

[KEMIKOOL]

xdan: I found the problem... so I was looking at the offsets for both the Gibdo's head and my new model and noticed how there was 3 lines mixed in the wrong order in the .bin file your program created:

 

Gibdo's head:

 

The .bin file created raw:

 

So I had to re-arrange the 3 lines that your program created to look like this:

 

So it turns out my model was fine, but your program was creating some problems earlier where the Gibdo's head was invisible... but now it works after I fixed it:

 

So this will work for other objects, it just needs to be adjusted.

 

it made me happy to see you used my textured version ahah

[Airikita]

I tried creating a new model today, in blender... converted to 3ds then obj, then imported; fixed the dllist, and now it's not showing again.

 

Is it possible that blender could be a problem, or maybe when I export it to 3ds?

[Airikita]

I will have to apologize for the earlier demo, apparently I didn't need to do that for custom models... regardless, I finally have a successful import:

 

My issue now is the sharp corners and such, but I think my model editor should be able to fix that? The lighting is all weird.

[Secant]

I think the sharp corners are caused by missing or incorrect vertex normals data. I want to say DeathBasket posted a solution to that problem somewhere in a thread he started.

 

EDIT: Turns out I'm not insane after all, check his post here.

[KEMIKOOL]

its because the material is mostly a solid single color

[Airikita]

Problem solved:

 

There's still an edge, but it still looks good with what I have.

 

 

its because the material is mostly a solid single color

 

Actually, I was using a texture, but I forgot to remap it to fix the problem.

[KEMIKOOL]

 

Actually, I was using a texture, but I forgot to remap it to fix the problem.

 

by material i meant texture, i saw the 2 black strips and they werent affected by the shading so i figured the texture was mostly solid greenish brown

[KEMIKOOL]

gah finally, i ripped air off sorry

 

there are some rotation problems i need to fix lulz but yea

you are what you model (in my case)

[Airikita]

I'm attempting to get the Arwing to work, but even just adding the new model data to the end of the ovl_en_clear_tag.zactor crashes the game when an Arwing is present... Even without pointing to the new model!

[KEMIKOOL]

theres no obj file for that? someone needs to extract the zobj out of it, link in space mods would rule ahaha

[Airikita]

xdan: is it possible to get DE00XXXXXX... to "point" to a position in RAM?

[xdaniel]

DE000000 80123450 - second 32-bits are the Display List's address, either the absolute RAM address (like in the example) or the segment number plus relative address (like usual in ex. room files).

[Airikita]

DE000000 80123450 - second 32-bits are the Display List's address, either the absolute RAM address (like in the example) or the segment number plus relative address (like usual in ex. room files).

 

Okay, that's what I figured... I know I should've asked this sooner, but I'm trying to get a 128x128 texture to work... what format should it be? (OoT cuts off most of the texture after importing)

[xdaniel]

Sanguinetti already mentioned it on the shoutbox, but anyway. From the SharpOcarina readme, regarding texture sizes:

 

Q) What texture sizes and formats are supported?

A) Most textures can be up to 4096 bytes in size once converted. This doesn't mean anything to the artist making the textures, so here's some hints about color depths, dimensions, design, etc.

- Textures with more than 256 colors can be anything up to 64x32 pixels, that means, for example, 128x16 would also work, while 128x32 would not.

- Textures with up to 16 colors can be up to 64x64 pixels in size, so 128x32 would work, 128x64 would not.

- Try to make use of grayscale textures, which save space and can thus be rather big - with up to 16 shades of gray, up to 128x64 pixels -, and can still be colorized using the tint options in the room's group settings.

Again, not limitations of SO, but of the N64.

[Airikita]

Yeah, Sang mentioned it after I asked here... but anyways, the RAM address I want to point to changes in different maps, is there a way to use a data pointer to point to a zobj?

 

Or another way to point to a model group?

[Airikita]

Urgh... okay, I know I'm double-posting, but I have a problem in the Arwing... it's RAM offset is this: 01 01 F0 3E 80 9D 60 58 (found at 0x27C0 in ovl_En_Clear_Tag), it's virtual memory start point is 809D35B0, which makes the RAM offset at 0x809D35B0, but your program won't calculate it! It crashes instead... help.

[xdaniel]

Urgh... okay, I know I'm double-posting, but I have a problem in the Arwing... it's RAM offset is this: 01 01 F0 3E 80 9D 60 58 (found at 0x27C0 in ovl_En_Clear_Tag), it's virtual memory start point is 809D35B0, which makes the RAM offset at 0x809D35B0, but your program won't calculate it! It crashes instead... help.

 

Uhm, what... are you even trying to do? With the Arwing and my program? Are you trying to replace the Arwing's model with something you created? If so, the program isn't really intended to be used with absolute RAM addresses - it's intended to be used for models that are accessed via segments, be it stand-alone objects (segment 0x06) or those in the gameplay_files (0x04, 0x05) or wherever.

 

That said, it might work if you enter "0x80" as the segment and whatever the rest of the address is as the base offset, then properly copy and paste the data from the resulting file, etc., but I can't guarantee that at all. Plus, what's with the "01 01 F0 3E 80 9D 60 58"? That's a vertex command pointing to some vertices to be used for drawing the original model; it's not even at the start of a display list (which appears to be at 0x26F0 in the overlay). Please post exactly what you're trying to do and how, then I can try and help some more.

[Airikita]

Well, that's what the Arwing uses, so yes, I'm trying to add new model data to it... I don't know what to say about it yet, but can specular affect an actor using the model?

 

Anyways, the Arwing's model uses absolute addresses in it's ram segment, that's why I don't know what to do.

[xdaniel]

The Arwing's model does not use RAM segments - a RAM segment is in play when an address is prefixed with ex. 0x04, or 0x06 or something. If it begins with 0x80, it's an absolute address in the N64's overall RAM.

 

...I guess I don't really know what else to say either... Again, you're pretty much using the program in a way it wasn't intended to be used in, with the absolute addresses and all. The program's only purpose is to convert textures and vertices and create display lists that use them, how to get the converted data into the game is up to the user - the program helps as well as it can, asking for RAM segment and base offset (so that you don't have to manually fix all the pointers inside the display lists), and printing out the offsets inside the resulting file where textures and display lists were written, but it's not supposed to do any more or anything else.

 

Hrm, before anything else, try to enlarge the Arwing's overlay file and get that enlarged file to load properly. If you can get that to work, then try to copy/paste your model, fix any offsets that might need fixing, etc. again. Sorry that I'm not more helpful, but this is beyond the scope of the program, not to mention it's early morning here by this point and I'm tired.