• Welcome to Smashboards, the world's largest Super Smash Brothers community! Over 250,000 Smash Bros. fans from around the world have come to discuss these great games in over 19 million posts!

    You are currently viewing our boards as a visitor. Click here to sign up right now and start on your path in the Smash community!

Completed P1 is Immune to Throws

Punkline

Dr. Frankenstack
Joined
May 15, 2015
Messages
423
J jra64 requested a code that makes P1 immune to throws.

Achilles1515 Achilles1515 had some advice that made this particularly simple to figure out; so I just put something together that intercepts the P1 check for throw collisions. Lemme know if anything doesn't seem to work right~

Edit: made small adjustment to safely load internal player data when other entities are loaded mid-game.

$P1 is Immune to Throws [Punkline]
C2078a6C 00000004
809D002C 8884000C
2C040000 389D0000
40820008 7C641B78
60000000 00000000

Injection Mod for MCM:
Code:
    -==-


P1 Immune to Throws
Throw hitboxes have no effect on Player 1
[Punkline]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x80078a6C --- 389D0000 -> Branch

809D002C 8884000C
2C040000 389D0000
40820008 7C641B78
00000000

ASM:

Code:
#@80078a6C: addi r4, r29, 0 (passing stored player entity for a function that checks it against r3)
#r25 = stored player that owns "throw" hitbox
#r29 = iterative check against all player entities; will be == player 1 at some point in the loop
#r4 is about to be clobbered, LR and CR0 are safe.
#if r4 == r3, then this iteration of the check is skipped. This is used to nullify P1 (lbz r4, 0xC(r4); cmpwi r4, 0)
lwz r4, 0x2C(r29)
lbz r4, 0xC(r4)
cmpwi r4, 0        #check if "grabbed" player is P1
addi r4, r29, 0        #original instruction
bne return
mr r4, r3
return:
.long 0x00000000
 
Last edited:

Punkline

Dr. Frankenstack
Joined
May 15, 2015
Messages
423
your c2 goes to 0x000000, according to your notes, it should be C2078a6C
Fixed it, thanks!
Made a quick revision and forgot to set the address, lol.

Edit: Also, I think we simultaneously fulfilled this request. I didn't even know there was a flag for Giga Bowser's inability to be grabbed. Nice!

Here's Flieskiller's code:
Player 1 can't be grabbed (1.02) [flieskiller]
C206938C 00000005
8B9F006C 2C1C0000
40820014 3BA00001
881E222A 53A03E30
981E222A 8001004C
60000000 00000000

This code uses the same flag as Giga Bowser uses that prevents him from getting grabbed.
 
Last edited:

Achilles1515

Smash Master
Joined
Jun 18, 2007
Messages
3,211
Location
Cincinnati / Columbus OH
Punkline Punkline I saw the ASM notes, before you edited them, and was going to mention that you (and we, as a community) should be loading character data offset attributes from the Entity Data offset rather than the Entity Struct start (again, I just term these in my mind as internal/external data offsets, respectively). But we should be doing it like the game does, by always using the internal offset when pulling values. 99% of the time it won't make a difference because I've never seen a VS. Mode match where the entity data does not immediately follow the entity struct (so the +0x60), but this is not the case when new characters are created/spawned mid-match like in some single player mode stuff. It's one of those things that is good practice to implement and will always keep your code safe. I've started to always do it as well and stay consistent with the vanilla game code. And in your edit it looks like you changed it accordingly. Nice code.

flieskiller flieskiller
 
Last edited:

Punkline

Dr. Frankenstack
Joined
May 15, 2015
Messages
423
Punkline Punkline I saw the ASM notes, before you edited them, and was going to mention that you (and we, as a community) should be loading character data offset attributes from the Entity Data offset rather than the Entity Struct start (again, I just term these in my mind as internal/external data offsets, respectively). But we should be doing it like the game does, by always using the internal offset when pulling values. 99% of the time it won't make a difference because I've never seen a VS. Mode match where the entity data does not immediately follow the entity struct (so the +0x60), but this is not the case when new characters are created/spawned mid-match like in some single player mode stuff. It's one of those things that is good practice to implement and will always keep your code safe. I've started to always do it as well and stay consistent with the vanilla game code. And in your edit it looks like you changed it accordingly. Nice code.

flieskiller flieskiller
Yes! I can't tell you how frustrating this problem was to me a while back when I was still writing codes from an external offset notation. Players spawned in training mode will be displaced incorrectly, for instance.

I've actually been focusing on this a lot lately because of your post here.

Old habits die hard though. The "quick revision" I made was a result of me forgetting to load the internal offset.

I'm working on a little project right now that had me carefully consider this problem. It caches pointers in a little endian format for Cheat Engine to use in order to watch RAM from constructed pointer chains. It uses a few special syntaxes, and one of them summarizes player data offsets in either an external or internal offset notation.

With this problem in mind, I've made it so that regardless of the notation used, the effective displacement is determined to be < or >= 0x60, and the appropriate BA is used for internal addresses by loading -> 0x2C.

This way, for the input syntax, it correctly displaces external notations if they are input as references from the SSBM data sheet.
 
Last edited:

flieskiller

Smash Journeyman
Joined
Jan 3, 2013
Messages
426
That means it's better to use the bigger address of the two? That's nice to know
 

jra64

Smash Journeyman
Joined
Jan 30, 2004
Messages
372
I have been using this code so much for practice. Thanks to both of you. So far it works flawlessly. Is there any way to get it where P2 is also invincible to throws? That would help a lot since P2 is the only one that you can toggle 20XX codes for...
 
Last edited:

Punkline

Dr. Frankenstack
Joined
May 15, 2015
Messages
423
I have been using this code so much for practice. Thanks to both of you. So far it works flawlessly. Is there any way to get it where P2 is also invincible to throws? That would help a lot since P2 is the only one that you can toggle 20XX codes for...
No problem at all. Here ya go:


$P1 and P2 are Immune to Throws [Punkline]
C2078A6C 00000004
809D002C 8884000C
2C040001 389D0000
41810008 7C641B78
60000000 00000000


Code:
-==-


P1 and P2 are immune to throws
Throw hitboxes have no effect on Player 1 or Player 2
[Punkline]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x80078a6C --- 389D0000 -> Branch

809D002C 8884000C
2C040001 389D0000
41810008 7C641B78
00000000

---

Also here's one that does just P2

$P2 is Immune to Throws [Punkline]
C2078A6C 00000004
809D002C 8884000C
2C040001 389D0000
40820008 7C641B78
60000000 00000000

Code:
-==-


P2 is immune to throws
Throw hitboxes have no effect on Player 2
[Punkline]
Version -- DOL Offset ------ Hex to Replace ---------- ASM Code
1.02 ----- 0x80078a6C --- 389D0000 -> Branch

809D002C 8884000C
2C040001 389D0000
40820008 7C641B78
00000000

Note: All of these use the same hook, so only use one code at a time.

Only briefly tested, so let me know if there are any problems.
 
Top Bottom