DeathBasket

This might be of interest to anybody who is still interested in importing custom music, etc. Features: Instrument set builder MIDI sequence converter Instrument set inserter Sequence inserter Sample inserter Instrument ripper More I don't do a lot of testing so beware of crashes and let me know if/when you find errors. Other information: https://sites.google...itor-oot-insted Download: https://sites.google.com/site/deathbasketslair/files/InstEd%20r6.zip?attredirects=0&d=1

For functions pointed to by the actor 'header' (initalisation, drawing, etc.) the arguments are always a0 = pointer to actor structure, a1 = 0x80212020, all other registers are free (except s registers, $sp and $ra obviously). For all other functions the arguments are defined by the actor unless they're not being called from the actor itself, in which case you'd have to work them out for yourself. The actor structure is not the same thing as the .data section of an actor. I'm not really sure how to find its size, could be related to something in the actor 'header'. Yes. I'm not sure, try looking for something that reads from there to see where it is. Most actors don't use it so I've never even looked for it.

That might be good to look at in free play, thanks, but if Link isn't spawned then they'd all be zeroes. At least one thing I was thinking of trying out would be in a situation where Link is not present and all actors on the map would be controlled by one main actor, so position/rotation would largely be constant. I could try using z-target arrow coordinates though, as they seem to be changing every frame, or maybe have a function that will put 'random' numbers at a certain address and then read them from there. I will see what I can find first and then what would be the best way to do it. Anyway, thanks for the suggestion.

I was wondering if anyone knows of any function that will return random numbers or an address that contains a randomly generated number. This would be really helpful for a lot of things.

Image quality isn't great, I know. The red thing in the N64 is an unofficial expansion pack. There is another controller in the box the grey controller is on but it's missing a joystick. The ISS '98 box is probably the last surviving N64 game box that I have, there are instructions in there too, that's the last game I remember buying. Also some games have random stickers on them (no idea why). Unfortunately there's several things missing that I couldn't find right now: Transfer packs (2, N64) Memory pack (N64) Starwing (SNES, boxed!) Super Mario All-Stars (SNES) Boxes for various games (I fear these may have been thrown away...) Additional SNES controllers (I think there were at least two, one was third-party) SNES console (I had two because one got lost... showed up a year or so later though) Pikachu N64 (this is probably wherever the rest of the N64 stuff got to, along with Pokémon gameboy games) Probably more stuff I don't even remember... Lists: I don't want to do this for Wii/Gamecube now as those games are scattered around everywhere...

I finished Peach's slide in on Mario 64, pretty good I think but I have seen better runs using a different method. I managed a similar time on the console too but didn't get a video because it would have taken me forever to do it again.

I have two grey controllers, the joystick barely works on one and the other has a broken Z button (bad for GoldenEye). I only have one controller that works well and isn't broken in some way (blue Pokémon controller) but that one is starting to wear out too.

A few things I'd like but probably won't buy any time soon: N64 controller (mine are all wearing out) Pokémon Snap (N64) Luigi's Mansion (Gamecube) Component cable for Wii Yoshi's Story (N64) Mario Party 3 (N64) Also waiting for a few things to be released before I even consider buying them: Halo 4 (Xbox 360) FIFA 2013 (Xbox 360) Aliens Colonial Marines (Xbox 360)

File Name: OoT Text Tool File Submitter: DeathBasket File Submitted: 27 Jul 2012 File Category: Community Downloads A tool for making text editing easier than it would be using a hex editor. Click here to download this file

I added another feature that will fix the text that was broken (again only for the debug ROM). I'll upload the file here now.

I'm using -Os at the moment. I really can't see any reason this should be happening .

100% sure it's missing a few new line commands with those. It's probably ignoring the lines in the text file because they are empty. I will see what I can do to fix it but for now a quick fix is to put a space on all the blank lines. Update: That problem should be fixed now. I also added an option so you don't need to type the message bank or pointer table address every time (debug ROM only). Link to the file is in the first post. Let me know if you come across any other errors.

Thanks, but none of those is the source of my problem... The problem is either than gcc is not writing some relocation data to the files or that nOVL is for some reason not reading some entries properly. I haven't properly looked at where the error is occurring yet, but it happens a lot when I use if/else, goto or return statements in my code and when I look at the disassembly in Nemu it seems to be mostly (or only?) jump and load/store instructions that aren't being relocated properly. The rest seem to work fine. I don't remember what the solution was when I ran into this before when using assembly, but I doubt it would be something I have much control over when using C.

I'm having this error when writing actors in C; it has happened a few times before when I've edited actors using assembly code but the errors appeared much less often. There doesn't seem to be any problems with my code but when I have compiled it and converted to an overlay there are usually a few bits of relocation data missing though most of them are there. It's not that much of a hassle to fix this manually, but when it needs to be done every time I want to change some of the code in my actor it does become a hassle. I just wanted to know if anybody else has come across the same problem or knows why this happens or how to fix it. I'm not a C expert (only just really started learning a bit) so I acknowledge that I may be doing something wrong somewhere. Thanks.

No. Registers never clear themselves. What I am saying is that you don't need to initialise a register before putting a number in it. A register can have any value in it but if you use an instruction like lui, li, la, etc. it's the same as saying register = constant, so there is no need to clear the register first. ex. lw a0, 0 ($sp) //a0 here could be anything (a0 = *sp) li a0, 255 //now a0 = 255, since this is the same as addiu a0, $zero, 255 (a0 = 0 + 255) lui a0, 0x8016 //now a0 = 0x80160000 I guess what I'm trying to say is that these instructions will ignore what was already in the register and just set it equal to whatever value you gave them, which is what you seem to be confused about. There is never any need to set it to zero before putting another number in it. LUI K1, 0x0603 # K1 = 0x06030003 (Before we got to this area of code, K1 was equal to 0x03) ADDIU K1, K1, 0xFE7D # 0x06030003 + 0xFFFFFE7D = 0x0602FE80 (Bow FPS) Now you should see that this piece of code would give k1 = 0x0602FE7D, not k1 = 0x0602FE80, since the first line set k1 to be 0x06030000. Also, pseudo-instructions are useful because they make writing the code easier and quicker so there's not really any point in avoiding them. move is a pseudo-instruction too, by the way (r1 = r2 | 0 / or r1,r2,$zero).

Whether or not the instruction in the delay slot executes depends on the branch instruction. Branch instructions ending in l (ex. beql) will only execute what is in the delay slot if the condition is met, branch instructions not ending in l will always execute what is in the delay slot.You can use the jr instruction like that, yes. You could always do something like: #define bow_dl 0x0602FE80 ... li t0, bow_dl Then if somebody had the code, they'd only need to change that line to adapt it for their own purposes. A few tips: Since you added your code at the end of a function that doesn't seem to be returning anything, you should be able to use all v, a, t and f registers without messing anything up. t registers can always be used freely if you are putting code at the start or end of a function. You also don't need to set registers to zero before using them unless they needed to be zero in the first place. ex. MOVE GP, R0 # Clear GP for future use LUI GP, 0x8012 # GP = 0x80120000You only needed the second line since gp would be set to 0x80120000 regardless of what it already was.

Yes, that is Link's actor. The actor's structure in RAM seems to always be at 0x802245B0 (yet to see it at any other address) but I would not call that a constant. I'm not sure where the functions etc. get copied to but I think it's somewhere > 0x8038000 if that's any help.

Figured it was about time I post a topic for this... For anybody who followed the past incarnations of this project, it's going to be a lot different this time around. So here's a little about the story... The game is set a long time after the events of Ocarina of Time. Link lives in a town based near Hyrule Castle, the main settlement of humans, and is learning about the legends of the Hero of Time. One day Link leaves the town to find further information elsewhere, but he will soon discover that the world is not the safe place it seems to be... Current progress is probably close to zero percent but a lot of the planning is already there so this time I should not run into loads of problems in development. This will probably take a long time as I plan to use as much custom content as I can, so don't be expecting anything finished to play any time soon. Here's a few screenshots to keep you occupied for the moment: A few other music previews, etc. http://www.youtube.c...eature=view_all Note: only the 4th video onwards is relevant to this version of the hack. I'm sorry.

Nice work. Just so you know, the game doesn't seem to have any trouble loading jpegs that are 50kb+ so it could be possible to improve the image quality a little if you want to go to the trouble of moving the files around in the ROM. You could change the camera angle so that the picture lines up with the collision properly. This won't affect the way the background is displayed. To do this you need to find the collision header and follow the pointer to the camera data. At this address you'll see some data in a format something like xxxx yyyy zzzzzzzz, I don't know what x or y do but z is a pointer to the camera's position data, which looks like: xxxx yyyy zzzz aaaa bbbb cccc dddd FFFFFFFF x = x position of camera y = y position z = z position a = x rotation b = y rotation c = z rotation d = zoom (?) It would probably take a lot of fiddling around to get the background to line up properly though.

This page should tell you what you need: http://wiki.spinout182.com/w/Maps_and_Scenes

This thing. Not great, but it works well enough for Zelda OoT at least.

Young Link already uses the bow correctly, it's exactly the same item (in functionality) as the slingshot. The reason they only shoot seeds as a child and arrows as an adult is because Link's actor decides what can be fired based on age only. The video posted above changes what variable the actor loads for the arrows/seeds, I explained it originally in the post here. Being able to use both bow and slingshot would require a bit of assembly hacking both to get the models to load properly and for Link's actor to be able to distinguish between the two, so it's actually quite complex... that goes for both adult and child. In short, using only one of the items (ex. both use only bow or slingshot) is relatively easy but using both items is hard. If anybody knows what causes the crash when child Link tries to use the hookshot (I've never looked) then I should be able to find a way to make it usable.

Extracts the text so you can edit it easily in notepad then inserts it back into the game for you later. Aims to make the text more easily readable and editable so you don't need to be fiddling around with a hex editor. You can also change the size of any message because the pointer table is recalculated when the text is inserted. There is only one problem I have come across so far but that is covered in the readme. Downloads: http://www.the-gcn.com/topic/1539-community-downloads-oot-text-tool/?do=findComment&comment=23627 https://sites.google...sketslair/files Let me know if you have any suggestions for features or find any bugs, etc.

Downloaded Kameo since it was reduced on the Xbox marketplace, seems to be a pretty good buy for £3.99.