Random Hitbox Elements

[Achilles1515]

From Magus on hitbox info:

(This is a picture because I can't edit or quote that post.....???)

Random Hitbox Elements - Every Non-projectile Attack (1.02) [Achilles]
C20715B0 00000009
7C0F0378 38600010
3C808038 60840580
7C8903A6 4E800421
2C030004 41A2FFE8
2C030007 41A2FFE0
2C030008 41A2FFD8
2C03000B 41A2FFD0
907E0030 7DE07B78
28000009 00000000



Random Hitbox Elements - Modified Attack Specific (1.02) [Achilles]

• Hitbox element will be random if the element ID within the hitbox event equals 0x11 (or in terms of Magus' list from above, 44).
  • So you can manually change specific hitboxes to have random elements.

C20715B0 0000000B
807E0030 2C030011
40820044 7C0F0378
38600010 3C808038
60840580 7C8903A6
4E800421 2C030004
41A2FFE8 2C030007
41A2FFE0 2C030008
41A2FFD8 2C03000B
41A2FFD0 907E0030
7DE07B78 28000009
60000000 00000000

Function:
8007121C    SubactionEvent_HitboxData


Random Hit Elements
inject @ 800715b0 - cmplwi r0,9
- after much hitbox info has been loaded

lwz r3,0x30(r30)    # load hitbox element ID
cmpwi r3,0x11    # does is equal 0x11 or 44 from Magus' post?
bne- END

mr r15,r0   # save register 0
REPEAT_RNG:
li r3,16
lis r4,0x8038
ori r4,r4,0x0580
mtctr r4
bctrl          # branch to random function and return a value between 0x00 and 0x0f, inclusive
cmpwi r3,7     # ignore sleep [long]
beq- REPEAT_RNG
cmpwi r3,8     # ignore grounded [first? - the one I can't get to do anything]
beq- REPEAT_RNG
cmpwi r3,0xb     # ignore empty (gray hitbox)
beq- REPEAT_RNG

stw r3,0x30(r30)    # store element effect
mr r0,r15              # restore register 0

END:
cmplwi r0,9    # default code line

------------

To make it happen on every attack, remove the first three lines from the above function.

Idk about the attack SFX part, but I figured I would put it in there because some of element IDs have the same SFX IDs (Ice, for example). But I think the cape effect will produce a shell sound (which is kind of cool)...so it doesn't always work correctly. Feel free to take that line out and the SFX will be the same as from the hitbox data.

@ MagicScrumpy you know what to do with that first code...

Playing with this code is just ridiculous and fun and frustrating at the same time.

 

[MagicScrumpy]

I played around with it, and this is pretty wild. I found that the game freezes sometimes when this code is enabled though; interestingly, I'm pretty sure all of my crashes had to do with the Link I was playing against when making the TAS.

If anyone's interested, a video of this in action can be found at https://www.youtube.com/watch?v=S7Y3bg8nEaQ

Great work on this, Achilles! This is fun stuff; I'll probably do more with it in the future as well as figure out the exact source of the crashes and maybe try to spruce up the code a little bit or something to prevent the crashes from happening.

 

[Achilles1515]

I played around with it, and this is pretty wild. I found that the game freezes sometimes when this code is enabled though; interestingly, I'm pretty sure all of my crashes had to do with the Link I was playing against when making the TAS.

If anyone's interested, a video of this in action can be found at https://www.youtube.com/watch?v=S7Y3bg8nEaQ

Great work on this, Achilles! This is fun stuff; I'll probably do more with it in the future as well as figure out the exact source of the crashes and maybe try to spruce up the code a little bit or something to prevent the crashes from happening.

Awesome video, man! I really appreciate you taking the time to make this. I wonder what the freezes could be from…My first thought would be something like changing the hitbox element to “grounded” but leaving the hitbox property as being able to hit aerial opponents and that hitbox actually connecting with an aerial opponent. Maybe this would cause a freeze. Were the freezes happening when hitting the opponent? I can’t test at the moment, but you could just modify the above code and replace the “bctrl” line with “li r3,9” to force every hitbox to be the grounded type.

I think this will be a fun game mode to play around with.

And that is a really powerful function to tap into. If you look into the code lines before the injection point I used, you can see it picking apart every piece of the hitbox subaction event data and storing these values into the character data offset. This function is the direct function that is branched to after it reads the “2CXXXXXX” event type. You could do all sorts of interesting things with this function, like pulling the character’s current damage percent, and if it’s above 100, then multiply the hitbox damage by 1.2 or anything like that. Or do things if it is a specific character, etc.

But now I have a basic understanding of how the game handles subaction events, and I can find the specific functions that control each event type. Disabling these functions completely, or just stepping through them, can probably shed light on each event IDs purpose faster than trial and error.

 

[Achilles1515]

I played around with it, and this is pretty wild. I found that the game freezes sometimes when this code is enabled though; interestingly, I'm pretty sure all of my crashes had to do with the Link I was playing against when making the TAS.

If anyone's interested, a video of this in action can be found at https://www.youtube.com/watch?v=S7Y3bg8nEaQ

Great work on this, Achilles! This is fun stuff; I'll probably do more with it in the future as well as figure out the exact source of the crashes and maybe try to spruce up the code a little bit or something to prevent the crashes from happening.

I updated the code. It was the "40 - nothing" element that was causing freezes, so it's been removed.

 

[MagicScrumpy]

I'm getting even more crashes now. Over many tests, I've seen no pattern between characters/moves used and likelihood of crashing.

I'll look into this myself to see if I can find anything. If anything, it'll be a good learning experience! :>

 

[Achilles1515]

I'm getting even more crashes now. Over many tests, I've seen no pattern between characters/moves used and likelihood of crashing.

I'll look into this myself to see if I can find anything. If anything, it'll be a good learning experience! :>

Hmm. It was freezing for me every now and then like you stated before, but now it doesn't seem to at all. I just watched 2 minutes of 4 lvl 9's playing with this code enabled.

 

[Achilles1515]

@ MagicScrumpy
I tried the code on console and it was freezing again, like you said. I ran some tests and figured out the problem was the SFX IDs. So I took that line out and then the freezing seemed to stop.

I updated the code on the OP. Give it a try again, and let me know how it goes.

 

[flieskiller]

Is it possible to exclude grabs from having a random hitbox? Grabs are useless with this active, because they have another effect and characters doesn't grab anymore.

I'm thinking of trying to add a cooldown to hitboxes too, so multi-hit attacks aren't going crazy on more extreme hitboxes effects, like screw attack/sleep effects

 

[Achilles1515]

Is it possible to exclude grabs from having a random hitbox? Grabs are useless with this active, because they have another effect and characters doesn't grab anymore.

I'm thinking of trying to add a cooldown to hitboxes too, so multi-hit attacks aren't going crazy on more extreme hitboxes effects, like screw attack/sleep effects

That reminds me that I've been meaning to do this.

Try this:

C20715B0 0000000B
807E0030 2C030008
41820044 7C0F0378
38600010 3C808038
60840580 7C8903A6
4E800421 2C030004
41A2FFE8 2C030007
41A2FFE0 2C030008
41A2FFD8 2C03000B
41A2FFD0 907E0030
7DE07B78 28000009
60000000 00000000

 

[flieskiller]

The grabs works fine now.