Airikita

I'm currently revising mesh header type 2 from the wiki: http://wiki.spinout182.com/w/Maps_and_Scenes#Mesh_Header It doesn't seem like it was given a proper look-over, as I am comparing data with the map of Kokiri Forest, and the ordering actually appears to be: a and c = X and Z position of first display list (using rendering distance) b and d = X and Z position of second display list (using rendering distance) More appropriately: a and b = X positions, c and d = Z positions. NOT "a and b, c and d", because I used an actor to position the hex of the Twin's House: 046E 00AE 025B 0133 03008ED8 00000000 0x046E = 1134 0x025B = 603 I also noted that type 2 mesh DOES NOT use distance. In fact, based on a position I used, everything rendered when Link was FACING that position... NOT when Link was at a certain distance. Result of observation: This is useful for building large maps, and can help a ton for those making high-quality 3D maps. Mesh types 0 and 1 are not good in terms of this. It also seems as though the ground is connected to a central path component: 02C0 0132 00AF 0A0A 03004860 03018048 My guess is that when there's 2 display lists connected, they share rendering together, and will render together based on either x and z positions. But I have not tested this.

Yes, this is a possibility. Look for information on RAM expansion on the forums, and here's a note on Scene RAM space: More RAM space for loaded objects [More space for scenes/maps]: -------------------------------------------------------------------------------------- 80097DFC|80097E1C|80097E44|80097E6C|80097E70 -> change to 3C110020 (or higher if need be) *this is to allow more space for certain bigger files, such as Link's file, but maybe others as well

Well the model glitch is a strange problem... although, as for the guard... unsure. He should appear if you are using the same scene number as the original Market... if you're using a different scene, a lot of actors tend to check for their storyline scenes to appear in. That will require some ASM hacking to fix.

I was starting to think that perhaps if you re-opened SO after saving the file... perhaps it would fix itself then. However this is still an issue with the BinaryWriter class used... I'm sure SO is using the file size, that was opened previously, to determine the offset size... but it should determine the new offsets by the new byte array. Perhaps Haddockd might be able to look into that, might be in the code where my last revision was. It's late for me now, and I have a report to work on this week.

Oh, I didn't realize you were using "exporter"... ah well, I should check out the exporter one then... didn't know he had that option too.

Probably. You can experiment with UoT (the old version) which allows you to move individual vertices. You will have to experiment with it, but you can also cheat by using CloudMax's texture explorer by loading the gi file into it, and finding the textures on it.

If you're using Blender (or something else maybe?), the obj file isn't exported correctly for SO to read from properly. You can convert it with Milkshape by importing it, smoothing the faces (Ctrl+M) and exporting it. I am unsure why it is SO can't read it... but I haven't really looked into it. There might be other obj exporting tools that might work, but I haven't tested much else.

No, the gi shader is basically the "shiney" gloss that covers the model. That "gloss" will not be compatible with your new gi model, and will crash the console because of DList error checks. Or it will look really ugly if you remove the error handler for it. There's no collision to the gi model. It's more about rendering it.

I wish it was an easy model swap... however, I can guide you on shaders... Part of it is your items you gain for one: http://wiki.cloudmodding.com/oot/Get_Item Part of this will rely on your object number... given. However, if you change your gi model, your shader will have to be changed to match the offsets of your new file. Take this one for example: Deku Nut: 02 8C 0C EE 34 00BB Basically what you're looking at is the GI ID (0xEE in this example), this gets your object offsets from a table list. If you open the Deku Nut gi object in a model viewer, you can find this offset for the nut model: 0xE90 If you write it using the 06 bank (to reference the gi model) you get: 06000E90. If you search for this in ROM, you should find something in the shader list such as: 8006A5F0 06000E90 00000000 00000000 00000000 00000000 00000000 00000000 00000000 This is index EE from the GI ID listed above. Since this only has one 06 reference, this means this gi object can only load one 06 offset reference to the gi_nuts model loaded via object number 00BB. If you replace the model, you can basically import a NEW obj binary, and change the 06 reference to your new model. To be even more clever, and add more parts to your gi model, reference the offsets in the file in the file itself using DE000006XXXXXX ending with DF0000000000000000 to make it all collected in one offset of it's own to work with the shader reference. If you want to make it hardware compatible, you will have to modify the function at 8006A5F0 to work without any excess display list commands it adds on in RAM, the "shader" component of the gi model.

Oh, btw, here's a link to my topic on error handlers: ----------------------------------------------------------------- https://www.the-gcn.com/topic/3006-the-bish-moan-function-exception-handler/?hl=console

Feel free to look around the forums. One of the error checks is 80001FF0, if this function is called any time, it's always going to crash the console. You need to skip over it from the source of the function that calls it (you can't just force it to skip, it doesn't work). Also, sometimes console crashes can occur because of bad ASM reads. I made some changes in code that caused the code to read from address 00000000, which is impossible on console... so instead the N64 OS crashes. Main thing is to be careful of your changes in ASM, because Nemu will just think it's all A-OK when it's not. Key Note: Nemu doesn't give any fucks what you're doing, but N64 will choke you for every little modification blip.

Hmmm... well if you want hardware compatibility, a simple model swap won't do you any favors. There is a way to fix the renderer function that is used for the shader in order to remove any conflicting F3DEX2 commands. I used one rendering function, removed the "shader" F3DEX2 commands added to RAM, and just re-used it over and over for every new gi model. You have a limitation of about ~0x3000 (a bit more than that, but close to it) for a gi model.

Sometimes it can import the textures for RGB5A1 incorrectly, but a restart will fix the issue. Other than that, it works like magic.

I just realized that SO doubles the size of room files (zmaps) and adds an extra display list underneath the legitimate one. Not only that, but the 2nd set of DLists is completely malformed, and not even in format. That can chew up the RAM easily... for now I suggest modders look at their zmap files for now to see if there's excess. In the meantime I'll be poking at the source. ================================ EDIT/UPDATE: -------------------- A fix was made to SO to prevent large files from being saved. Turns out a method used in the file saving code was just overwriting old data, keeping the file large if it was previously a larger file. This will prevent any errors from missing the excess data and re-importing a huge map if the modder made it smaller than before. I will message Haddockd to re-build it.

Did you set the offsets correctly? Did it import to the correct location in ROM without overwriting something important? Send me a link to the binary of the scene and room that is the culprit... it could also be a possible increment issue.

There was also some minor tweaks: Fixed the order of the FC and E2 commands to be placed before the D9 commands (something I noticed in other maps.. it MIGHT make a difference for something. Just a precaution) And the room tab, for the offset entered to inject the room into rom... the textbox only allowed 4 digits to be entered. I lengthened it to the proper size of 8 characters. And yes... animated textures with notes on how to activate them. The rest is up to the modder, because 0x31 isn't the only possibility. I may work on setting up the interleave settings for bank 2, but it seems like just entering in bank 2 requires the proper value for the scene entry too. I will likely need to add the ability to select a scene to replace from a list if I do that, so it won't be an extra add-on that is simple. Maybe even cutscene creation... but don't hold me on that one. I'm not familiar with OpenTK... Also, I will need more documentation on cutscenes to work with.

Yeah... a lot of blood, sweat, and tears. There's notes on it strewn about, but I'm the one working on it. It's not an instant thing you can do. You have to dig for exception handlers, and have a console to test with. There's one hidden somewhere right now that I don't know where it is. I post a lot of new findings, but this community doesn't have all the answers... Part of hardware compatibility was getting the Display Lists generated properly with the model exporter... The console is finicky, so Nintendo put in a lot of exception handlers which aren't always necessary.

0x01 F3DEX2_VTX Fills the vertex buffer with vertex information (ex. coordinates, color values) Basically the command needs to be called after the first group after the 01 F3DEX2 command. ...Seems like I'll just make a note for the animation value ====================== EDIT: SO now has been updated with the animated texture option. Feel free to build it whenever Haddockd.

I have also implemented a feature to add the animation DList commands to a mesh group of your choice. However I have not implemented the overwrite for the scene value for the animation to work... I will check into this. I also need to test before I can confirm it is valid.

lol, don't worry about it... I'm working on the source to see if I can implement it. I'm loving the ZScene.ZRoom array. Nice easy maintenance on SO... except I'm unsure where the 01 commands are added...

Well I didn't implement the DList for texture animation... I would assume the generation of 01 and 06 commands are recursively added to the binary in SO, where E700000000000000 DE00000009000000 would have to be added on the 2nd 01 command before continuing the rest.

Testing out the animation DList and values for the scene list: I utilized the water temple scene values for this... not sure if the skybox is an issue for hardware yet. Just a fancy little set up on the DList for the walls is all I needed after: The UV mapping is sloppy atm because it was just a quick test, but it appears to rely on UV mapping to determine the direction. All I did was a quick cube unwrapping.

lol, it's fine xdaniel. We fixed it. It might be incorrect, but it works well now. I don't think I could have figured it out without haddockd's previous fix, because it did make a difference too. I think it was just SO confusing until recently. So I can see how such a tiny problem could have been a hassle. We don't need to make any other confusing changes. ==================================================== EDIT: ------- Currently working on an animated texture feature... will need to test a bit before I can validate it. I will also need to add some code to add the animation value when injecting the binary into ROM.

Well, I don't know where you even call it for one. I can check into this, but your methods are a maze to me. Fixes can still be made. EDIT: yes... I found the 0x1C, but are you not setting this as something else elsewhere? EDIT2: You had 0x1C, where 0x04 was a flag to ignore depth compare on maps. I already tested this on hardware with this minor change to all the parts.

Yes... in fact, I can upload the file if I can figure out how to compile it. I could add other features to it. The updates are in Google Code, I made notes. I had to remove flag 04 from the DC (at the end) in the E2 command. The 04 flag somehow caused the game to think the map DLists had no depth. Otherwise, it seems the FC command is perfectly fine and doesn't need to be changed. Now... uh... pardon me while I play with my N64 for a bit... *runs off*