Airikita

Mainly that, but also the converter can't necessarily detect segments. There is also the facts that Actors use that flag that otherwise caused the map to cover up Link. Logically, it works for an actor because of how an actor uses z-depth compared to a map. Since the map was using the wrong flag before, it was treating it like an actor. So if the walls and ground were higher, below, and surrounding Link the map was using z-depth as if it was a convex shape and not acting like a flat surface. Therefore that was why it was likely covering Link for that reason. For another reason, I believe tangent shading is different, but it's possible that actors can benefit from it too. I remember xdaniel mentioning a different type of lighting/combiner for maps. I'm pretty sure that there are different set-ups for maps as opposed to actors because of the rendering differences. In fact, actors use different renders regarding matrices or not. Of course it's possible that the same converter is used, although I do recall there being differences. Unicat worked with the old converter when placed into besitu because her model didn't go beyond Link's size, and I just never bothered to hardware test a normal map after that point for other reasons relating other modifications needed before doing so. There is a reason why maps need a different set-up for the ordering of F3DEX2 commands, because of how the buffer works as part of it. Try comparing a simple DList from a pot to a map, you'll see it will be missing a row of E6 and other commands before the texture rendering. We could try and see what happens without it, but my hunch is that maps use a different renderer than actors because of specific lighting effects. So that is why xdaniel's model converter WILL NOT WORK and SHOULD NOT be made that way because of how it was designed to work with zobj files. If you make it work that way for all models, you can end up with problems (possibly weird effects) on actor models.

I'm not pulling up old issues, because both of us didn't know what to change. I wasn't insisting, but it was poorly misinterpreted. My post was asking for assistance, and perhaps find any flaws that were overlooked. I'm referring, my statement, to the SO converter that was fixed. I already stated that "I meant it in the sense of those who aren't making comparisons.We're all guilty of that at one point in our modding expeditions" and none of my posts were insisting everything. I was trying to co-op, but got dismissed because someone wasn't looking at how the ordering of the F3DEX2 commands from comparisons. I was trying to figure it myself and help improve the converter, so I wanted to make as many tests and comparisons to ensure there wasn't any converting errors. The mistake that I didn't realize was Nintendo using a different renderer for Stalchildren that didn't calculate Matrices. So, hence there were some unexpected issues from that. Blaming each other is not the solution when there was never ill intent, just overworking ourselves when we were making progress. I did lose my patience because I was going through a lot and pushing myself, so let's just put that issue aside. I don't hold grudges. Although... since we're on the topic, I forget if you have ever posted the source to the converter? Or am I just being dumb? NO, you can't, both converters have to convert each mesh differently. Map mesh and zobj mesh are NOT synonymous at all.

Right, I didn't intend that to sound ambiguous, but you so miss details from not looking at the code too. I meant it in the sense of those who aren't making comparisons. We're all guilty of that at one point in our modding expeditions, I'm mainly making a point that there are times where staring at cutscene data isn't going to show you which values control different cutscene actors. For stuff like that you need to observe the code for better results. Otherwise just replacing actors and fixing the ROM to load it every time is slower. I've done live-editing in RAM during gameplay to pick apart the game's mechanics without having to throw guesses. This can be the same for someone who doesn't understand the code, but would like to just test the data. All that has to be done is to read-check the part of RAM, and change it once it's read to get the effect you want. Also, for the error in SO, ALL that had to be done was take the map DList made by SO and put it side-by-side comparison to a scene that already exists. This is my point... certain people are NOT comparing their data when they should. I hear people quitting left-and-right when all I had to do was poke my finger at 2 files, and change one thing. If you're a programmer in the professional world, you will want to learn from this experience. But this can be said for those with big ideas for their mods too.

I would still love to implement a cutscene builder, but that won't be until I get a good start on the first transition to the story in ZEY where I can have a hand at making custom cutscenes. The best way to get documentation, however, is to observe the AI from existing cutscenes and see how they read the values. I'm sure it's more elaborate past that point, but it's a good way to figure out what cutscene objects are used with different indexes. Please start observing the data used in RAM, use the read/write checks in the Memory Debugger to find out what code is using data. I find all too often people overlook this, and don't compare data. I'm not generalizing though... I know we're all either busy, or don't know what to look for. But you won't learn anything by staring at binary in a HEX Editor.

I liked her design, but the ad for her was terribly ironic. The broken and run-down city being taken over by bots... it just represented the browser badly, and as if the problem wasn't obvious enough. I know that, in marketing, when a mascot fails to advertise a product, a company will create a new one. For 2 reasons: to get new attention, and so that they aren't left with the old stigma from the experiences during the previous mascot. OR they might give her a re-color and new clothes.

Uh, I can add stuff to your importer otherwise, especially down the line. Sure, there is another way to do this, but it doesn't matter. It already does more than we asked for, so I see no issues. There is always still going to be things to fix/add, but that doesn't mean there's anything to discard. Also, as a programmer it would be a colossal waste of time to re-create something from scratch. The only glaring issue I can see is deprecated methods, but I imagine someone can find a way to fix that. Otherwise your code is rather easy to maintain.

R.I.P Inori Aizawa You were such a pleb, and a tool.

I don't think that's wise, because a modded ROM can easily have changes to obj dependencies, especially with, uh, me... Or perhaps allow SO to read the object number in the zactor file itself, and use that.

Um, why not get your totalitarian views out of here? You're starting to get on my nerves with telling everyone how to speak and do things. This forum isn't only meant for modding, in fact we should welcome anyone here who is interested in staying. You don't own this forum, so don't act like it's your way or the highway.

It still legitimately qualifies as a Q&A for Gaming. We modders kind of took over the forums. Don't mind us. :3

Ah, there's still work-arounds, but you have to apply multiple textures to different squares. My winged bow once had 4 32x64 textures making it 64x128 wings. I split up the square plane into 4 equal sections (subdividing the edges) and making 4 sections of the one wing. Although, because the wing was conveniently white, I reduced the number of grey scale colors it used to a CI texture quality. I think the new wing takes a full 64x128 CI texture now... that or I scaled it down, which I doubt. Chances are low at making it work though, but it can be plausible.

Looks great! It looks very smooth and shiny for OoT. I'm just curious... are you interested in designing dungeons? I don't know how skilled you are. You don't necessarily have to come up with the layout, but perhaps you can help with ZEY when I get into a problem with making maps. I tend make errors in UV mapping, or my textures are not very clean. Considering that OOT limits the size of textures... I'm still considering the possibility of modifying OOT to use larger textures since it seems to me that OOT used to have higher res textures, especially from what someone told me about the Demo having higher resolution textures.

I'm pretty sure that requires some ASM hacking. Maybe swap his default age and remove a lot of conditions. It's very likely, due to Link's transformations, the checks and conditions can be a mess. Perhaps it might work like the pause menu in OoT, where a central condition determines which panel is active with nested functions and checks. Otherwise, if not, you'll have a lot of code to edit and change. More than likely there's more than a few checks for that.

Uhhhh... see, by fluke chance I needed SO, and ironically Haddockd did a fix that, where I stepped in, haddockd's fixed served my fix. Ironically I would not have been checking that topic had I not imported a map that day. Deus Ex Machina... I know you don't want to hear that, but I don't always have time to add features to tools if I don't require them. Until I find out something is missing (which I won't know without someone posting a screenshot/video, or until I find the issue myself) I can't fix it. I also don't know what to add because I don't have xdaniel's memory. I might make tools, if it were the case that I am able to understand how to fully put together something. I want to make an enemy/boss builder, but I haven't observed actor files enough to make a comprehensive tool. Granted, each actor file does it's own thing. The worst part of enemy files is their collision... the code does weird shit in RAM which throws around float values in an illogical way. Buuut that can be based off of another actor, and then there's possible compatibility issues. I can't work on display lists while focusing on documenting AI. I can't multitask because I take a long time to re-focus on a previous task. Sometimes I'll poke at the mod for weeks until I understand what I'm doing again, or where to continue. I cleaned up a lot of errors and mess too before I moved onto a new task. There's going to be unavoidable mass clean-ups eventually near the end too.

If you were using the public build 0b, it's hardware compatible. Or one of the public builds... I worked with xdaniel to have a proper converter.

No worries, I'm just ripping on mzx. I sent him a download of part of my Kokiri Forest map. Here: http://www.mediafire.com/download/4huaka10b35ms81/demoKF.zip Feel free to use it as a test file.

Then make something quick, like a flat square with a smiley face texture on it. Maybe that'll cheer you up.

I will allow everyone to download my notes on audio. It is missing some details, such as the buffer size at 0x8 at address 80171A0C for music sequences, but feel free to have a poke around and play with the values. It's difficult to get a fully rounded sound from the notes, but that's up to whoever is willing to have a poke around: http://www.mediafire.com/view/enlmcd8tcei1xja/AudioHacking.txt I also didn't list the other values I changed, but I did list a nice ASM hack for a nice smooth bass boost for the notes. The snippet at 800E9108 did a stupid truncation, making the notes more like a sine tone. Very flat and blunt notes. The Ceil command adds a slight bass boost and calculates the full value instead of the partial fractions, which adds a roundness to the sound using the full peak of the frequency rather than trimming that nice fade at the edges. If you don't truncate, however, the notes will have a lengthy fraction causing the sounds to drag out, which sounds like a mess when a sequence plays over itself. Any overzealous value changes can cause an overcalculation for the echo, which uses the sample rate as part of the calculations. This will cause a buffer overflow in certain situations. Even the attack volume of a sequence can lower the overlapping of float sequences, making the size of the sounds less bulky in RAM. You'll notice a significant clarity with the suggested sample rate, and a possible emulator crash. 48kHz is the limit for N64, so don't expect your audio plugin on your emulator to sustain a heavily orchestrated sequence such as Hyrule Field music or mini game music. The value changed is what calculates the decompression of the AIFC audio sound files, so it's not using a higher sample rate file, but rounds the file up to a higher sample rate quality in-game. In fact the decompression is clean and smooth, making the tones sound a hell of a lot smoother than a higher sample rate sound file due to the sound manipulation in the code itself. YES, your audio plugin will crash the emulator if you're not editing the proper values. ------------------------- Note: I will do more on finding the sample rates of individual sounds... but it might be that all instruments use the same sample rates.

Are all maps hardware compatible now? If you want, I can test and do a clean-up for hardware stuffs if you haven't. But I'm not sure how out-of-date your other maps are. I'd love to add it to my collection for my flash cart ROMs. I think Petrie911's hack was all hardware compatible since he just did mostly code hacks.

Er... that defeats the point if you have a default map for the tool. There's a readme with it, if the modder isn't going to learn to read, not our problem.

I see you're using a different sprite, did you create a new file with Mario's old file and removed gravity?

Well the logo is divided into 6 parts... so that might be part of it. But you can find the first corner, then change the size of the texture found to show all the logo pieces.

Yeah, I didn't want to just make my reply a "welcome back" post... I was already surprised to see you online.

Try dumping the texture with rice's plugin, and use CloudMax's texture explorer to find it: http://www.cloudmodding.com/n64 It also imports textures cleanly with no pixelated messes, especially when it converts ia textures.

Yeah, it happened on a clean ROM before. It's a video plugin error.