COMPETITIVE Brawl+: Code Agenda

[Igglyboo]

Kupo, I posted this over at gscentral but I don't think you noticed, so i'll just leave this here...

Default CPU Level Modifier[Igglyboo]
C2693A70 00000002
3880000X 909E01D4
60000000 00000000

CPU Level - 1 = X
(level 9 would be X=8, don't go over 8)

 

[zxeon]

Kupo, I posted this over at gscentral but I don't think you noticed, so i'll just leave this here...

Default CPU Level Modifier[Igglyboo]
C2693A70 00000002
3880000X 909E01D4
60000000 00000000

CPU Level - 1 = X
(level 9 would be X=8, don't go over 8)

Cool beans.

 

[matt4300]

since we are on the subject of cpus... i was wondering for a while now if it was possible to fix the problem with all of them going after the human player and hardly fighting each other... its really not fun and completely kills 4 player for me (with cpus) i know this has nothing to do with competitive codes i just want to know ^_^

 

[kupo15]

@kupo:


Now, for stopping people from airdodging while in in a tumble... Let me just say that stopping airdodge while in a tumble will do nothing to nerf the defensive game. Do you hear me? It will do nothing. All your opponent needs to do is tap left or right on the control stick when they go into the tumble, and they will be set into their freefall position, allowing them to airdodge again. This existed in melee, too, although people didn't usually airdodge out of it since they were often too high in the air for the airdodge to be effective.

Nothing? Like nothing? I tend to disagree. I think that the extra step needed to perform a defensive maneuver such as an air dodge does something.

 

[MookieRah]

It would do something, but not much. On the highest level of play it won't make much of a difference. I also don't see a need to fix something like that, cause if you know the timing of the airdodge after tumble without wiggling out I don't see why it's a bad thing.

 

[leafgreen386]

Nothing? Like nothing? I tend to disagree. I think that the extra step needed to perform a defensive maneuver such as an air dodge does something.

And I think it's insignificant. It's like SDIing fox's uair in melee except a million times easier. Basically all you have to do is dashdance in the air right before you airdodge. You'll get the airdodge every time with zero delay.

 

[kupo15]

And I think it's insignificant. It's like SDIing fox's uair in melee except a million times easier. Basically all you have to do is dashdance in the air right before you airdodge. You'll get the airdodge every time with zero delay.

well then what other codes besides the air speed are we missing to make this a solid game? Its all about the smaller codes to tighten the game up as of now.

 

[MookieRah]

Grab release codes come to mind. We need to solve that issue.

 

[maplesyrupandjam]

Grab release codes come to mind. We need to solve that issue.

I recall that being fixed.. I remember it was posted on the Brawl xat channel, but I don't see it anywhere on the op, but it does exist I've used it.

 

[MookieRah]

There were a few solutions to it, but nobody decided on what was better, and the group involved decided that the solutions they came up with weren't good enough yet.

 

[Alopex]

In terms of major codes, air momentum is it. That's why I've been pushing this whole time for effort to be allocated towards fixing the issues that our current codes have. They're not all perfect yet.

I'm going to make a nice organized list of the things that need to be fixed within the currently available codes, then that should take us somewhere.

New new codes that are needed are grab release fixes and bounce lock removal.

I've mentioned before that the solution to grab releases is simple: we just need to make the frame length for all 3 animations universal. The universal value is 30.
30 frame air release, 30 frame ground release, 30 frame grab break for the grabber.
That's really all there is to it. It retains the positional advantage that one would seek from a release instead of a throw, but it doesn't give any time advantage.

As for grabs off the edges not returning mid air jumps... that one I don't know.

 

[Jiangjunizzy]

couldn't we use the same method we are using to speed up the fast edges to speed up the grab release animation?

 

[Shell]

Or slow down, as needed (some animations have 20 frame length, others 40, most 30). But yeah, that sounds good.

 

[dgameman1]

Whats the prob for having more than 40 icons for the CSS?

 

[Shadic]

The player icons aren't much bigger than the player tokens at 40.

 

[plasmatorture]

Whats the prob for having more than 40 icons for the CSS?

There is no problem.

 

[leafgreen386]

The player icons aren't much bigger than the player tokens at 40.

Just an fyi, here...

36 icons = 4 rows, 9 columns
37-40 icons = 4 rows, 10 columns
41-45 icons = 5 rows, 9 columns
46-50 icons = 5 rows, 10 columns

Well, I haven't tested it myself, but based on what I've seen so far this should be true. Only the ones with 10 columns will have the smaller portrait sizes.

 

[Alopex]

Current Code Issues That Still Need to be Fixed

(The list is in no particular order.)

1) Lagless Ledges needing more invincibility frames.

• This was being thrown around before and kupo has stated that a separate code is needed to adjust for this.

2) No Auto-Sweetspot not properly affecting all characters.

• a) Diddy's recovery needs to get fixed. Its current state like this is tolerable, but
  hardly appropriate.

• b) The code has been shown to affect write-protected Ness and Lucas. It's inconsistent
  and seems to affect them differently, though. Meanwhile it does not affect write-
  protected Lucario.
  Given enough research into the matter, the code could maybe be perfected to work
  consistently on all characters pending the consensus on how every character should be affected.
  In the case of Ness and Lucas, for example, if the consensus is that they should always ASL, then the code
  needs to be perfected in order to make sure that is what always happens.

3) YES! lag.

• It still exists despite the TJG Fix.

4) Near Perfect Shielding.

• Spunit's previous shieldstun code got rid of it, but the current one still has it. Spunit is looking into the matter and hopefully it'll be fixed soon.

5) Buffer glitches.

• Instant aerials still can't be performed on 0 buffer. Many Brawl+ players feel that 0 buffer is the way to go, so this needs to be rectified in order for it to be viable.

• Any buffer setting above 1 is glitched to a near unplayable degree. This needs to be fixed in order for values of 2 and above to be properly tested and discussed.

There might be some glitches I have missed. If so, mention them and I'll add them here.


Some mechanics-related codes that are still need to be created:
1) Air momentum.
2) Grab release fix.
3) Bounce lock fix.
4) Damage-only decay.

 

[Shadic]

Just an fyi, here...

36 icons = 4 rows, 9 columns
37-40 icons = 4 rows, 10 columns
41-45 icons = 5 rows, 9 columns
46-50 icons = 5 rows, 10 columns

Well, I haven't tested it myself, but based on what I've seen so far this should be true. Only the ones with 10 columns will have the smaller portrait sizes.

I'm fairly certain that vertical space is limiting icon size as well.

 

[Heavyarms2050]

@Alopex
what is YES!

 

[Dan_X]

@Alopex
what is YES!

Why it's that special moment between you and a lady friend, of course!

No but seriously, it's Falcon's up+B (YES!!).

 

[leafgreen386]

5) Instant aerials on 0 buffer.

* This still can't be done and might never be done, but it's worth looking into.

Screw that. We don't need to go any lower than 1 buffer.

2) No Auto-Sweetspot not properly affecting all characters.

* a) Diddy's recovery needs to get fixed. Its current state like this is tolerable, but
hardly appropriate.

* b) The code has been shown to affect write-protected Ness and Lucas. It's inconsistent
and seems to affect them differently, though. Meanwhile it does not affect write-
protected Lucario.
Given enough research into the matter, the code could maybe be perfected to work
consistently on all characters.

@Diddy: ok
@lucas/ness/lucario: honestly, why do you want to make it harder for them to recover than it is already? their recoveries already suck - give them a break

@Alopex
what is YES!

The sound falcon makes when he upBs you. >_> It still has lag afterward if he connects, for no good reason whatsoever.

 

[Dan_X]

Current Code Issues That Still Need to be Fixed

(The list is in no particular order.)

1) Lagless Ledges needing more invincibility frames.

• This was being thrown around before and kupo has stated that a separate code is needed to adjust for this.

2) No Auto-Sweetspot not properly affecting all characters.

• a) Diddy's recovery needs to get fixed. Its current state like this is tolerable, but
  hardly appropriate.

• b) The code has been shown to affect write-protected Ness and Lucas. It's inconsistent
  and seems to affect them differently, though. Meanwhile it does not affect write-
  protected Lucario.
  Given enough research into the matter, the code could maybe be perfected to work
  consistently on all characters.

3) YES! lag.

• It still exists despite the TJG Fix.

4) Near Perfect Shielding.

• Spunit's previous shieldstun code got rid of it, but the current one still has it. Spunit is looking into the matter and hopefully it'll be fixed soon.

5) Instant aerials on 0 buffer.

• This still can't be done and might never be done, but it's worth looking into.

There might be some glitches I have missed. If so, mention them and I'll add them here.


Some mechanics-related codes that are still need to be created:
1) Air momentum.
2) Grab release fix.
3) Bounce lock fix.
4) Damage-only decay.

Don't forget, we also need codes to make Diddy, Lucas, and Ness "slide" up the edge of a platform when recovering. I've seen this one tossed around a bit.

 

[Alopex]

Screw that. We don't need to go any lower than 1 buffer.

I agree whole-heartedly. Others don't. Kupo is one of them. In order to make an unbiased list, I included it.

@Diddy: ok
@lucas/ness/lucario: honestly, why do you want to make it harder for them to recover than it is already? their recoveries already suck - give them a break

I have no ill will toward the Mother Boys. Ness was my 64 main and Lucas was my first Brawl main. I love them and want them to succeed. I'm just looking at this objectively.
Is the common consensus that they SHOULD or SHOULDN'T retain the auto-sweetspot?
In either case, the code needs perfecting because it currently sometimes works for the Mother Boys and sometimes doesn't.
Regardless of the consensus, the code needs perfecting to work on the Mother Boys one way all the time. Whether that one way be No ASL or Yes ASL.
Nevertheless, the list needed to be unbiased. Link has the worst recovery still and needs the ASL more than the Mother Boys - "give him a break". But see, that's a biased point. And saying the same about Lucas and Ness could also be seen as biased.
I made an unbiased list that leaves the facts up for discussion.

You want my personal opinion to get that started?
Lucas, Ness, Lucario, Link, and all tether characters should retain the ASL, since they have the worst recoveries.

 

[cooler1339]

They might have bad recoveries but that's how they are. They should be given the power to make up for it on the stage though. Link still seems to lack killing power with aerials and smashes.

I wish the initial hit of his air upB(ground too) was a killer like N64. that was so great.

Oh I was also wondering if there was any plans to remove fastfall and tilts from the c-stick?

 

[Dark Sonic]

edit: Nevermind, I don't need it anymore.

 

[Revven]

You want my personal opinion to get that started?
Lucas, Ness, Lucario, Link, and all tether characters should retain the ASL, since they have the worst recoveries.

I agree with Lucario (he can't be changed anyway... lol), but... Link? Not so sure about that. He can't do anything to retaliate from the ledge and if he ASL's, his Up B won't hit people away from the ledge like it did in Melee so he could get back onto the stage. And, why would tethers change? lol. They work the same right now as is. Lucas and Ness seem okay now... well, Lucas I have a bit of a problem with. Sky rocketing against FD's edge?... Not good. I'd be fine with him ASLing.

Ness though, I suppose he could ASL if it's a HUGE issue but, it really isn't. I bet you if I'm Ness and NASL is on, I can, 90% of the time recover back to the stage and snap onto the ledge. It's not that hard (it shouldn't be) and I shouldn't bounce off the ledge or go past it if I'm far away enough. It's alllllll about the spacing for Ness, which isn't really a huge problem for him (it certainly wasn't in Melee).

 

[kupo15]

I agree whole-heartedly. Others don't. Kupo is one of them. In order to make an unbiased list, I included it.




I have no ill will toward the Mother Boys. Ness was my 64 main and Lucas was my first Brawl main. I love them and want them to succeed. I'm just looking at this objectively.
Is the common consensus that they SHOULD or SHOULDN'T retain the auto-sweetspot?
In either case, the code needs perfecting because it currently sometimes works for the Mother Boys and sometimes doesn't.
Regardless of the consensus, the code needs perfecting to work on the Mother Boys one way all the time. Whether that one way be No ASL or Yes ASL.
Nevertheless, the list needed to be unbiased. Link has the worst recovery still and needs the ASL more than the Mother Boys - "give him a break". But see, that's a biased point. And saying the same about Lucas and Ness could also be seen as biased.
I made an unbiased list that leaves the facts up for discussion.

You want my personal opinion to get that started?
Lucas, Ness, Lucario, Link, and all tether characters should retain the ASL, since they have the worst recoveries.

Is it really necessary to single me out alopex like Im some sort of bad person????? Seriously and I am actually using 1 frame thank you very much >_>

Maybe I'll start singling you out when you have different opinions... -_-

 

[matt4300]

couldent you say the same about diddy though? he is also about spaceing with ASL.

 

[Revven]

couldent you say the same about diddy though? he is also about spaceing with ASL.

With ASL, his is easy as pie. With NASL, it's a little different, then again I didn't play Diddy much in the time I've been playing Brawl+ (I onno why, CF and some other people are taking higher priority). As a Diddy main, I shouldn't have much trouble either but, again, I haven't really been playing Diddy in Brawl+ soooo.... =\

 

[Shadic]

Is it really necessary to single me out alopex like Im some sort of bad person????? Seriously and I am actually using 1 frame thank you very much >_>

Maybe I'll start singling you out when you have different opinions... -_-

Maybe he's singling you out because you've made yourself a high-profile person when it comes to this project? Just saying.

 

[kupo15]

Maybe he's singling you out because you've made yourself a high-profile person when it comes to this project? Just saying.

im not the only "high profile person" and its really rude to be that direct especially since I changed my code set

 

[Revven]

im not the only "high profile person" and its really rude to be that direct especially since I changed my code set

Don't worry kupo, I still <3 you.

 

[SketchHurricane]

Screw that. We don't need to go any lower than 1 buffer.

I still think we should be around 3 for the buffer. 1 makes certain timings just a bit unnecessarily difficult. It also has the undesired side effect of making the game a bit slower overall. This is because with an unforgiving window, you are that much closer to executing things too early in addition to too late. While executing too late makes you slow, executing too early makes absolutely nothing happen, which is worse. The result is that you have to be generally more conservative with your timing in order to prevent that worse case scenario.

With the buffer at a more reasonable level, you will retain some of the tight controls while also making truly instant execution more viable with early button presses. Does this make any sense?

Having said that, the buffer window glitches for anything above 1 need to be fixed first, of course.

Is the common consensus that they SHOULD or SHOULDN'T retain the auto-sweetspot?

Judging from that video that revealed the problem, they should definitely be exempt. No ASL sometimes causes them to bounce completely in the other direction when hitting the edge (similar to what happens during an edgehog). That's completely unacceptable.

 

[zxeon]

I agree whole-heartedly. Others don't. Kupo is one of them. In order to make an unbiased list, I included it.

We hatin' on Kupo? *High five*
Wait, I think zero buffer should be fixed too. What do I do?

I think zero buffer should be fixed too I don't like ducking after SHFLing a Nair with Marth.

 

[Dan_X]

I don't think we need to fix 0 buffer. 1 buffer is absolutely fine-- the best of both worlds. I'd consider using 3frames of buffer it it worked, as sometimes I do find the flow of gameplay to be off. Sometimes I fail to time something correctly that before I never had to time. I can't explain what it is that I mess up with regards to timing, it's generally little things. It is aggravating though (more aggravating then the mess up that a larger buffer frame would give me).

So does the 1line buffer code work????

Furthermore, what about the buffer code integrated in the merged code? Does that work?

 

[leafgreen386]

We hatin' on Kupo? *High five*
Wait, I think zero buffer should be fixed too. What do I do?

I think zero buffer should be fixed too I don't like ducking after SHFLing a Nair with Marth.

Stop holding the control stick for so long then imo

And I would also like to add that I think a 3 buffer would be ideal. I forgot to add that on my post that we should be working to get the higher buffer values working rather than zero.

 

[petre]

Sometimes I fail to time something correctly that before I never had to time.

that's part of the problem, IMO. the huge buffer window allows people to be really inaccurate with their inputs.

 

[Dan_X]

that's part of the problem, IMO. the huge buffer window allows people to be really inaccurate with their inputs.

Yeah but I've played with 1 buffer for a while now and certain things just don't seem smooth. Sometimes after doing some attack that sends the enemy into the air, I fail at following up because of the buffer window. Like, my attack hadn't finished precisely on the ground and I tried jumping. Maybe it's just something that I need more practice with... Either way, I think 3 frames of buffer would alleviate that. There's should be many mistakes made with 3 frames of buffer... we shouldn't be working to eliminate the buffer, just lessen it to the point where it will no longer mess us up.

 

[Yeroc]

So, you want the buffer to help you out where you'd otherwise mess up, but not mess you up where it makes you do things you don't want to do. I'm sorry, I mean no disrespect, but seriously, learn the proper timings on the button presses IMO. It had to be done in both the other Smash games, and all other fighters. Buffering is sloppy and impedes gameplay. Get rid of it.

For those of you still crying about things like autocanceling and other jump aerial timing, who actually plays on a gravity/fallspeed setting where those things are still actually possible within the jump window?