xdaniel

イオシスjkガールズ - すているめいと！ (D-Frag! OP) HIGH TENSION de HIGH na HIGH TOUCH mainichi JETCOASTER You wa stun understand kibun wa joujou TUNGSTEN I never know why! Maybe my favorite anime OP of this season (or at least tied with Mikakunin de Shinkoukei's), perfectly complements the crazyness/near-insanity that is D-Frag~

So, I guess that edit means it's working fine now, even on hardware? Also, feel free to modify the patch further then, ex. to remove the wings if you need to or whatever. I didn't bother with them, I just wanted to get Unicat working somehow.

Having spent a few hours trying to replace Navi, I came to a few conclusions for myself: Working with and/or replacing existing display lists inside gameplay_keep is a pain in the ass; finding usable space inside the file is, too. Just pasting conversions created by my tool to replace Navi won't work. I do not believe this to be a problem of my program as such, but rather down to how ex. Navi's original data is structured. There are a few things here and there that I think I'll have to double-check in my code, but it is not completely broken, seeing how Unicat worked fine as Besitu's room model. I'm on the fence about accepting any more bug reports when replacing things inside gameplay_keep, considering the above points, as well as me being unable to verify that the user in question (no matter who it is) didn't accidentally cause any glitches inserting the data into gameplay_keep. All that said, this patch replaces Navi with Unicat and it's not a straight up, vanilla conversion made by the program. If it works on hardware, and you'll like to use it in your project, keep in mind that I had to replace another texture that I think is unused / used by an unused actor (0x42530 in gameplay_keep, 0xFA0530 in ROM) - you might want to check if it's really not used normally.

Ah, I thought with "tried both" you meant Navi and the patch, not Navi with and without ForceRGBA... Could you try the patch then, as well as maybe another actor with a separate object? Take your time, tho, as I gotta go soon anyway (3:30 am by now...)

Any change with a conversion that had the ForceRGBA option enabled, as mentioned in the edit? Because that's probably the culprit then, if neither the patch nor injecting over Navi worked.

I'm quite sure it's correct now, ex. considering the commands that matter most (SetCombine, SetOtherMode_L/SetRenderMode, GeometryMode) match up with ex. those in the Deku Tree's first room, for the vines and wooden plank walkways. Did you try the patch, or did you manually inject her in place of Navi? If it's the former, it's something I'll have to look into soon, if it's the latter... I dunno. Any chance you could try replacing a different actor's model with Unicat - say the Gossip Stones or whatever; a simpler actor with a separate object file - so that we can be sure it's not the way you're inserting her into gameplay_keep, and that it's the fault of the converter for sure? Edit: Oh yeah, maybe try the ForceRGBA option first, I gotta say I'm not 100% sure CI-type textures (which Unicat gets converted to by default) and alpha channels go together well. Works in emulation, not sure about hardware.

New build coming in a bit, will edit this post later BELOW. Some notes: Texture data after display list will have to wait, if I can get this to work cleanly at all. The display list generation code need to know each texture's offset, and I'm not sure how I'd feel about having it semi-manually modify each generated display list to change where each SetTImg command points. Will keep this suggestion in mind for the future, tho. Fixed Unicat's alpha channel under emulation (Glide64 Final), the problem appears to have been a combination of incorrect parameters in SetRenderMode and SetCombine. I'll also post another patch of Unicat replacing Besitu's room model when I post the new build, so that those with flash cartridges can try it on hardware. Airikita: Once I've posted that build, if you want to try inserting Unicat again and report your results, please try it on a completely fresh ROM, just to make sure there's no remnants of your previous attempts or my program's faulty conversions still in it. Again, new build (and test patch) coming in a bit... EDIT: Converter: http://magicstone.de/dzd/random/Model2F3DEX2-PublicBuild0b.rar Besitu Unicat patch: http://magicstone.de/dzd/random/unicat-besitu-2.ppf

Yes, I need to make documentation for this, but I've pointed you to how this works (that is, toggling lighting and culling via group names) twice or more, to the post that explains this in detail. The post keeps mentioning how it's the names of groups in the .obj standard. I used the term "group" in that post too, so you not realizing that's what I mean and that the "Groups" tab in Milkshape corresponds to that... that is not my fault. Still not having proper documentation written is my fault, yes, the conversion still having bugs is my fault, yes, and so on and so forth, but a user of the program not making the connection between two identically named things in the program and their modelling program - even after specifically being pointed to a post that explains this connection - really is not and cannot be my fault. I appreciate the feedback you're giving, even when it's sometimes not as detailed as I would've liked or when it has snide remarks on the side, and I really don't want to offend you or anything, but come on: You're the one who needs to know the GUI and features of the program you're using. And I've explained before how mine of the two programs works.

There's a multitude of modelling programs people might be using, and I really can't write down detailed instructions for each and every one of them - this is not something to hold against me. In fact, I only have Milkshape installed because either you, or someone else on here, once had another question about the program in relation to the old Model2N64. If this was some uncommon option or whatever that's not supported by most modelling software, then I would certainly give more detailed information myself, but something like this really should be in the care of the user, not the developer.

It's technically not my job to check how to do this-or-that in modelling programs - it's to write this converter, which I'll have to get back to soon, I know! - but anyway... "Groups" tab on the right hand side of the window, select the group you want to rename, change the name in the textbox next to the "Rename" button, then press said button.

I dunno, thinking back to ZSO/ZC, I probably wouldn't call him paranoid - hell, if I remember correctly, he streamed himself working on UoT a few times or so, using some remote desktop software... Anyway, as for this kind of stuff having taken long with the original OoT: Remember that this is an actual model format similar to what you'd see in most PC, GCN or DS games, for example, while OoT N64 had our "much-loved" display lists and their raw commands. For the N64, we basically have to emulate the N64's hardware to an extend, while with OoT3D, we can feed certain data to OpenGL literally unchanged, as long as you set it up right. Hadn't it been for this kind of similarity - ex. had we had raw PICA200 commands to deal with -, this too would have taken a lot longer than it actually did.

1) A crappy video I made yesterday. 2) I think this might be the next thing to try and emulate, this being part of that...

Just dumping assorted reaction tweets of mine from the last ca. 2 weeks here~