spinout

ovl_En_Vase is the simplest actor in OoT. The only code it ever calls is a display list rendering function. It was rewritten in C. https://www.google.com/search?q=ovl_en_vase

Cool work, xdaniel. Is this more of a frontend for a library you're writing, or what? @everyone: Awesome imports! re: Airikita [offtopic] The size of actor files is vital to their loading. I wouldn't reccomend changing the file without throughly understanding the actor format, or editing them as zovldis disassembled actors. Anything else will mess all the relocations and other information up. Check out my video on youtube of . I once found a value for gravity, and it wasn't as cool as I expected. It is a signed value, normally negative. I never tested it with anything but link... Come to think about it, it probably only affected link.

At first I didn't look at this very thoroughly and I thought it was some oddly glorified hex editor. But as sakura said, it is a very useful, interesting tool for tuning the values within actors, in the case that you just want to "tune" an actor rather than disassemble and then reassemble.

Well, I know for now that the line of code is actually found in file code.zdata, which is ironic but not really... it seems to be a case of inheritance or composition in this case. Seems as though a function/method is used from code.zdata in order to create these things. It's possible that there's more than just this item spawner in code.zdata than meets the eye... Knowing this, it's possible to dig up more AI-related data if this is the case, since the file is very large. So is that a no on the details?This is exactly what I was thinking. It is quite a surprise that it didn't end up being in the actors, but like JSA said, details!

From what I've seen your just really blunt/too serious some times, in comparison to other members. That's about all I have to say.

void kill(RamActor * actor) { actor->ActorDraw=0; /* Actor drawing code executed if non-zero */ actor->ActorMain=0; /* Actor AI code executed if non-zero */ } Seems to work fine. The game figures out that it's no longer needed. Of course, you could always do: actor->next->previous = actor->previous; actor->previous->next = actor->next;

Alright! Registration is only possible now through OpenID. So uh... If you have an old account, you should be able to convert it, or you can stick with it. If you don't have an account you can create one through OpenID. I'm currently in the process of updating some SQL tables for everything to run smoothly after the OpenID extension but it should all be done soon.

All user pages are cleaned up! yay!

Thanks, xdaniel. You're the man. I haven't had time for this stuff recently. EDIT: I think I stopped having time to keep up with bans on the 27th of May. I only banned accounts that posted spam though... I doubt the spammers are going to use accounts that are older than a few months old, maybe we could stop at August or so, then ban any accounts that are older if and when they post spam?

disabled registration. deleting all user pages, they are the ones filled with spam. will finish this job later, i'm working a lot recently. computer time is down to an all time low. edit: xdaniel, you're now an admin. Zeth, you've always been an admin. If you guys want to delete user pages that'd be totally helpful. Sorry for letting this problem manifest itself. Helpful tip for deleting pages: open a whole bunch of tabs (ctrl+click) from the page with the list. Go to the first tab, then alt-shift-d to go to delete page, backspace then enter to delete, and then your browser's close tab hotkey (ctrl+w) for me. No mouse = faster. I gotta get to bed tho, only have 8 hours between shifts, and I've been off for an hour and a half and still have to sleep. edit2: delete everything on this list but the main page (and any other page that sticks out as notable) edit3: another list edit4: list of people to ban; blue links are pages that should be deleted.

Virtual, in this case, means where the files would be if the rom was decompressed. Decompressed ROMs have the same virtual and physical addresses for each file, except no physical end address is provided, indicating to the engine that the file is decompressed. As for this topic, I once integrated the "A+C" interface to ROM. I don't know where I put the source but try applying this patch to a clean debug ROM and looking at the differences. Nemu will be your friend as far as figuring out this stuff goes.

... There are a lot of bugs in the current release version. The version I am using is tuned too specifically to be a release version, to be quite honest I need to devote some time to using librawimg in libobj. I apologize for releasing software which doesn't work up to it's own spec. I just get bummed out that nobody expresses interest in helping me with my programs. Maybe it's the way I write them. I don't know.

I smell a photoshop fanboy... I would reccomend GIMP, as paint does really low quality JPEG compression

Simply put, they are JPG (JPEG) images. The one for link's house is at 0x02B64480 in the Debug ROM. You can find a full list on the wiki. Welcome to the forums, by the way! http://wiki.spinout182.com/w/Zelda_64:_JFIF_Backgrounds#List_of_JPG_Renders

Great work. Put this on the wiki!

BMP textures don't seem to be working with it. I use PNGs strictly.

Arcaith: Yes, a community collaboration would be great. Re: GUI, I've found that knowing hotkeys on the keyboard is much faster than moving the mouse around all the time, in both SU and z64anim. Objects, unlike maps, can easily be scaled in the actor.

It's funny you should mention this, I'm in the process of rigging an NPC for OoT. I did slight yet very hackish modifications to a couple of tools and a fair bit of hex editor work and have a method down but it is a complex setup with many shortcuts which would took me a long time to figure out and would take even longer to explain. I suppose I could make a few "hack" releases of the modified tools - but in all fairness the tools were modified specifically for the job I'm currently doing, and fail my personal standards for software I wish to publish. EDIT: actually, what the hell. I'll review my method: Build each component of charachter. Correct normals in modeling software. Export each with their own origins to their own obj. (I'm using SU pro built-in OBJ exporter, no problems so far) Modify the objs to all use the same mtl file. Ensure all images are non-interlaced PNG (objn64tool bug. Ideal new builds will use librawimg, but that doesn't support BMP yet anyways) Import them all at once as separate display lists, so you don't repeat texture data for each piece of the model (requires a special build of objn64tool) Build hierarchy by hand in hex editor. I used a couple of lines at the python interpreter to help me out with the more redundant parts. Build animation(s) by hand in hex editor Configure animations and hierarchy in z64anim (I now am running into the bug where it won't save changes. Just save with a different file name then save to the original name again. It will eventually save. Double check that the changes were saved by loading the file in another instance of z64anim) Realize that you need to remodel 60% of the model. Return to first step, repeat. The hierarchy and animation can be reused if you don't change the bone structure again, you just have to fix any pointers that changed (basically all of them)

Link's coordinates or rotation? The user has no control over the least significant bits, so take the least significant 8 - 16 bits of the player x and or y and or z.

Current ROM compressors (my Yaz0 and LZO compressors, ZZT32's LZO compressor) ignore anything that isn't pointed to in the file table.

JSA's DMA "fix" only works with decompressed ROMs. It will miserably fail on compressed ROMs. As far as link's file creating problems, that doesn't have anything to do with the filesystem - the game only reserved so much space for him. My suggestion: remove all the low polygon models and consolidate his object to a smaller size, then add what you desire.

The way the LZO hack reads the filetable, it doesn't have to be sorted, therefore you can just put files at the end of all the other files. When the ROM goes to be compressed, any files which are no longer needed are ommited.

I would, except for the fact that my LZO hack makes it completely unnecessary. What should be under development, in my opinion, is porting the LZO hack to other ROM versions - of most importance, probably MM since DeathBasket has figured out how to disable most of the debug features of the debug ROM, and considering it has a more advanced graphics ucode than OoT, I think the Debug ROM should be the ROM of choice for future OoT hacks.

I have 4 Nintendo brand N64 controllers, all flawless with modified battery-free rumble packs. Yeah buddy!

That's pretty fucking cool. What's the procedure for testing these, if I may ask?