Airikita

LOL, the fix was so minor. Changes have been committed. Done. XD Have cake now: Happy Birthday to everyone (especially those who had birthdays the past month, lol)

Hey, if you can give some information about the 2 commands (maybe your notes?) we can work on this. I can understand if you can't work on it xdan. I just have no understanding of these commands, FC especially. But surely we can manage something. The component missing is where to place the alpha value in the combiner. I have old notes from SoulOfDeity, but they're REALLY OLD notes. I'm sure me and haddockd can work on this fix. This literally just looks like all that needs to be done is the removal of a few flags, and poof! Don't even have to remove the lines like I did, just subtract a few values. Haddockd, maybe you can send me your updated source in PM perhaps?

EDIT: Seems like order matters. The stuff in the background should be last, and the opaque/translucent order remains fine... Although, comparing Spot04, which requires lighting, and is receptive to fog, I noticed a missing command: 0x03 F3DEX2_CULLDL (usage unknown) I noticed that a farther polygon will appear to overlap a higher plane, and also the ground covers up Link. I assume that, by comparing the ground portion of Spot04 at 0x4860 of spot04_room_0.zmap, it seems like this 03 command probably corrects the culling for proper z-depth. I can only assume the farther polygon has a conflicting issue with the culling of the top layer somehow... because I haven't seen the 03 command used anywhere else, and it seems to make sense. I have no idea where to start with display lists... but the 03 command seems simple, aside from what appears to be a 01 reference to normals. The 03 command looks like this: 03 00 00 00 00 00 00 0E. Seems basic, and I can only guess that this is what corrects this z-depth issue, but also the DList coding is a lot bulkier in it. Kokiri Forest's ground DList hex: E7 00 00 00 00 00 00 00 D9 FC FF FF 00 00 00 00 01 00 80 10 03 00 47 E0 03 00 00 00 00 00 00 0E E7 00 00 00 00 00 00 00 D9 FF FF FF 00 03 00 00 E7 00 00 00 00 00 00 00 E3 00 10 01 00 00 00 00 D7 00 00 02 FF FF FF FF FD 10 00 00 02 01 06 18 F5 10 00 00 07 01 44 51 E6 00 00 00 00 00 00 00 F3 00 00 00 07 3F F1 00 E7 00 00 00 00 00 00 00 F5 10 10 00 00 01 44 51 F2 00 00 00 00 07 C0 7C FD 10 00 00 02 00 FE 18 F5 10 01 00 07 01 78 5E E6 00 00 00 00 00 00 00 F3 00 00 00 07 3F F1 00 E7 00 00 00 00 00 00 00 F5 10 11 00 01 01 78 5E F2 00 00 00 01 07 C0 7C FC 26 7E 04 1F FC FD F8 E2 00 00 1C C8 11 20 78 D9 F3 FF FF 00 00 00 00 D9 FF FF FF 00 03 04 00 FA 00 00 00 FF FF FF FF 01 02 00 40 03 00 34 40 EDIT: seems like you need to convert the models with the Model2N64 tool. xDaniel, couldn't you upload the one that worked with the cube? ================================================ EDIT2: CORRECTIONS MADE TO F3DEX2 CONVERTER: ------------------------------------- 1) added lines: E7 00 00 00 00 00 00 00 D9 FC FF FF 00 00 00 00 01 00 80 10 03 00 47 E0 03 00 00 00 00 00 00 0E E7 00 00 00 00 00 00 00 D9 FF FF FF 00 03 00 00 2) removed (Note: just removing these 2 commands seems to work): FC 12 7E 03 FF FF FD F8 E2 00 00 1C C8 11 30 7C Result: Ground is behind Link as it should be. (y) Problem: This does cause a problem for alpha textures... but I can look into that, unless someone knows how to look into the FC commands for maps. Map parts don't use FC and E2 commands though. Maybe FC for alpha textures. Alpha textures (for maps) seem to use the 2 commands, with slight differences: FC 12 7E 03 FF FF F3 F8 E2 00 00 1C C8 11 30 78 The water mesh uses this (for transparency I imagine): FC 26 7E 04 1F 0C FD FF E2 00 00 1C C8 10 49 D8 Once I applied these changes, this is the end result: ----------------------------------------------------- (apologies for the lighting, I was fixing the mesh over re-adjusting the lighting.... ah well) Also, Haddockd, I couldn't have done this without the interleaving formatting. With the wrong ordering in the header format, the map still displayed out of order even with the DList fixed. I do commend you for your efforts, it was a wise insight. That being said... once this is fixed, maybe getting the 02 type to work will be useful for larger maps. Also... I got the formats mixed up when I was reading the information. You had it right the first time, in fact the way you did it is perfect!

Actually, strangely enough Hyrule Field orders the 00000000 BBBBBBBB stuff as non-collision mesh. The translucent stuff seems to be... somewhat-transparent models. Idk, Hyrule Field puts the lon-lon ranch walls as a translucent right next to the bridge to Kakariko as an opaque. The "translucent" stuff after appears to be non-collision background objects... such as the castle towers. I think you're close haddockd. The non-collision mesh is listed after the collision mesh list. The collision mesh is as AAAAAAAA 00000000 and the non-collision mesh is 00000000 BBBBBBBB where all the non-collision mesh is listed afterwards.

For starters, for the mesh header to work, like in Hyrule Field, at 0x58 of my map the first line would have to start with 02060000, because type 02 seems to read it that way. Although, from my test there was some improvement... but I only caused a mess. I can't make heads or tails of the list myself, at least not unless I look into it further and test a lot. Maybe this will help: http://wiki.spinout182.com/w/Maps_and_Scenes#Mesh_Header ?

Well, not sure then... but I can see a glaring problem: When I run it on the console, it doesn't know which end of the mesh is which without proper z-depth values... this seems to be related to z-depth. It might be a result of the fog, or just the version I have. I will download your update and test it out.

I am curious if lighting effects, or fog, might be an issue for z-depth. It appears my map I created with dark fog, etc, shows map mesh in the wrong z-depths. The water layer appears hidden below the ground, and the walls appear behind the exit cone behind the wall, etc... Is this a related issue to the interleaving?

With music like this, why were you going to waste it on a mod? This is high-quality video game music for something bigger! It kills me as a game designer to see original music to be wasted without using it in a proper original game... It literally makes me cry. I find that, if you're going to mod, don't put original content with high potential in it! My god good man! This is music you use to make a new game a smash hit! At first I couldn't bare to listen to the music from URA Project for fear of this... this digs deep.

Testing out a map. It looks strange for now without proper lighting, etc.. but this is mainly for texture alignment. I changed the map design to suit a different storyline. Not that this changes the route, or plot in any way... I'm attempting to make this map break the 4th wall a bit. I want this map to make the player feel exposed. Although I feel like the ground ruins it, and gives a comfort level to this... it might be better after some changes. Also, custom grass ftw. \o/ Animations will be added... some textures are off, like the 128x128 black/white historia texture didn't import correctly... Maybe I was wrong about the size, or FUCK ME I'm just tempted to hack the code to force feed it the 128x128 texture to work. That might require a new scaling format for the F3DEX2 code if I can... seems unlikely I can do jack about it anyways. There's always work-arounds though. ----------------------------------------- EDIT: lighting effects and fog work out quite the difference:

Looks good! I'll be watching for more updates.

Yeah, so looking at Adult Link's "skirt" in OoT here... his DList goes like: DA 38 00 03 0D 00 00 40 D7 00 00 02 FF FF FF FF E7 00 00 00 00 00 00 00 at the start. You need that DA 38 00 03 0D 00 00 40 before the D7 00 00 02 FF FF FF FF. The list you provided doesn't appear to have that either... Since you say the only time it does it is when the mirror shield is equipped, I assume the torso must be the Limb adjacent to the Mirror Shield, causing it to read the combiner from the mirror shield. Just double-check, and make sure the other tunic parts have it as well. If you need help converting it, sadly I'm sick this week, and I've only been poking at 2 things, and watching videos lately. However if you upload the file, I can take a look at the data sometime. EDIT: There's also DE 00 00 00 0C 00 00 00, which seems to be missing... but I'm not too familiar with it's use outside of texture animations.

...it's not the mirror shield, please post the torso display list, and it should start with DA 38 00 03 0D 00 00 40. If your torso doesn't have DA 38 00 03 0D 00 00 40 before it, that might be your issue. DA 38 00 03 0D 00 00 40 is what reads the tunic color code from memory during runtime, mainly a global value of some sort. Unsure of the details, but it is the 0D that determines where it's reading from.

Hi, just experimenting with the 15 xx yy zz text command.

I'm unsure, but it could be a color command or your texture is not set to the right texture. Depending on the hex for that part... maybe you can paste the hex code to just the torso display list?

I think his screenshots suffer an aspect ratio difference... compared to Link's height, it looks fine. I like the main map design, but it's lacking some nicer decal. I'm not saying that it's not nice as it is, because it looks good. I just think the textures can stand out a bit more perhaps.... like the brick looks so washed out and flat when it can look more like brick. Good work with the UV mapping btw.

Epona death and revival sequence, activate. Such a sad fate indeed... Gotta move onto dungeons soon, and giving proper items, but after I finish more important things. Plus I'm sick as a dog, so I'm mostly resting and doing assignments aside from poking around at small tweaks during breaks in-between. I don't have many assignments, but I'm still laying in bed a lot this week.

Er... ok? I never said anything about it being garbage text. /rude

Good finding with the function, but I assume it's similar to the one used for the debugger itself?

Even I don't code that much.... lol. Well, maybe sometimes.

Yeah, so there's not much to worry about. My hookshot test was pretty high-poly when that happened anyways (the overwrite). ------------------------------------------------------------ EDIT: ick

Finally tweaked the storyline to follow the concept more thoroughly: This will definitely add more tasks, but that was bound to happen anyways.

Wow, that piranha plant boss is awesome! I am loving the intricacy of your levels too. That platform tank design is amazingly ingenious!

Not yet, but it's something I'll look into on my list. I'm sure it won't be difficult to find. It's seems like it's just added on after Link's instance by the looks of it. Although I'm sure if you search for 2020 in the memory, you'll find it's ADDIU, lol. Or even set a read type check on the address where the start of that actor is, and reverse-check the address it loads. Backtrace it by looking for what writes that address, etc... EDIT: -------- Seems to be that the gi_object is loaded in Link's instance rather than a new spot just for it... yeah... Anyways, Link's instance size is in his code, and can be found at 803E7010

The grenade is 16B0, but I knew about the limit already. Majora's Clock is 29A0, and I was already aware of the limits. Seems to be safe in small zones with not many objects, like in the pot house/room, or at a shop. So I'm not really concerned. Afaik, I did see code get generated after gi models before when it crashed, and I do have a snippet of it somewhere. where it shows the gi overlapping some code. EDIT: -------- In fact this error occurred to me back during the custom hookshot chain chomp mod:

Found out how to unsheathe the sword without swinging it, with interesting effects: Could be the wrong finding, but it's useful for ZEY. It can be a good indication that the swinging and focus to bow, hookshot, and boomerang could have been implemented in the code in later development. But that's just my thoughts on that.