PDA

View Full Version : Looking for SSB GS Code


DaFees
17th November 2008, 08:11 AM
Hello All,

I'm new to these forums (as if it wasn't obvious, heh) but not new to Project64. I love Project64 and occasionally find the time to sit down with my cousin and do some Mario Kart or Mario Party.

Anyways my question is that I've been looking for a very specific cheat for Super Smash Bros for a very long time. A long time ago I use to have a working version 3.3 gameshark and a copy of SSB for my n64. I created this cheat for SSB that would let me modify the damage modifier beyond the range of 50-200. I loved this cheat because I could set the modifier lower than 50 and make it that you will need to get your opponent to 999% damage in order to knock them off. However my gameshark no longer works and I no longer have this code and I've searched hi and low on the internet and couldn't find it.

Therefore I figured someone on here could help me find this code again?

If you have any questions just ask. I can't wait for v1.7 of PJ64, :)

HatCat
17th November 2008, 03:01 PM
You can try Renegade. Also Project64 in development now supports memory debugging and cheat research, creation. That's how I created cheats for health modifiers...seems two codes were needed to write to the damage display and the actual quantity--both of which mode- and level-dependent. Not sure if the same applies to the damage sensitivity modifier codes?

DaFees
17th November 2008, 05:10 PM
Ok, well I knew the new Project64 in Development had a cheat creation thingy, but I don't have any of the betas of the new version. Secondly, what's renegade?

HatCat
17th November 2008, 05:27 PM
http://doc.kodewerx.net/tools.html
See Renegade and Parasytic Cheat Search.

Mdkcheatz
17th November 2008, 06:04 PM
interesting, must try at some point

DaFees
17th November 2008, 07:00 PM
Ok, these programs are like greek to me, but after fiddling with the memory editor. I came up with this memory address: 001348F0 000000XX Where XX = the value you want the damage modifier to be equal to. However I can't figure out how to convert this memory address value into a gameshark cheat value. Any suggestions?

Note I found this value using Nemu and Renegade

HatCat
17th November 2008, 07:16 PM
Humm if you have the address that should be good enough?

The second one doesn't really need to be eight digits; for GameShark cheat codes the format should be the same. Something like 801348F0 0000 will do...but obviously a value of 0x0000 = 0 probably isn't what you want to be limited to. Try using the PCS plugin for Project64 to warp to that address (0x1348F0) while you're in the area the cheat was found, and it should tell you the value. Should give you an idea on how value formatting works...otherwise it's just guesswork.

DaFees
17th November 2008, 08:12 PM
Thank you for your help, I found the code I was looking for. I didn't need the PCS plugin (not that it worked anyways, :-D), but in renegade when I did a code search I was able to export the reults out as N64 codes and all I had to do was find the code that look as close the memory address and there I go.

Thanks again.

Mdkcheatz
17th November 2008, 08:20 PM
would you like to copy the code onto here, i will be happy to import it into the cht for everyone to use...

HatCat
17th November 2008, 08:21 PM
Great!

Aw I had this huge collage of N64 tools on my flash drive bye bye to that baby...I'm glad to hear Renegade worked for you.

DaFees
17th November 2008, 09:13 PM
801348F3 00XX

There is the code, just replace the XX with what ever value you want it to be.

Note if you set it to zero, then you will never be able get knocked off as you will fall instantly. So the only way to get knocked would be is if you walked off the edge.

Note if you set it really high like FF then a single smash hit would more than likely instantly knock you off.

One last note when you check the damage value for the first time after turning this cheat on it may be off by one, but don't worry go up one level in the menu and then go back and the damage value should look correct then.

Note I've tried change this value while in mid-game so I don't know what would happen if you did.

Lastly, I recommend setting the value between 1 and F with the stocks set to 99 for what will seem like a really really long match, ;)

Mdkcheatz
17th November 2008, 09:27 PM
thankx dafees will work this out!!

DaFees
17th November 2008, 10:08 PM
Update, I did some play testing with this cheat and unfortunately it throws an error in mid battle (but it worked as expected before it threw the error):

"Unhandled R4300i OpCode at: 801348F0

dsra32 at, t1, 0x3

Stopping Emulation!"

I'm confused because back when I had my working GS I don't recall ever getting this error er well an error in general.

HatCat
17th November 2008, 10:20 PM
You might find those messages to be random, but special GameShark cheats can be the reason for their random execution.

Noteably the address where the game crashed is close to the one your cheat code is writing to...maybe you can manage to verify near a crash point? Not sure why this should be the issue if the cheat code is a single command in a damage modifier....

DaFees
17th November 2008, 10:35 PM
I think the error may have been random. I checked my task manager and I had more than one instance of PJ64 running even though I could only see one instance visibly being open.

Also, I just tried another round with the cheat and all seemed fine. If some drastic happens I'll let you know, otherwise I think this code is solid.

EDIT - just did some more testing. I got this error again, my first battle was one on one and I got no error, this time is was a 4 person ffa and I got the error almost instantly after the fight started.

Also what do you mean verify near a crash point, I'm unsure of what you mean here?

HatCat
18th November 2008, 03:16 AM
I would want to know for sure if the cheat is allowing this to happen; it's just a single code action. But from the sound of it it is...so I guess it's known instability. Have you tried testing it with other emulators like 1964 or Mupen64?

DaFees
18th November 2008, 04:08 AM
Ok, I just did a quick 4 person ffa in the 1964 emulator and everything seemed fine. The cheat worked as expected. I couldn't test Mupen64 as I quite unfamiliar with that particular emulator and I have no clue as to how to enable cheats with that emulator.

At this point however, I'm starting to think maybe it's an issue within PJ64. I'll go do some more play testing with 1964 just to verify.

EDIT - I did a few more battles and surprise surprise nothing went wrong. Everything worked as I expected. Now if only 1964 worked as well as PJ64 then I'd have a temporary fix until we can figure out why PJ64 doesn't like the cheat.

HatCat
18th November 2008, 04:21 AM
schibo spent loads of time on the recompiler as well; it's the only one to support Vista so well internally.

What if in Project64 you right-click Edit Game Settings, set it to use the interpreter instead? This will be slower, but it could narrow it down. It's not unnatural for some cheats to raise problems in emulators in general.

DaFees
18th November 2008, 04:43 AM
Ok, I set the game settings to interpreter and while it did run MUCH slower it didn't give me any errors with the code.

HatCat
18th November 2008, 04:56 AM
Very useful to know for me. Now there are four advanced game memory processing settings that are rendered irrelevant as to what they're set to when you use the Interpreter instead of the Recompiler:

Advanced Block Linking
Register Caching
code self-modification method "Self. mod Core Method"
compiler buffer expansion "Large Compile Buffer"
It would be helpful to know in as far as that what really helps Project64 be more stable with cheats. It's come to my generalization that 1964 ironically has the most stable recompiler, and Mupen64's recompiler is currently the only one to really get e.g. Top Gear Overdrive going. (Now Project64 does as well.) And Project64, well recent development shows there's a hell of a lot of knowledgability put into this thing, but there's some side effects due to accuracy I take. Right now to evaluate that try meddling with those settings?

(I'll be back tomorrow.)

DaFees
18th November 2008, 06:33 AM
I believe I isolated the problem, by default the Register Caching was enabled, but after I disabled said feature I was able to play numerous battles using the code and I didn't get any error(s).

So now that the problem has been narrowed, all I can ask is why? Well, first I guess I should ask, what does Register Caching do and is there a reason it's enabled by default? May be knowing that will help me understand why having this enabled caused errors.

EDIT - I have an update to this matter. First let me say I can't say that my fix works in the 1.7 betas. However I can say that with this cheat enabled, if I let the opening scenes come up rather then clicking to the main menu as quickly as I can, then the game will lock up. Also sometimes during mid-battle the game will lock up with this code enabled, but still I get no errors.

This edit comes from me testing this out on a different machine one that isn't vista (unlike my home machine)

HatCat
18th November 2008, 11:22 PM
Better now than never...but why can I not seem to get your code to work? I've tried VS Mode and 1P Mode with a few characters and on Sector Z, Peach's Castle. Unless there's something consistent you do. My exact write-down here is 801348F3 0000.

Caching of registers is perhaps the recompiler's most significant memory optimization component. If it had been one of those three other settings that would be surprising and useful to evaluate since they are disregarded in the interpreter core for lesser technical reasons; register caching is a big reason why the recompiler is faster than the interpreter. In many cases fixes to games need the interpreter core, but disabling the big registers component seems to improve recompiler stability. For more information please see the User Manual (Help) for details on processing settings.

I also have Vista. The beta 1.7 stability is not that important because zilmar has excercised some compatibility fixes in the recompiler--some of which were very risky in result. In the recent betas this has been reduced very much, but some games are still much less stable than they are on 1.6 especially on Vista. For now zilmar's concern is the transition to working on the site and the emulator interface to get back from his other life work.

DaFees
19th November 2008, 12:59 AM
Ok, I guess perhaps I should explain how I do things. When you first enable the cheat, if you go straight into a match the cheat won't work as it will read the damage percentage as being the default 100%. If you go the vs mode options you'll see the damage percentage at the default 100% but if you exit that screen then go back, then the damage percentage should read whatever you set it to in the code. After you see that, then begin your VS. match. Also I should add that this currently only works in VS. mode because you can't (visually at least) change the damage percentage in the single player modes.

Mdkcheatz
19th November 2008, 01:17 AM
Sorry ive been meaning to test this but life has been busy, im glad you were able to explain how it worked before i got confused and added some sort of comment on how it doesn't work hehe

HatCat
19th November 2008, 03:06 AM
Oh I see you searched in memory while modifying the damage variable directly...that's why it applies to all courses. For some reason I thought you changed the Damage setting, started a fight, and then searched the memory, then went back and changed the setting...I guess I wasn't thinking along the lines of the variable being updated without exiting the menu.

Yeah that was pretty fun throwing Kirby with R repeatedly trying to get [him?] off of the walkway, that obnoxious ARWING blasting him over and over with no effect in the meantime, the invincibility....

I see they don't stay in the air for a long time, but what this doesn't control is weight during being in the air as opposed to weight resistance from being thrown. Metal mario is one heavy man.