Request Autolink Angle

[tatatat0]

What I have in mind is if the hitbox has an angle of 362(or whichever angle is not being used), for when the enemy is hit to set the angle based on the attackers velocities.

 

[flieskiller]

for instance, if the player is moving at a 60° angle, the opponent hit will be launched at 60° angle too?

 

[tatatat0]

for instance, if the player is moving at a 60° angle, the opponent hit will be launched at 60° angle too?

Yep, so things like fox's f-air can actually connect, cause lets be honest, Fox's f-air is booty.

 

[Punkline]

If I knew more about the math functions available in the game, I'd give this a shot... it's a good idea!

If anyone more competent than me wants to make this, check out the function at 0x8007121c (v1.02.) This is the function that parses hitboxes. In particular, I think 0x800713f4 is where angles get parsed. Manipulating the value in r4 here to match a calculated angle would probably do the job.

 

[flieskiller]

^ Should just make when the angle is read, in the code "if angle = 361", make an extra check for new angle (ie 363) and set the angle of the attack similar to the Sakurai angle.

 

[Punkline]

^ Should just make when the angle is read, in the code "if angle = 361", make an extra check for new angle (ie 363) and set the angle of the attack similar to the Sakurai angle.

Yeah, so some psuedocode:

@angleParse
If angle == 362 (or whatever)
then do angle calculation and replace value in r4

I think there might be some things in the CMS that could help make this simple. I'm still pretty unfamiliar with most of the stuff in there though.

 

[flieskiller]

Yeah, so some psuedocode:

@angleParse
If angle == 362 (or whatever)
then do angle calculation and replace value in r4

No, what I mean is not using that place in the code, I think for clarity it would be the wrong place to do that. I'm sure there is somewhere in the code where the angle is read and has a "if angle == 361", and it's that place that should be used. There are some chances that using this place for the code would get overwriten by the check made later. For instance, you change the angle, then later there is a check "if bigger than 361", and the new angle gets replaced by Sakurai angle; Or maybe even having a condition problem and getting a random angle from time to time

 

[Punkline]

No, what I mean is not using that place in the code, I think for clarity it would be the wrong place to do that. I'm sure there is somewhere in the code where the angle is read and has a "if angle == 361", and it's that place that should be used. There are some chances that using this place for the code would get overwriten by the check made later. For instance, you change the angle, then later there is a check "if bigger than 361", and the new angle gets replaced by Sakurai angle; Or maybe even having a condition problem and getting a random angle from time to time

I see what you're saying. Potentially more complicated than I thought. I'll look into this tonight or tomorrow though if I can, because it'd probably be simple to find such a function by watching the angle stored in the player data.

 

[Punkline]

I took another quick look at the CSM before starting a hunt and found that Achilles had mapped out a function that might do well for this.

0x8008d7f0 -- ac_Damage_CheckAttackAngle_f1Out=AttackAngleRadians

At 0x8008d804 the function loads player.0x18A8 (which appears to hold the player's current knockback angle) and checks it for a sakurai angle.

Changing the angle stored at player.0x18A8 to 361 (just before it's loaded) can force an inappropriate sakurai angle in the resulting knockback. Maybe this would do?

 

[SinsOfApathy]

At 0x8008d804 the function loads player.0x18A8 (which appears to hold the player's current knockback angle) and checks it for a sakurai angle.

View attachment 99103

Corrected the data sheet on that. Though it being 0x169 normally is funny, because that is the Sakurai angle. I kinda feel like Sakurai Angle is more of a default than anything else now.