Brawl+ Project Hub: OP updated 4/28 w/expansion pack and why it is necessary

[Plum]

Haha I forgot about that post Viet <3

Glad to see that people want characters dying earlier though.

 

[MK26]

i tried and failed to understand the stage boundary code <_<

and i would argue with veril but i just read a series of Sirlin's articles that essentially amounted to "you should lol at noobs who demand changes, but go ahead and meatride the pros all you want because they'll help you make your game better"

 

[VietGeek]

yeah meatriding pros gets sh*t done

and hey

maybe veril can get m2k to NOT wear gym shorts to every tournament

*...remembers the last Tipped Off...o_O*

 

[Veril]

yeah meatriding pros gets sh*t done

meatride the pros all you want because they'll help you make your game better

My initial reaction was to tell both of you to **** yourselves. Giving more weight to the opinions of the best player in the world, the best Kirby in vB and B+, and a top East coast Kirby... when they are all saying the same exact thing ≠ meat-riding.

Look, I'm not having a good day (girl+headache related). Saying I'm meatriding anyone is really insulting and I'd appreciate it if you would be a bit more careful with your choice of words.


If I could make M2K less smelly... yeah, definitely would.

 

[JCaesar]

In all honesty, M2K just wants the character he plays (which happens to be Kirby in Brawl+'s case) to be the best in the game. Vanz knows what I'm talking about.

Not to say that Kirby wasn't overnerfed, but M2K's opinion on it should be taken with a grain of salt.

 

[MK26]

My initial reaction was to tell both of you to **** yourselves. Giving more weight to the opinions of the best player in the world, the best Kirby in vB and B+, and a top East coast Kirby... when they are all saying the same exact thing ≠ meat-riding.

Look, I'm not having a good day (girl+headache related). Saying I'm meatriding anyone is really insulting and I'd appreciate it if you would be a bit more careful with your choice of words.


If I could make M2K less smelly... yeah, definitely would.

O_O nonononono

i was just paraphrasing the article

which said that you should ignore the screaming masses and only take important peoples' opinions into account

even especially if they have trouble articulating that opinion, because once theyre good enough they dont need to have basic English skills

and i though the most concise word to sum that all up would be the verb 'meatride'

v_v"

i need to choose my words better

ok, no, i didnt really think at all when making that post

:/

 

[Thunderhorse+]

i was just paraphrasing the article

which said that you should ignore the screaming masses

Well we already failed on that front *looks at Marth mains*

I wouldn't be opposed to giving Kirby some power back on his fsmash. NOT ALL. The original fsmash was stupid good, and I would never want to see that back. But if people think he's a bit over-nerfed, I would be willing to conceed some of his power back, and maybe something nair-related if really pressed. But he's pretty good as is.

But it's M2K ._.

 

[VietGeek]

What JCaesar said...

and in all honesty, since the point where you've taken over the Brawl+ project leadership, you never seem to have a good day considering how many light jabs/jokes you've misinterpreted on simply the WBR. Life is sh*t anyway so I won't continue.

Moving on:

Death Boundary Modifier as it currently is in Brawl+ (unless any of you "pulled a fast one" since GSH2):

065A9000 00000020
1CF0F330 CD000000 WarioWare
2DF0F1A0 E6000000 Green Greens
30F0F030 FD000000 Corneria
37F00000 000D0000 Online Practice

So let's see...Corneria is banned, Online Practice is considered un-salvageable AND the border modifications in the end only added to the suckage. IDK about Green Greens, and honestly we should adopt the fixed WarioWare .pac that allowed wall jumps on the lower portion of the stage (and apply the boundaries in the .pac).

For the curious, here are B+ WarioWare's current boundaries (according to the code):

Left Boundary: F33 (3891)
Right Boundary: 0CD (205)

Rest assured this makes sense! Not really...

if we assume that each block added by the code = 20, then it would make sense I guess.

3891/20 = 194.55 added to original left boundary
205/20 = 10.25 added to original right boundary

...yeah, still doesn't seem to add up huh?

so...it seems to actually affect a lot less stages than we thought...maybe we should decrease the death boundaries anyway? Let's be honest here, people still die way too late even if the DBM isn't the culprit. It's pretty obvious that hitstun is partly to blame, but we're apparently content with that (or at least I am) and so let's shift our focus to the original stages' boundaries.





Also why does it seem like Magus' post on Luigi (http://www.smashboards.com/showpost.php?p=9405497&postcount=30) was ignored? The hitstun practically buffed the move unintentionally, and thus I would assume falls under the category of "things that should be fixed due to improper function."

The growth on the meteor hitbox is only 7. The fact that the move does not tumble due to the hitstun constant being decreased should at least spark some interest on the subject, no? Or are we waiting for something "terrible" to happen? *shrug*

Well we already failed on that front *looks at Marth mains*

 

[leafgreen386]

/agree on stage boundary reductions.

I can also see giving some of the power back to kirby's fsmash, just not all of it. Especially if we're gonna reduce the stage boundary sizes.

 

[Yeroc]

School time kids!

The way the code works works is it assigns four 3-digit integers. Remember, integers of a given variable size in hex always function like this: the first half of the possible values are positive, the second half are negative, and count from the opposite of the highest positive value back to 0. Hence, for a 3 digit integer, 7FF (2047) is the largest value you can have, 800 (-2047) is the smallest, and FFF = -1. These integers are measured from the center of the screen. What they correspond to I'm not entirely sure, but WW's sides measure positive and negative 205 from the middle. I suppose that it's feasible to assume they're the same units as in PSA, because 20.5 stage builder blocks seems a reasonable comparison.

If Brawlbox can edit these distances directly, I'm all for modding up a bunch of replacement pacs for the stages that need it.

Edit: I agree about partial rebuff to Kirby. Also agree on fixing Luigi.

 

[MK26]

i think its safe to assume they're the same units, WW's death boundaries are

(-170,180)		(170,180)





(-170,-104)		(170,-104)

by default

 

[Team Giza]

Agreed on both Kirby and Luigi. Mostly on Luigi since what needs to be fixed with him was unintentional to begin with.

 

[GHNeko]

That reminds me. Are we going to leave the ledge grab range as is?

Also, has anyone thought of implementing a less significant version of Melee's rolling edge guard? Like how in Melee, if you rolled back onto the stage from the ledge, the game thought you were still on the ledge until the animation was finished.

Many times have you tried to edgeguard someone and as you're in the middle of the rolling/get up animation from the ledge, they grab on even though you're still finishing the animation.

So I was thinking about a lesser version of Melee's version where its no where near as long, but long enough so that doesn't happen as often as it does in B+.

 

[JCaesar]

I thought that was one of the dumbest things in Melee. It meant you didn't have to actively edgeguard. If they were only just going to make it to the edge, all you had to do was grab the edge and press L and they had no chance of making it back. Now the edgeguarder has to at least time the edgehog or hit them back out. I think it's good the way it is.

 

[Glick]

That reminds me. Are we going to leave the ledge grab range as is?

Also, has anyone thought of implementing a less significant version of Melee's rolling edge guard? Like how in Melee, if you rolled back onto the stage from the ledge, the game thought you were still on the ledge until the animation was finished.

Many times have you tried to edgeguard someone and as you're in the middle of the rolling/get up animation from the ledge, they grab on even though you're still finishing the animation.

So I was thinking about a lesser version of Melee's version where its no where near as long, but long enough so that doesn't happen as often as it does in B+.

Let's leave this for project M.

I actually agree with the ledge grab thing. It's a little intense for some characters. Not the roll thing.

 

[Shell]

As far as I know P:M will be keeping the non-occupied-ledges-while-rolling-up, but we're almost done fixing ledge grab range to mirror melee's.

Talk to Doval or Eldrian if you'd like tips on this.

 

[goodoldganon]

I think adjusting some stage boundaries and lowering ledge grab range would go a long way to speeding up matches.

 

[Veril]

I'm fine with spending a little more time discussing stage boundaries, but I want everyone's character specific input by tonight, before 10pm ideally.

 

[GHNeko]

I thought that was one of the dumbest things in Melee. It meant you didn't have to actively edgeguard. If they were only just going to make it to the edge, all you had to do was grab the edge and press L and they had no chance of making it back. Now the edgeguarder has to at least time the edgehog or hit them back out. I think it's good the way it is.

Let's leave this for project M.

I actually agree with the ledge grab thing. It's a little intense for some characters. Not the roll thing.

I meant in a sense that to adjust the get up options so the ledge doesn't become avaliable while your in the middle of getting up.

Not like, "you're already rolled onto stage, but your opponent cant get the ledge."

More like "As long as some part of you is on the ledge, your opponent can't grab, however if you're on the stage, the ledge is free."

 

[Veril]

Yoshi's side-b jump refresh and resulting egg-stall. DISCUSS! This is one of the last completely unsolved problems. I don't want the options to be: remove the jump refresh or remove its cancel on collision or do nothing, but if no better ideas surface here those are the only choices. Cape has already played around with the move not being cancelable on collision and says it f***s up the use of this move onstage.

Again, tonight lets get these last character changes confirmed and move on to testing and stages.

 

[DarkDragoon]

Yoshi's side-b jump refresh and resulting egg-stall. DISCUSS! This is one of the last completely unsolved problems. I don't want the options to be: remove the jump refresh or remove its cancel on collision or do nothing, but if no better ideas surface here those are the only choices. Cape has already played around with the move not being cancelable on collision and says it f***s up the use of this move onstage.

Again, tonight lets get these last character changes confirmed and move on to testing and stages.

Well, if its an infinite you're worried about, a logical step to take, if you're avoiding removal, is a limit. Maybe 3 refreshes, then it doesn't work? Its not that hard to set flags on PSA to read it. Then Yoshi needs to return to the wait animation or something for it to reset.
-DD

 

[The Cape]

What about just making it go into regular stall? Makes the move a bit less silly overall and his recovery is just a bit too good.

 

[MK26]

Well, if its an infinite you're worried about, a logical step to take, if you're avoiding removal, is a limit. Maybe 3 refreshes, then it doesn't work? Its not that hard to set flags on PSA to read it. Then Yoshi needs to return to the wait animation or something for it to reset.
-DD

yeah, im partial to a limit of 2 refreshes until hit/ledgegrab/land - yoshi will never under any circumstances need more than 2 refreshes, ever. Hell, he'll almost never need 2 in the first place...

 

[VietGeek]

I would prefer to bump that down to just one refresh.

His DJ has super armor, he already has egg momentum which is already really good. If he preserves his double jump he will almost ALWAYS get back on stage anyway. More often than not, Yoshi will only get gimped off a footstool or by the player's own screw-up (like DJC on recovery). Not to mention he's ****ing fat. >_>

 

[goodoldganon]

If a limit is possible I don't see why there is a need for a discussion. 2 is more then Yoshi will ever need and is a very reasonable number.

EDIT: What's our opinion on the havok system and how it effects team matches. I have always felt team matchups have fallen by the wayside in the name of 1v1s but this seems like something worth debating since it only deals with teams (and I guess matches with the ICs in them...) I can't see any competitive reason to leave it in the game, but I just wanted to see what you guys thought.

 

[Isatis]

As time-consuming as adding sword glows to hitboxes are... not only did I add them, but I spent the last 3 hours experimenting on Sonic's usmash numbers.

The reason it effs up in low-weight classes was the fact that the smash move itself was sped up 2x in the last 16 frames, thus throwing off the knockback in general for that last 16 frames. It wasn't about raising SDI-ability in the move itself, however, since Sonic's usmash was apparently overlooked the past half year in previous builds apparently, this went largely un-noted until yami_sora brought it to my attention and I was able to experiment with this move more at Pound 4 itself against other smashers.

Not only do you notice characters (with DI) getting out of it real early on the first hit of Sonic's usmash (starting on frame 8, and since I couldn't get to a smashfest I couldn't ask a second person to help me in my endeavor), but those without DI can get out on the third hit of Sonic's usmash at 130%+ on Fox, 140%+ on Jiggs (weird), 120%+ on Mario (weirder), and 190%+ on Bowser. After experimenting with the Debug Pause and writing down some data, I found out why they were getting out.

As I said, it wasn't raising SDI that solved this, but here's Sonic's usmash now: the starting hit has two large hitboxes, followed by the multi-hit complex (the problem area) where it has zero base knockback and 100 (64 hex) knockback growth. The final hit, Ryoko's idea with changing it so it kills a bit earlier and starts combos as well, which largely agreed with Cape, myself, and the rest of the Sonic mains, did not affect this noted problem area at all.

What have I tried doing?
* Keeping KBG at 100 and raising SDI to 1x -- Fail: They still get out, but 15% higher (145% as opposed to 130%)
* Raising KBG from 100 to 150 at 0.8x SDI -- Fail: They still get out, but it actually KO'd them sideways instead of the top
* Raising KBG from 100 to 150 at 1.0x SDI -- Fail: Same as above
* Lowering KBG from 100 to 75 at 0.8x SDI -- Fail: They get out at earlier %'s
* Lowering KBG from 100 to 75 at 1.0x SDI -- Fail: It almost works, but they get out after the third hit

Raising KBG = Fatal KO from the multi-hit hitboxes which is not what anyone wants
Lowering KBG = lowering the damage % the character can actually get out of

Any other ideas? I'm fresh out as far as I can tell. And yes, I've tried experimenting with KBG like 50, 75, 85, 95, 100, 115, 125, 135, 150.

 

[leafgreen386]

Wait, isn't that weight dependent set knockback? How is it being based on percent at all? If it's using real growth for some reason, try just zeroing it out and using base.

 

[Veril]

I would prefer to bump that down to just one refresh.

I agree. 2 super-armor double jumps is pretty amazing. Anyone who gets footstooled twice in a recovery attempt should lose their stock imo.

The reason it effs up in low-weight classes was the fact that the smash move itself was sped up 2x in the last 16 frames, thus throwing off the knockback in general for that last 16 frames.

Bionic is too good.

Could we add in an IASA point 8 frames prior to the vBrawl animation ending or adjust the frame-speed mod? BKB, KBG, and SDIability clearly are not solving the problem as it is due to the speedup. Target the source of the problem...

 

[Yeroc]

I suggested PSAing the speed change in the IRC. We could do it with an embedded async timer in the loop, and removing one iteration to compensate. Just a thought, in an effort to keep the move feeling the same it does now, only working properly.

 

[Isatis]

Adding an IASA may not help any, especially considering I'm fixing why it's not connecting.

Trying leaf's suggestion now, then Yeroc's suggestion if that doesn't work.

 

[Veril]

11:55, I'll be writing up the final set of votes for character specific adjustments. The exact fixes don't need to be cemented, but we need to know what to focus on. Ex. we know Sonic's up-smash has to be fixed but not necessarily the best way to do so. Stage and general mechanics change discussion clearly is still ongoing, vibrant and necessary whereas there has been ample time to discuss the character specific stuff.

 

[Isatis]

Switching the BKB for the KBG didn't work, neither did raising or lowering the BKB (while KBG was kept at 0).

 

[lord karn]

As far as the Yoshi changes go, I think setting a limit on the refreshes is the best idea. However, yoshi is not broken so you should just set it to a number that would not ever be reasonably used.

 

[Veril]

ok, proposals sent out. Instead of abstaining this time, I want anyone who doesn't understand a proposal (not agree or disagree, just... not understand at all) to message me.

I don't understand the fusion glitch very well. http://www.youtube.com/watch?v=ZkHXHj4xvmI http://www.youtube.com/watch?v=OEoW3VZKQlU&NR=1 **** is clearly not ok to have in a finished set though.

 

[lord karn]

Just to let you know, THO is out of town so he probably won't be able to respond until like Monday, or something.

 

[Veril]

Just to let you know, THO is out of town so he probably won't be able to respond until like Monday, or something.

I was just going to ask about him. He needs to get involved here, its not like the sbr where... well...

 

[lord karn]

I was just going to ask about him. He needs to get involved here, its not like the sbr where... well...

I still talk to him irl about most of this stuff but he needs to get on. . .

 

[The Cape]

So the Yoshi side B would be set to be similar to Snake or Sonic upB. Where he can do anything but sideB?

 

[Revven]

Veril, what happens is that anytime you do Squall hammer and Nana is hit with a move like Falco's laser or MK's tornado or Pikachu's thunder jolt, they "fuse" together because of the hitlag of the attacks. Amazing Ampharos already sort of fixed this in his BBrawl thread, might want to look at it.

Edit: Also the more I think about fixed boundaries the more I realize that perhaps the boundaries for a lot of the stages in the game were made in mind with items being on, since items kill so crazy early in this game. A good example is to look at Smash 64, a lot of the boundaries for some of the stages have rather big boundaries (Peach's Castle, Saffron City, Sector Z, Dreamland, and Hyrule Castle all come to mind) however it is counter-measured by having huge hitstun and being able to still combo real well at higher %s. That game too had rather crazy early killing items.

So, I actually do agree with tweaking all the viable stages' boundaries so that people can't live above the 140%-145% mark unless you have really amazing DI.

 

[DarkDragoon]

Veril, what happens is that anytime you do Squall hammer and Nana is hit with a move like Falco's laser or MK's tornado or Pikachu's thunder jolt, they "fuse" together because of the hitlag of the attacks. Amazing Ampharos already sort of fixed this in his BBrawl thread, might want to look at it.

Edit: Also the more I think about fixed boundaries the more I realize that perhaps the boundaries for a lot of the stages in the game were made in mind with items being on, since items kill so crazy early in this game. A good example is to look at Smash 64, a lot of the boundaries for some of the stages have rather big boundaries (Peach's Castle, Saffron City, Sector Z, Dreamland, and Hyrule Castle all come to mind) however it is counter-measured by having huge hitstun and being able to still combo real well at higher %s. That game too had rather crazy early killing items.

So, I actually do agree with tweaking all the viable stages' boundaries so that people can't live above the 140%-145% mark unless you have really amazing DI.

Uh, well...how I've always killed with items is hit them offstage, then throw the item at them.

That usually kills every character under 100%...because items tend to have stupid good KB.

The boundaries are where we're used to them being, items or not. If you change them to reflect no items, then people will complain everything dies too early.

Although maybe I don't understand the point of what you're saying.

-DD