Strati

For now. I'll have to settle with what I've got - is not THAT bad. Just gotta figure out how to change colors dinamically - as it appears to happen with the standard tree cones. Thanks for the help. @ SanguinettiMods: That was just a joke, no worries. It explains itself that by expecting HT to output exactly as Model2N64, I could brush it off at my own loss, since it seemed to be working to everyone else all this time - as you just kind of confirmed, saying you never heard this specific problem before. If there is a chance HT will fix the lighting, I'll have to ask someone else to try importing the tree model's .obj file. EDIT: Found the right instruction! Thanks SoulofDeity! http://glitchkill.proboards.com/thread/5930/most-difficult-f3d-instruction-cracked

Bad luck. F5s pratically blackened everything, including the alpha. F3 glitched up the textures.

I was forced into learning F3DEX2 commands to make small fixes to the Model2N64 Import, namely the backface culling flag. Basically, I'm doing what xdan suggested: taking pieces from here and there, throwing different values at different places expecting a reaction. So far I have a small lead on the GeometryMode flags from reverse engineering parsing codes. If I got these flags right, disabling lighting didn't change anything. For a matter of assurance: D9 Fx FF FF 00 0y 00 00; x => 0100 = lighting bit; y => 0010 = lighting bit. Combiner modes are something I haven't delved in yet. It looked rather complicated from the outside, that's why I came here for help. Here's the DL by Airikita's request. By the way, the F5 command is SET_TILE (I had to mess with texture mirroring). E7 00 00 00 00 00 00 00 E3 00 0F 00 00 00 00 00 D7 00 00 02 FF FF FF FF D9 F3 FB FF 00 00 00 00 D9 FF FF FF 00 03 00 00 E3 00 10 01 00 00 80 00 FD 10 00 00 06 00 95 D0 E8 00 00 00 00 00 00 00 F5 00 01 00 07 00 00 00 E6 00 00 00 00 00 00 00 F0 00 00 00 07 03 C0 00 E7 00 00 00 00 00 00 00 FD 50 00 00 06 00 8D D0 F5 50 00 00 07 01 80 60 E6 00 00 00 00 00 00 00 F3 00 00 00 07 3F F2 00 E7 00 00 00 00 00 00 00 F5 40 08 00 00 01 81 60 F2 00 00 00 00 0F C0 FC E2 00 00 1C C8 10 30 3C FC 12 7E 03 FF FF F3 F8 FA 00 00 00 AA FF 44 FF 01 01 40 28 06 00 95 F0 06 00 02 04 00 06 08 0A 06 00 04 0C 00 0E 10 12 06 0E 14 10 00 16 18 1A 06 16 1C 18 00 1E 20 22 06 06 24 08 00 1E 22 26 DF 00 00 00 00 00 00 00 Lol. Sometimes I think you are a Hylian Toolbox Bot in disguise. I even tried HT before, but when it prompts a save dialog after importing, the supposed new file is never created for me. Finally, this might be wrong, but HT also uses Model2N64 to import .obj models, thus giving the same display list output, no? If this "almost" ever evolves to "exactly", feel free to ask.

Is there any way to alter a display list command to null or diminish the sunlight shading, so high contrasts like these won't happen?

Given the right amount of discipline, I'll be happy to guide you through all this OoT modding stuff.

Updated patch Link blood added; Lizalfos/Dinolfos and Dodongos fixed.

Something must had went wrong then. Blue blood is Lizalfos standard damage effect. Link's blood might be more complicated to get. Will see what can be done about it. I'm in a process of documeting many actors hitboxes to find a pattern. My guess is that each actor category employs a different way of loading collisions. So far, the horse hitbox seems to allow only touching, not hitting.

I forgot to list the enemies changed: Dodongos, Keese, Lizalfos/Dinolfos, Kid Dodongos [not tested], Moblins, Wolfos [not tested], Guays, Twinrova, Ganondorf, Cuccos, Gerudo Guards/Fighters.

Debug ROM patch: http://wikisend.com/download/327818/hemorrhagic.ppf Seriously, I didn't think this would be such a big deal to some of you people. Enjoy.

Thanks, I'll work on them. A couple things: I'm not sure if you can actually hit octoroks with anything that would gush blood, I may be wrong though. I feel that BigOcto should bleed blue - maybe it already does. Don't ask me why. @Spire: I haven't actually tried anything, but there is a possibility of making NPCs bleed too, of course without any real damage. No harm trying.

Got those working... well, except for that Ganondorf green censured blood. Anything else, sir?

So... I might have stumbled on a way to change the damage animation and could use this request for blood to do some proof-testing. If there's any interest, could you list some enemies that in your opinion should have the bleeding effect in OoT?

I remember Swat Cats and Mummies Alive. I'm not sure if the others ever aired around here. Well, to list some: It's weird how cheesy they sound in english. I bet they would sound horrible to you my language either...

I think that's the whole point of making an engine, ain't it?

Lol, I think this is it:

Nice trailer, heavy. I know this song from somewhere... this chord progression is awfully familiar, but I can't quite put my finger on it.

*chokes inner orthography nazi* I'll try to do a step by step: Change your last 4 digits in each waterbox's properties in Sharp Ocarina to something like EEEE or AAAA. Give each a different one, for identification. Once you inject your scene, open your ROM in the hex editor and go to the the address 2D00000 (unless you changed the standard injection address); There, look for a sequence like 03000000 02nnnnnn. Once you find it, take the nnnnnn part and add it to the starting address. E.g. if your nnnnnn = 000208, you should add it to 2D00000, getting the new address of 2D00208; Once at this new address, you should find a list in this format. As you have 4 waterboxes, you should find something like 00040000 02mmmmmm nearby. Take the mmmmmm and do the same process as earlier: add mmmmmm to 2D000000 and go to this new resulting address; When there, you should notice - a few digits later - those waterbox properties values I told you to write earlier. Let's say your first water box was changed to 0000AAAA and you want that in room 8. Open your calculator, change it to hex mode and left shift the room number by 5. 8 will give you 100. Put 00 at the end of it - 10000 - and overwrite that 0000AAAA with 00010000. The standard waterbox "properties" is 00000100. If I'm right, that 1 is related to environments and you must add that 100 to your result, getting 00010100 as your final properties value. Room values up to 7 can be written directly into Sharp Ocarina, since the left shift will fit inside 4 bytes and the program will accept it without vomiting an error message. That should do it. Good luck.

DeathBasket posted a solution for waterboxes here: https://www.the-gcn.com/topic/675-sharpocarina-zelda-oot-scene-development-system/page-4?do=findComment&comment=11155 Although Sharp Ocarina has space for entering 8 digits in waterbox properties, it won't accept values higher than 4 bytes (u16), thus the ones required to define the room. That value could be entered directly using a hex editor, but it's a bit of a hassle having to fix that every time you make any change to your scene.

Importing actors from MM might be a lot harder than it looks. What maybe could be done is to change the code to upscale the door size and associate a secondary texture scheme if a specific variable is chosen. I can't assure you I could do all that, though - specially about including a secondary texturing. Would be cool, nonetheless.

A lot of stuff works on Nemu because it has a "ignore errors" option going on. My guess is the other emulators run a CRC check, so every little difference counts.

Thanks for *cough* everyone's *cough* feedback. The size was scaled down to 0,6 so it doesn't feel that empty. I hope you were playing with adult Link - using kid Link must had made the size discrepancy even worse. That area will be reworked into 3 different maps. I'm thinking of changing that useless space into a NPC populated zone. Right now, my idea for there is "Goron's Camp". About the trees - as I want to keep them as actors - if I could figure out how to change their collision together with the display list, it is in my plans to, at least, make them fatter than what they are right now. Finally, water flow wasn't even supposed to work. It will be set it to the lowest strength next time.

Well, first I asked for Spire's opinion on this, but I guess the more opinions I get, the better. I have this map I'm quite unsatisfied with and would like you to try it for a bit and tell me all that's wrong with it (don't hold back!). Things to overlook: Grass texture isn't very good-looking (I'll see about multitexturing it); Any water transparency different than 255 will make it disappear entirely; Some textures have a problem with the alpha, showing a kind of border (Must be fixed within the display list code); No river or water texture animation; The few actors placed. Some issues I myself can tell: Land size looks unproportional to Link, giving an empty feel to it; The overall water depth - well, to be honest all about water here is wrong somehow; That region with the rocks is completely useless (in alttp too). I'm accepting suggestions about how to make use of that space; Land/map division also may not be the ideal one. I'm thinking of modifying this region entirely. What do you think? ZoraRiver.ppf Debug ROM, usual sasatest scene.

Most likely yes, unless I missed something along the way.So, this 0C command is a sort of lamp/Sun effect? I don't get exactly what "transparent cape" means. I'm thinking of something like Farore's Wind green ball. Is it right?And talking about environment colors, I don't know if this was ever documented, but here are the 12 standard environments (Well, those assigned by Sharp Ocarina, that - as far as I know - are obrigatory)1 - Dawn2 - Day3 - Sunset4 - Night5 - Underwater Dawn6 - Underwater Day7 - Underwater Sunset8 - Underwater Night9 - Storm Dawn10 - Storm Day11 - Storm Sunset12 - Storm Night

Oh, wait.... aren't we on a Zelda modding community? How convenient...

Yes, no need to ask. It's not like I have any property over that information anyway. By the way, wasn't the 0F command already figured out? Sharp Ocarina even has means to control all those colors and fog/draw distances and assign new environment settings. Finally, the code for command 09 is almost moot. It has only two instructions saving values to the stack, that aren't read before being overwritten.