Removing the Dead Frame on Jumps [Working Code now posted]

[shanus]

Figured this probably concerns every project back here.

As we all know, either on the last frame of jump start or first frame of jump (I think its jump start), there is a frame where NO input is accepted impeding the ability to do perfect timed aerials, etc.

This is a major concern and something that should be fixed.

Can someone with frame advance test the following?

In JumpSquat in PSA

Change Action: 33, req=animation end
Add Req, Button Press: 0
Add Req, In Air
Change Action: 0C, req=Animation end
Add req= Button pres: 2
Add req=In Air
Add req: Compare LA-Basic[1]<IC-Basic[219]
Chance Action: 21, req=Animation End
Add req=Button press: 3
Add req= In Air

If this does work, then I'll type up all the coding for specials, too.

 

[Veril]

Its pretty much only an issue for people with a 0 buffer, but yeah (iirc) the final frame of jump startup doesn't accept inputs.

I have to say, I'm really curious as to why that is. I mean, you'd assume that there was a reason behind this.

 

[Shell]

I mean, you'd assume that there was a reason behind this.

lulzluzluzluzluzluz

Ahem. Shanus, have you talked to Magus yet? He had half of the custom dead frame buffer complete, I believe.

 

[shanus]

lulzluzluzluzluzluz

Ahem. Shanus, have you talked to Magus yet? He had half of the custom dead frame buffer complete, I believe.

It's a similar code, I just want to know the exact specs on it.

 

[Budget Player Cadet_]

Using PSA for this is probably not the greatest idea, just sayin'... It would not be that great for Samus/Zamus/Pit/Sonic coders.

 

[shanus]

Using PSA for this is probably not the greatest idea, just sayin'... It would not be that great for Samus/Zamus/Pit/Sonic coders.

You do it in PSA to test if it works, then make a fighter.pac injection.

 

[Budget Player Cadet_]

Ooooh....

I feel stupid. Derp. :V

 

[Magus420]

http://www.mediafire.com/?t2namun1hdw

That was what I had done on it before. I'm sure it could be done much more efficiently, and it also was done in a way where it'd need to be a little different depending on the character, since it used a timing based on how long their jump startup animation is as well as whether they have a z-air, smash side-b, etc. I only bothered putting the part that 'reads' any stored moves in the forward fulljump and forward shorthop subactions and not the backward jumps.

Basically, at the start of jump squat it clears a series of true/false bits which each represent a move (I could never get storing them as numbers to write/read properly for whatever reason), then on the last frame of jump squat it checks for certain inputs and sets the corresponding bit to true. Then at the start of the jump subactions it checks them and if one is set true it goes to the move for that bit.

The conditionals for directions are wrong, and possibly something else is messed up. I do know that I was able to get that basic method to work when I only had the stuff for storing a f-air as a test, confirmed both in frame advance and in real time from the fact f-air could only AC out of a SH back then if started on the 1st air frame. When I added everything else in I think I was getting the same aerial regardless of which direction I was holding so I know that part isn't working right.




Didn't Dant say it does actually read your input on the dead frame? I'm guessing it probably 'eats' the input from that frame either when doing the direction of your jump (if you c-stick to the side this frame it'll use the direction but the A input from it gets lost), or that buffered inputs are handled after the change to the jump animation takes place while inputting normally has you do your action for it before the switch to jump and then it gets overwritten with the jump that 1st air frame and never actually happens.

IIRC in Melee it decided the direction of your jump ON the last frame of jump startup, while in Brawl I believe it decides this on the 1st air frame/when you change actions from jumpsquat to jump. This key difference could very well be where the problem stems from, though I imagine it'd be possible to have the jump direction read on the frame it currently is they probably just ****ed it up and it conflicts with trying to input other stuff that frame.

Maybe when it's determining whether it's a JumpF or JumpB it somehow uses up the direct button inputs, or perhaps direct input aerials and such take place before JumpF vs JumpB takes place and then JumpF/B overwrites it and then buffered inputs are handled after and are able to overwrite the jump properly to be the end result of what takes place on that frame?

 

[shanus]

I think i've made a couple of discoveries regarding this that needs immediate testing:

In Action 0B it instructs the game to read controller inputs on the first frame.
07010000
07020000

We can possibly try nopping these and seeing if it doesn't clear the inputs.

 

[shanus]

It works, can someone test if it impacts buffer?

Remove Dead Frame on Jumps [Shanus]
06FC18F8 00000010
00020000 00000000
00020000 00000000

 

[[TSON]]

this will just make the yoshi stall easier to perform lol

 

[Dantarion]

Okay.

Shanus, did you try NOP'ing ONE of the two commands? Perhaps one of those commands just refreshes the input state or something.