xdaniel Posted March 7, 2014 Author Share Posted March 7, 2014 The usual besitu replacement patch - http://magicstone.de/dzd/random/teletubbie-besitu.ppf - works fine under emulation, Project64 v1.6 + Glide 64 Final, same combo that crashes with your Stalchildren patch. Should work on hardware (was lazy with the mesh header and display list calls, tho other maps do the same thing I did), but of course it won't be animated or anything. Only change I had to make to the model is scaling it down in Milkshape, otherwise it wouldn't have been very visible in besitu, had to do the same thing with Unicat before, too. That aside and as far as I can tell, I'm rather sure my tool's not at fault here, ex. considering how your patch crashes for me before the display lists generated by the tool are ever called, like before the intro sequence with Adult Link... Your patch does work fine in Nemu64 v0.8 + Jabo's D3D6 v1.5.2 by the way, and the CRC's correct according to rn64crc. Link to comment Share on other sites More sharing options...
Airikita Posted March 7, 2014 Share Posted March 7, 2014 You're not noticing that the scaling is done because the models rendered on actors come out too small. Also, the besitu patch might work but the stalchildren don't. You're going back to besitu and repeating the same results, you're not looking into other ways to test this. It's great the map works, but that's not the apparent issue that needs to be resolved. You keep testing on besitu, which you did with Unicat even though I kept saying how she was failing with Navi. This is prolonging the issue. Also, testing this: http://wiki.spinout182.com/w/Debug_ROM:_Scene_Table I noticed switching tt values causes graphical errors. I don't think you should be relying on maps for this, they're highly inconsistent. Link to comment Share on other sites More sharing options...
xdaniel Posted March 7, 2014 Author Share Posted March 7, 2014 I'm starting to feel like you're trying to argue with me out of spite or something? Yes, I know that certain actors need their model parts scaled the way you did it. I've seen inconsistent model sizes before when working on actor rendering in viewers, so I'm well aware of that. As for besitu, so what other ways for testing this would you suggest? Ones that do not involve hardware testing, because I have no way to do that. Do a Stalchildren replacement myself, i.e. do what you've set out to do but can't get to work reliably, like with Navi/Unicat before? Also, tt in scene table entries is always 0x00 anyway and it's unknown what it's there for in the first place. What graphical errors does that cause? How are maps thus "highly inconsistent"? Also, besitu aside and as I was saying, your patch crashes even under emulation, and before the display lists in question are ever executed, so it cannot be the output of my converter that's at fault. Would you mind addressing that one before ranting about me and besitu? If you can prove to me that your insertion technique is fine and my converter really is at fault here, then I will gladly look into this. Know what? Fuck this. Source here, do whatever you want, I'm going back to SceneNavi or something: http://magicstone.de/dzd/random/Model2F3DEX2.rar Link to comment Share on other sites More sharing options...
Airikita Posted March 7, 2014 Share Posted March 7, 2014 Good job xdaniel, you kept testing on besitu even though I kept explaining how it wasn't working for Navi. Now you get this and you give up after doing the same thing? "Insanity: doing the same thing over and over expecting different results" I gave you the patch, so why not test it over the teletubbie I sent you? Don't use besitu, use the zobj in the patch I sent you... in fact, you can have the zobj if you're still interested. Link to comment Share on other sites More sharing options...
xdaniel Posted March 7, 2014 Author Share Posted March 7, 2014 (edited) I give up because I can't take your bloody attitude anymore. I can't test on hardware, I can only take stabs in the dark, which is exactly why I didn't even want to try and make another converter again. Go back a few pages for that if you want. Just imagine that I never did try to make another converter, just forget about this. Whatever. The converter's frozen as far as I'm concerned, anyone feel free to pick it up. Really don't feel like arguing or whatever. Edited March 7, 2014 by xdaniel Link to comment Share on other sites More sharing options...
Jason777 Posted March 7, 2014 Share Posted March 7, 2014 If I may take a guess, there is likely nothing wrong with the way xdaniel is generating display lists. It's likely a problem with the actor. You can often find hardcoded display list commands in actor code (i.e. Queen Ghoma) that utilize the global context; look at that. Also, Airikita, you really need to stop with the blame game. Link to comment Share on other sites More sharing options...
Airikita Posted March 7, 2014 Share Posted March 7, 2014 If I may take a guess, there is likely nothing wrong with the way xdaniel is generating display lists. It's likely a problem with the actor. You can often find hardcoded display list commands in actor code (i.e. Queen Ghoma) that utilize the global context; look at that. Also, Airikita, you really need to stop with the blame game. We just resolved this, no need for this. I was trying to explain how testing with besitu was not going to fix the problem... anyways, I'm working on the problem. I looked into it, which is why I was trying to get xdaniel to look into it. So, let's move on. EDIT: Apparently the heirarchy had to match the number of limbs for the stalchild. I might have been a bit peeved off, but you can't blame me from the previous problems with Unicat. So, for enemies (and this likely goes for other actors), hardware compatibility reasons, the heirarchy for custom characters have to be the same.... makes me wonder why young Epona still worked. Oh well. Link to comment Share on other sites More sharing options...
xdaniel Posted March 8, 2014 Author Share Posted March 8, 2014 So, once again and kind of expectedly, it was not my tool... And I mainly "blame" gameplay_keep for the Unicat problems. Link to comment Share on other sites More sharing options...
Airikita Posted March 8, 2014 Share Posted March 8, 2014 Even so, testing on besitu when it failed before... I mean, a part swap with an actor proved to be a better test, but overall it's fine. No no, my anger wasn't unwarrented xdaniel, besitu isn't always a good option. But yes, gameplay_keep is special in some ways... curious if I should look into that... To clear things up, when I get mad I don't hate anyone, I was simply trying to point something out. Observing actor models was my next option, and like I said the limb issue didn't make sense since my model has fewer limbs, and I did the same with Epona. So yes, I did assume the tool from previous issues, but I never said it was wrong for what it does. Idk what to say xdaniel, but I am not taking back my anger for re-using besitu. You know the display list better, so I figured you could take a look and run some comparisons. I am stupid with display lists when it comes to the enumerated values of the combiner, etc... we all specialize in something, and display lists are my weak point. Link to comment Share on other sites More sharing options...
Arcaith Posted March 9, 2014 Share Posted March 9, 2014 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. Link to comment Share on other sites More sharing options...
xdaniel Posted March 9, 2014 Author Share Posted March 9, 2014 Arcaith: I believe that's done using either PrimColor or EnvColor during color combining, not via vertex colors, which also wouldn't cause problems with different texture types. Granted, I haven't checked, but it would be the more sensible way. Airikita: Stalchildren, besitu, Teletubbie thing conversion, beginning of first display list each. Teletubbie is closer to Stalchildren than to besitu, yet works fine as besitu's room. While besitu does call display lists in other RAM segments for texture animation (scene configuration / "rr" value 0x31 in scene table entry, creates segment 0x08 for floor, 0x09 for walls), Teletubbie does not call anything in those RAM segments. I stand by the opinion that 1) gameplay_keep is hell to work with, making Navi replacements difficult, and 2) display lists created by this tool are equally compatible with actors and rooms, and factors outside of the data generated by the tool are responsible for crashes (i.e. actor code, hierarchy, plain improper data replacement, etc.). Not that this matters anymore, because the tool is still dead to me. 1 Link to comment Share on other sites More sharing options...
xdaniel Posted June 29, 2015 Author Share Posted June 29, 2015 If you're one of those people who still cling to Model2N64, here's what's probably gonna be my final contribution to model conversion and importing for OoT/MM: http://forums.zelda64.net/single/?p=8441682&t=11206118 2 Link to comment Share on other sites More sharing options...
Recommended Posts