Jason777

I respect you as a person, fellow modder, and as one of the administrator's of this site, Zeth, but I think there was no reason to give such a harsh comment on C-Force's project. Constructive criticism would have been the way to go. Anyways, that's just my opinion; I'm just trying to stop potential drama from arising.

Here's one thread that displays alot of hacks for SS: http://forum.unseen64.net/viewtopic.php?f=2&t=3051

I had the swine flu before they came out with a cure; that shit was hell to go through (but I don't think it was considered all that fatal). It took a lot of rest for me but I still beat it without medicine! You can do it ShadowFire!

Looking good so far C-force, my views and opinions upon retextures are starting to shift somewhat..

It really doesn't matter as long you're able to connect to the server. Speaking of servers... What servers would members like to play on? There are a few to choose from, such as scthack and sylverant (there are others). Also, in my case, I would be playing on my console I've gotta find a Dreamcast Keyboard!

For those of you who have a Dreamcast and a copy (or CD-R if your system can run those discs) of Phantasy Star Online v2 PAL, who wants to start a little team? I used to play alot back in 2001 when I still had dial-up and the DC servers were still on. Now, I don't have as much fun playing myself offline... However, apparantly there's a way to setup a DC server through your PC!: http://www.dreamcast-scene.com/guides/pc-dc-server-guide-win7/ So if I can get this running, who would be up for a couple of missions?

Lol'd at the NSFW warning.

Nice job, DeathBasket. Customization of music has just been made a little easier thanks to your tool(s).

Thanks for the help, DeathBasket, the first question was of the most importance to me and am glad to have that cleared up. Kinda Off-topic Subject I went and looked at the disassembly of 5 different actors whose damage charts have already been mapped out and I seem to have found a way to locate damage charts in the actor file and in the RAM (if it has one)... In the RAM, an actor's damage chart can be located 0x98 bytes away from the start of "actor panel" or RAM actor structure. In the ROM or actor file, it requires a bit more work to find... Take the disassembled actor file and do a search for the integer of 152 (0x98 in hex), you should get very few results. Look for a result which stores a word of a registers contents at an offset which is 152 bytes away from the base register's value. For example, in dark link's file (En_Torch2.S) we find this instruction: sw t1, 152 (s0) Check the instructions before to see if the base register (in this case, s0) could hold the offset to the actor panel. If you're not sure, then it may still do you some good to continue to the next step. If so, check to see what the contents of the register that was stored (in this case, t1) by looking at the instructions before. For example, in dark link's file (En_Torch2.S) we find these instructions: lui t1, %hi (data_80B1FA08) .. addiu t1, t1, %lo (data_80B1FA08) Take the value (it should be a virtual offset) and do a search for it (in this case, we would be searching for "data_80B1FA08"). Or, you could just go straight the virtual offset in .data section. And there you have the damage chart in the disassembled actor (in this case, 0x80B1FA08). The next 0x20 bytes are all part of the damage table. To find the damage table in the assembled actor file (.zactor or .ovl)... Grab the actor's virtual entry point from this list (dark link's is 0x80B1D980): click me Take the virtual address of the damage table and subtract the actor's virtual entry point from it. The result is the offset of the damage chart in the assembled actor file. I'm pretty sure this has been found before... Anyways, this is in response to this thread: click me

I have some questions about disassembled actors which would help me make a little more sense of all the code and data if answered. I also plan to come up with a list of mappings for each actor panel in the unknown areas and beyond 0x128 bytes from the start of the panel. I was wondering if there were set of default values each register contained at the start of the actor? At the very start I would assume that a0 holds the RAM address to the "actor panel" and a1 holds the RAM address to the object due to the arguments which need to be provided to an actor's "initialization" function? I was reading some notes on the disassembly of the "en_arrow" actor and it gave me the values that each register starts off with... I doubt that those notes apply to every single actor. Here are the notes I am referring to: click me How would I know how large an actor panel would be? At first I thought that each actor panel was defined by the .data section of each actor so that would mean that the actor panel would be as large as the .data section, but I realized that the start of the .data section is not always the start of the initial actor panel. Plus, you could find the virtual offsets of an actor panel through the actor table. Lastly, is .rodata also a part of a RAM actor? If so, where? Also, is it possible to change one of values in the .rodata via the RAM? I read in one thread on Z64, that trying to change any of the .rodata in link's RAM actor resulted in the changes not being made... Here is a link to the thread: click me I forgot to include this one... I want to know if the .bss section is also locateable through actor panel? Thanks to anyone who can help.

Damn, you've got most of the classics in there... Sonic R (I have that along with Sonic CD and Sonic and Knuckles 3 for the PC), Nights, House of the Dead, Virtua Cop, Street Fighter, Megaman X, and... Virtual ON?! I hate you

You could try building your own random numbers function. I know of one method in C++ that uses the "ctime" header file as a seed for an algorithm which seemingly generates random numbers. The time is always changing so there are different results each time. You could also give certain ranges as to how little or how big of a number is generated. In OoT's case, you could take the "Hyrule Time" value as the seed and then optomize the common random number generator to be used with OoT's engine. Here's the info I first watched a couple of years ago on random numbers and the header files that are used (in C++): http://www.youtube.com/watch?nomobile=1&v=PZZUJ1fxG04

What's not to understand about the usage of objn64tool? Of course, it won't generate a hierarchy and animations, but it will generate collision for a specified obj file. I'm pretty sure I'm not entirely understanding the problem because it seems like there are already plenty of solutions for it besides issues concerning building a hierarchy and modifying vertex colors. I do agree, however, that a GUI or comfortable user interface be made for these sorts of programs and that scaling is quite an issue for those who don't understand how actors work. http://wiki.spinout182.com/w/Libobj It might also be beneficial to look at marshallh's OBJN64 if you're interested in display lists in C: http://z64.spinout182.com/index.php/topic,174.0.html

First off, let me say "nice find." I remember reading something about this in some other N64 emulation forums and am looking for the posts as I am writing this. From what I remember, 0xA6000000 through 0xA63FFFFFF is memory that the 64DD (disk and registers?) uses and shares along with the PI bus. In other words, you have found a call to 64DD data within the ROM! Alright, a little google search and this what I have: http://www.emutalk.n...hp/t-34932.html http://www.assembler...hp/t-11067.html http://www.google.co...p7uDTEDps&mvs=0 I used to have a picture which gave the addresses to the special registers of the N64DD (the ones beginning with the name "Leo") but have since lost it, sorry. Good luck with this!

I'll be boarding my last plane today and will arrive at my final destination: Paraguay. I'll be back in 2 weeks. I hope I don't miss too many events.

Awesome news, DL! I wish you guys a long and happy marriage

I'm pretty sure you were knowledgeable to do this, but by some weird event you may have missed it: ^^ Taken from: http://64.vg/dr/node/5 I seriously doubt that that was the problem, though, since I'm pretty sure you know what you're doing. EDIT: I haven't read the source code of this thoroughly, but it may aid you in reconstructing the relocation data: http://code.google.com/p/vg64tools/source/browse/n64/z_snippets/z_ovl_adapt.c

UPDATE: Alright, I've hopefully fixed the hack and will assemble it into a GS code later (did you know that the iPhone has GCC tools on it?). Of course, there's still a few areas where I could shorten the code, but I really don't feel like it now...: .ORG 0x801064B0 J 0x80600000 .ORG 0x80600000 LUI AT, 0x8016 # AT = 0x80160000 LW K1, 0xE664(AT) # Load word @ 0x8015E664 into K1 BNE K1, R0, CLeft # If word @ 0x8015E664 = 0x0000001, Jump to "CLeft" routine LUI A3, 0x8060 # Delay Slot; A3 will be used for Jump Returns B Exit # In case you are Adult Link, exit routine NOP CLeft: # C-Left; 0x80600018 LUI GP, 0x0002 # GP = C-Left Value LB K1, 0xE6C9(AT) # K1 = Item equipped to C-Left B Check # Unconditional branch to "Check" routine ADDIU A3, 0x0025 # Delay Slot; A3 = 0x80600028 CBottom: # C-Bottom; 0x80600028 LUI GP, 0x0004 # GP = C-Bottom Value LUI AT, 0x8016 # AT = 0x80160000 LB K1, 0xE6CA(AT) # K1 = Item equipped to C-Bottom B Check # Unconditional Branch to Check Routine ADDIU A3, 0x0014 # Delay Slot; A3 = 0x8060003C CRight: # C-Right; 0x8060003C LUI GP, 0x0001 # GP = C-Right Value LUI AT, 0x8016 # AT = 0x80160000 LB K1, 0xE6CB(AT) # K1 = Item equipped to C-Right B Check # Unconditional branch to "Check" routine ADDIU A3, 0x0014 # Delay Slot; A3 = 0x80600050 Exit: # Exit; 0x80600050 MOVE GP, R0 # Clear GP MOVE AT, R0 # Clear AT ADDIU K1, R0, 0x0AAA # Restore K1 back to 0x00000AAA ADDIU A3, R0, 0x0003 # Restore A3 back to 0x00000003 JR RA ADDIU T2, R0, 0x2000 # Delay Slot; Restore T2 back to 0x00002000 Check: ADDIU AT, K1, 0xFFFD # 0xFFFFFFFD = -0x03 () BEQ AT, R0, Arrow NOP ADDIU AT, K1, 0xFFFC # 0xFFFFFFFC = -0x04 (Fire Arrows) BEQ AT, R0, Fire NOP ADDIU AT, K1, 0xFFFA # 0xFFFFFFFA = -0x06 (Slingshot) BEQ AT, R0, Sling NOP ADDIU AT, K1, 0xFFF4 # 0xFFFFFFF4 = -0x0C (Ice Arrows) BEQ AT, R0, Ice NOP ADDIU AT, K1, 0xFFEE # 0xFFFFFFEE = -0x12 (Light Arrows) BEQ AT, R0, Light NOP JR A3 # Jump to next C-button check or Exit routine (address in A3) NOP Arrow: LUI AT, 0x8016 # AT = 0x80160000 LW AT, 0x6AF0(AT) # AT = Buttons currently pressed AND AT, AT, GP # AT &= GP BNE AT, R0, BowSetup # If button value stored in GP is pressed, branch to FixDisplay ADDIU AT, R0, 0x0002 # Delay Slot; AT = Regular Arrow Spawn (0x0002) JR A3 # Else, jump to next C-button check or Exit routine (address in A3) NOP Fire: LUI AT, 0x8016 # AT = 0x80160000 LW AT, 0x6AF0(AT) # AT = Buttons currently pressed AND AT, AT, GP # AT &= GP BNE AT, R0, BowSetup # If button value stored in GP is pressed, branch to FixDisplay ADDIU AT, R0, 0x0003 # Delay Slot; AT = Fire Arrow Spawn (0x0003) JR A3 # Else, jump to next C-button check or Exit routine (address in A3) NOP Ice: LUI AT, 0x8016 # AT = 0x80160000 LW AT, 0x6AF0(AT) # AT = Buttons currently pressed AND AT, AT, GP # AT &= GP BNE AT, R0, BowSetup # If button value stored in GP is pressed, branch to FixDisplay ADDIU AT, R0, 0x0004 # Delay Slot; AT = Ice Arrow Spawn (0x0004) JR A3 # Else, jump to next C-button check or Exit routine (address in A3) NOP Light: LUI AT, 0x8016 # AT = 0x80160000 LW AT, 0x6AF0(AT) # AT = Buttons currently pressed AND AT, AT, GP # AT &= GP BNE AT, R0, BowSetup # If button value stored in GP is pressed, branch to FixDisplay ADDIU AT, R0, 0x0005 # Delay Slot; AT = Light Arrow Spawn (0x0005) JR A3 # Else, jump to next C-button check or Exit routine (address in A3) NOP Sling: LUI K1, 0x0602 # K1 = 0x06020000 ADDIU K1, K1, 0x8048 # 0x06020000 + 0xFFFF8048 = 0x06018048 (Slingshot FPS) LUI T2, T2, 0x0602 # T2 = 0x06020000 ORI T2, T2, 0x21A8 # T2 = 0x060221A8 (Slingshot String) LUI AT, 0x8016 # AT = 0x80160000 LW AT, 0x6AF0(AT) # AT = Buttons currently pressed AND AT, AT, GP # AT &= GP BNE AT, R0, FixDisplay # If button value stored in GP is pressed, branch to FixDisplay ADDIU AT, R0, 0x0009 # Delay Slot; AT = Deku Seed Spawn (0x0009) JR A3 # Else, jump to next C-button check or Exit routine (address in A3) NOP BowSetup: LUI K1, 0x0603 # K1 = 0x06030000 ADDIU K1, K1, 0xFE80 # 0x06030000 + 0xFFFFFE80 = 0x0602FE80 (Bow FPS) LUI T2, T2, 0x0603 # T2 = 0x06030000 B FixDisplay # Unconditional branch to "FixDisplay" routine ORI T2, T2, 0x0490 # Delay Slot; T2 = 0x06030490 (Bow String) FixDisplay: LUI GP, 0x8012 # GP = 0x80120000 SW K1, 0x5F3C(GP) # Store FPS display list pointer in K1 @ 0x80125F3C SW T2, 0x6144(GP) # Store String display list pointer in T2 @ 0x80126144 LUI GP, 0x8017 # GP = 0x80170000 JR A3 # Jump to next C-button check or Exit routine (address in A3) SH AT, 0x8232(GP) # Delay Slot; Store Projectile Spawn Actor variable in AT @ 0x80168232 EDIT: Gah, with the syntax that mips-as uses, it'll take a while before I turn this into a GS code -.-

Awesome! I can reduce the number of lines of code by a shitload now Thanks again.

Thanks for clearing that up, it was bothering me whenever I came to the situation where I could reduce the amount of code by putting an instruction in the delay slot and not knowing if that code would execute whether or not the condition was met. I was thinking about that, and decided to try to not use any psuedo-opcodes like "la" and "li". However, I did use the "b" opcode because I was lazy They are psuedo-opcodes, yes? So you're saying that registers will clear their value when a branch occurs? The reason I thought I had to clear the GP value before moving on is because I assumed that it would preserve its previous value across a branch. This is what I mean: # I am assuming that the button value GP has is C-left (0x0002) Bow: 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) LUI T2, T2, 0x0603 # T2 = 0x06030000 ORI T2, T2, 0x0490 # T2 = 0x06030490 (Bow String) LUI AT, 0x8016 LW AT, 0x6AF0(AT) # AT = Button currently pressed AND AT, AT, GP BNE AT, R0, FixDisplay # If button value stored in GP is pressed, branch to FixDisplay (now AT and GP equal 0x00020000) ADDIU AT, R0, 0x0002 # Delay Slot; AT = Regular Arrow Spawn (0x0002) B ClearData # Else, branch to "ClearData" routine (^^ AT = 0x0002 and GP = 0x00020000) NOP ... # Assuming the button was pressed... # GP = 0x00020000 # AT = 0x00000002 FixDisplay: MOVE GP, R0 # Clear GP for future use (or else the next line may change.... wait, shit -.-) # ^^ I just realized that GP had an the 0x0002 in the upper immediate; this means the next line would overwrite that value LUI GP, 0x8012 # GP = 0x80120000 SW K1, 0x5F3C(GP) # Store FPS display list pointer in K1 @ 0x80125F3C SW T2, 0x6144(GP) # Store String display list pointer in T2 @ 0x80126144 LUI GP, 0x8017 # GP = 0x80170000 B ClearData # Unconditional branch to "ClearData" routine SH AT, 0x8232(GP) # Delay Slot; Store Projectile Spawn Actor variable in AT @ 0x80168232 (AT = 0x0002) ... # Assuming the button wasn't pressed... # GP = 0x00020000 # AT = 0x00000002 ClearData: MOVE AT, R0 # Clear AT for future use MOVE K1, R0 # Clear K1 for future use MOVE T2, R0 # Clear T2 for future use JR A3 # Jump to next C-button check or Exit routine (address in A3) MOVE GP, R0 # Delay Slot; Clear GP for future use ^^ If what all your saying is true (and I hope it is), I can cut the length of the code quite significantly o: Thanks for the help and tips. Hmmm... I'll be studying over this.

I haven't been able to test this out yet, but at least it's something; I wrote a little fix for being able to use the Bow and Slingshot at the same time as Young Link on this thread: http://www.the-gcn.com/topic/1262-jason777s-hack-ideas/

Alright, I have something else now... I wrote this while bored on an airplane and I still don't have any emulator to test it out on (N64iPhone can't handle this stuff), but it should work in theory. If not, well I'll give you all the information one would need (someone like DeathBasket, spinout, or sakura) to fix it! My god, assembly is a bitch compared to hacking with C. It also doesn't help that I tried to use as little registers as possible. I don't have too much experience with assembly (this hack was for practice), so I can't really spot any errors right now (damn delay slot -.-) but I'm sure someone who is more knowledgable can. Alright, I present to you a semi-complete fix for being able to use both the Bow (including the magical arrows) and the Slingshot as Young Link!: Notes: More notes concerning how to change the arrow spawn variable before the ActorSpawn function is called...: I can see some problems arrising from my hook, seeing as how the arrow actor variable at 0x80168232 is only present as you're about to shoot the arrow and before the actor spawn function is called. However, the hook I have right now executes my hack every frame so it may not be a problem... I currently don't have an emulator to test this hack out on right now nor do I have a way to assemble this into a GS code. Also, as you can see, in order to adapt this hack to work with your own display list ports, you would have to change a few LUI/ADDIU or LUI/ORI pairs in the hack since I use these offsets as my display lists: # 0x0602FE80 = Bow Display List # 0x06030490 = Bow String Display List # 0x06018048 = Slingshot Display List # 0x060221A8 = Slingshot String Display List ^^ Those instructions I am referring to, are in the last few labels: Bow, Fire, Ice, Light, Sling. Things that I haven't put into the hack yet, that should be noted: Firing an arrow decreases the deku seed amount. Firing a magical arrow doesn't decrease the magic amount. ENJOY Also, can anybody give me some pointers on writing cleaner assembly? I don't quite get how the delay slot is used (if the condition isn't met, doesn't skip the instructions in the delay slot?) and if I can use the JR opcode the way I am using it in the hack (I use "JR A3" instead of the usual "JR RA").

I'm a little too busy myself (at the moment I'm scurrying to the proper gate where my next flight will arrive at shortly) to look this up so I'm asking someone for a quick answer. Does anyone know where ovl_player_actor is loaded into the RAM? Also, not really a major deal but I still wonder, is that actor the "Link" actor? I've really never known. If it is, well that answers my first question. I'm writing and finishing a little hack in the "Notes" app on my iPod to pass the time on the airplane. Nearly done, too!

Nice to see a topic about this finally; I had been following the progress made on YouTube videos for quite awhile now Good luck!

It would do you good to try to export levels from the Minecraft app on the iPhone since the polygon count is about million times more limited.