Balanced Brawl Standard Release

[Shadic]

AA: I know you had an attempt at fixing Temple to be something more viable in the past, I was wondering if you had happened to look at what I did for the stage? My post is here.

 

[Steeler]

aa and i are true buds

edit shadic i really like that temple you made

 

[IrohDW]

I'm not going to get into endless back and forth arguments on stuff. I posted my assessment of Din's Fire which you basically in a long way said you disagreed with. Fine, you disagree, and I didn't find your disagreement convincing (I also don't think Din's is as useless in singles as people say either; it's mediocre but not useless). Your post wasn't asking me anything; it was just raising an argument on a point I'd already gotten into, and I'm sorry but this 262 page thread means I have to just drop some of that. Din's Fire also already hits pretty hard so I'm not sure what kind of buff you could really want out of it. Altering the speed the projectile moves at would not only go against the aims of this project but would require direct hex editing of currently unknown parameters. Zelda's start-up and end-lag on the thing are already fairly small; speeding them up would be of almost no utility. There's nothing to be done if you don't like how Din's Fire is already, and it's not like it's Zelda's most important move anyway. Even if it actually were near-useless, it wouldn't make much sense to buff. Consider that King Dedede's Jet Hammer is actually pretty definitely near useless, and we haven't and probably aren't going to buff it. Characters should be mostly equal, not moves (though in terms of balance, Zelda is a special case anyway because she is bound to Sheik... meaning ideally she should be weaker than the other characters alone and just barely stronger than the others when used in a joint strategy). There is no compelling reason to buff Din's Fire; it doesn't make sense for Zelda as a character.

I gave cr4sh's post a quick response (something like 2 sentences) because his post was a very simple question. I try to answer very simple questions preferably with simple answers; I'm not perfect, but I do try. Others chose to carry on a mini-discussion on it... which is fine. I also have run into him in person before, and yes I am blatantly biased in replying to people from my own region with a small amount of higher priority than everyone else unless they post in here a lot and I can talk to them easily through other venues (as is the case with steeler). It has nothing to do with anything you're suggesting it does.

One of the major problems with Din's fire is that Zelda makes an animation after the player chooses where to make the explosion, but before the actual explosion is made. The frame window is large enough that it allows an opponent to know exactly when and where the explosion is going to be which makes it blockable on reaction. If this part of the move is speed up enough it won't be blockable on reaction anymore which would make the move much better without changing how it is used.

 

[A2ZOMG]

The real problem with Din's Fire is that it doesn't set up into anything for the most part. Forcing an airdodge or reaction of some sort is useful, except Zelda is rarely ever able to capitalize on that since it's juuuuust laggy enough, and Zelda is too slow. For the large part it doesn't stop people from approaching her and playing a slow, safe poke game that will wear her out.

Although on the flip side, Zelda's F-tilt did become a viable poke, which I would guess would make her significantly better than useless.

 

[ぱみゅ]

That's pretty Zelda's main problem. She cannot do many things to punish approaches unless the opponent seriously screws it up (which actually, happens sometimes).

Seen that way, Ftilt speedup is a very good solution, specially because it's a kill-combo setup (although, I still thinking it doesn't fit her playstyle).

Spoiler

(how many times i've pointed that?!)

BUT, now that makes her predictable. A safe option means that it will be the most used (if not the only one, due to the others are just too risky to even try them), and the opponent can easily think a way to counter. With that, now she's the same useless again!

 

[A2ZOMG]

Donkey Kong has only like one or two good poke options, and he's not useless.

 

[ぱみゅ]

-One of those pokes is aerial (Bair), that implies a poke PLUS spacing.
-EDIT: He has a lot more range....
-DK don't even baits approaches, so he can perform random pokes (which is not bad); but if the opponent know he's being baited, he'll know the next move, and think on something (although, it will work some few times).
-DK will survive MUCH more than Zelda (as M2K's height table said, Zelda's and Sheik's are pretty the same).

 

[JOE!]

Donkey Kong has only like one or two good poke options, and he's not useless.

hey, compared to zelda hes ready to kick some tail..

he's bigger, faster...and stronger too...

he's the first me *SHOT*

 

[Amazing Ampharos]

Zelda was never useless in the first place, and predictability is the woe of a player not a character.

A lot of people just don't think of all the options they have at any time with every character, really universal stuff. I'm not even talking about shielding or rolling or that. I'm talking about choosing where to stand and when to jump or whether to slowly walk forward or away; every character has a huge number of options just with that really simple stuff that a lot of players just don't appreciate. By just using this sort of thing, every character can bait pretty effectively; it's just all about player skill. More powerful characters who can still hit reasonably quickly (like not Warlock Punch but the speed of a typical smash is fine) get the relative most out of this sort of thing. Just kinda make a deceptive movement to bait an attack and punish the commitment with your own. Even jabs are frequently very unsafe on whiff...

I'm not saying that's all there is to Zelda or any other character, but I'm saying stuff like that exists and is useful to winning and is stuff that everyone should be using to some extent. It really fixed "predictability" problems to use good all around fundamentals like that.

With Zelda's ftilt, I'm not really sold on it being such a huge go-to option, but let's say the baseline strategy you're doing best with is poking with safe ftilts. Okay, that's not bad, but the opponent is likely shielding them and then improving their position to go on the attack. Well, what beats shielding? A dashgrab would be one solution. Zelda's dashgrab is particularly crummy; it's not something you use very often. However, if the opponent throws up his shield, dashgrab will work great! Zelda's throws are actually not bad either so the opponent isn't going to want to let this happen very often. Of course, their efforts to avoid only let you use more ftilt with success and keep them pinned down.

You have other tricks too beyond that simple mix-up (while that simple mix-up is good, it only gets you so far). If they have a lot shield, dtilt is likely to shieldstab. If they angle their shield low, run up up smash is going to shieldstab (and that one really hurts). So now your safe poke has led to another mix-up with very uneven rewards. Dtilt gets you a small gain (though as I recall it can trip), and usmash is just really strong. If their shield is really low but you are further away, fsmash can have the "let me shieldstab you or I'll just break the thing" effect, always an important thing to have in your arsenal when you're shield pressuring (and if you are relying on safe pokes, you had better be thinking about shield pressure).

Then of course you have the bold option if they keep throwing up shield and you really aren't close and don't think a risk is worth taking. Just throw a Din's Fire. One might say it's useless because you'll almost surely not hit, but think about it. What do you lose? If you are smart about it, you lose just about nothing. You keep them on their toes, possibly do a little extra shield damage, and make yourself more unpredictable at nearly zero cost. Some people have this idea of always using moves with the goal to hit, but just throwing something out you know isn't going to hit but isn't going to be punished either is a frequently good idea.

Din's Fire itself, to move back to that, has other uses. In terms of actually hitting with it in singles, I think of it as an anti-commitment move. Basically, the opponent really doesn't want to do anything that can be punished by Din's Fire. Some recoveries are a lot trickier if Zelda is putting a Din's out there in a smart way; just imagine recovering as Link with a Din's Fire ready to explode on top of the best place to Spin Attack. Stuff like using plunging dairs for mobility is scarier than usual against Zelda because that can entail some big commitment, and she can hit in places most characters have to take far more time to hit with Din's Fire. All around, this is probably less than what other projectiles can do; it hits harder than average, but many others can do this sort of job, and usually they can do many other jobs. However, Zelda is no projectile spamming character, and it's important to remember that what good this does for her still exists no matter how many other, better projectiles are in the game. Zelda would definitely be a less imposing character if Din's Fire simply were removed from her moveset; it would just be safer to do random stuff against her.

 

[ぱみゅ]

I won't debate that, it's pretty a summary of Zelda's DF strategy.

Any Zelda player knows that DF has a lot of good things, mainly because it punishes virtually any recovery and pressures. They also know that it obviously won't hit everytime (and actually, I think no proyectile is supposed to, if the opponent knows the matchup), and has find other usage for the attack.

Anyways, the problem with Din's Fire is baiting: A move that forces the opponent to airdodge is good, but if you can't perform nothing to punish that because of your lag, and your opponent succeed on his apporach attempt, THAT makes it unworthy.

 

[A2ZOMG]

Zelda was never useless in the first place, and predictability is the woe of a player not a character.

I should state however:

Predictability is woe of BOTH the player and character, since several characters are reliant on specific options for dealing with common situations due to either poor hitbox placement, or terrible speed. Good mobility by itself mindgames people, as demonstrated by say...Wario's broken crossover game that is almost impossible to observe on reaction. I wouldn't say it necessarily takes much player skill for Wario to just do an aerial in front of your opponent and then just arbitrarily decide to move behind them right as the aerial is ending. It's just the character itself and its options are very hard to read.

Even jabs are frequently very unsafe on whiff...

I think you meant Ganon's Jab right? I mean if you're just Jabbing to scout your opponent's unpredictable movements, you are extremely unlikely to get punished on reaction unless you're Ganon basically. Oh yeah, I mean of course, most characters have options that outspace or outprioritize Jabs in general, but if you just single Jab at someone who is camping with run speed like Sheik, that's not particularly unsafe.

Din's Fire itself, to move back to that, has other uses. In terms of actually hitting with it in singles, I think of it as an anti-commitment move. Basically, the opponent really doesn't want to do anything that can be punished by Din's Fire. Some recoveries are a lot trickier if Zelda is putting a Din's out there in a smart way; just imagine recovering as Link with a Din's Fire ready to explode on top of the best place to Spin Attack. Stuff like using plunging dairs for mobility is scarier than usual against Zelda because that can entail some big commitment, and she can hit in places most characters have to take far more time to hit with Din's Fire. All around, this is probably less than what other projectiles can do; it hits harder than average, but many others can do this sort of job, and usually they can do many other jobs. However, Zelda is no projectile spamming character, and it's important to remember that what good this does for her still exists no matter how many other, better projectiles are in the game. Zelda would definitely be a less imposing character if Din's Fire simply were removed from her moveset; it would just be safer to do random stuff against her.

Quite ironically enough, Din's Fire is really good against Metaknight's recovery, since Metaknight doesn't clash hits with most of his moves, and because it stops him from gliding with impunity.

 

[NovaRyumaru]

One of the major problems with Din's fire is that Zelda makes an animation after the player chooses where to make the explosion, but before the actual explosion is made. The frame window is large enough that it allows an opponent to know exactly when and where the explosion is going to be which makes it blockable on reaction. If this part of the move is speed up enough it won't be blockable on reaction anymore which would make the move much better without changing how it is used.

I agree with this, if you could alter the timign somewhat so Zelda will use the animation closer so Din's Fire explodes a little faster en let go it would remedy the fact it's so readable so you'd have to rely more on prediction as opposed to "Oh, she's dancing so it's about to explode."

 

[rPSIvysaur]

Hey guys, I've been looking into some Jab lock stuff and I found away to keep the forced get-up and remove the infinite part. This could help characters like Link and Lucas who use it as a large part of the damage dealing game and killing game (arrow lock combos and Tyr combos) without it "comboing" into itself.

What do you think AA, if we can just get rid of the infinite part and make it just a combo part, it would definitely benefit some lower-tier characters since some of them got their kill set-ups taken away. (oh and BTW, the Lucas mains don't play BBrawl b/c there is not jab lock )

 

[Amazing Ampharos]

You know, saying what you did would be infinitely more useful than describing its effects... Long combos across the stage (especially of the infinite nature as in jab locks) are not okay. Just imagine every match is on a hybrid Luigi's Mansion/Mario Circuit where setting up a jab lock is easy and they're always a sure thing kill. Short combos that don't cover a lot of ground (like an old jab lock set-up into a single jab combo/one other move?) aren't necessarily a problem but would have to be specifically balance tested.

 

[rPSIvysaur]

What it is you take the flopping animation from getting hit and you add some:
If Then's

and what it does is you have a variable that is set everytime you go into flopping animation which can be combo'd with, but if you do it again the flopping animation is sped up so it's not a lock. Then, once they get-up the varible is cleared so if they miss a tech again, it can be repeated. (and you also have the footstool problem solved, so all combo's would be subject to teching thus making infinites escapable) This let's the move combo into others if they miss a tech, but it cannot combo into itself.

 

[Amazing Ampharos]

This has some disadvantages and at least one misunderstanding. Allow me to explain.

The disadvantage is that you are unclear on where you're adding this code, but either way is potentially a problem. Both ways we need a free bit variable (do we have one that's universally free on every character? Feel free to name off all the free variables, bit and otherwise, you know of since that could be helpful in many ways). If you're adding it to every character, that increases the file size of every .pac by a fairly non-trivial amount probably; this could end up making characters close to the limit go over and either way limits our ability to do other stuff within those .pacs. If you're doing it via a fighter.pac edit, well, that doesn't have that issue but is not exactly easy to make; I confess I've never made one, and the process isn't easy as far as I can tell. You need to find where fighter.pac maps to memory (which I don't know), trace out a specific place to insert code, replace it with a goto (you're writing all this as a .gct style code so you are basically typing out hex stuff that corresponds to the human readable PSA logic), point it to some free region of memory (hypothetically we'd use the region of memory that greater than 256 line code files usually use... since Bbrawl is going to be under 256 lines with the next release), and then write your new code. That's non-trivial, and it's sounding like what you have done is a thought experiment and not an implementation so maybe you don't realize how tricky the implementation can be. Also, having a complete set of circumstances to clear that variable is probably non-trivial too. You would need to insert a clear function in every animation you want to clear the variable... which could be quite a lot.

The misconception comes to footstooling. Footstool issues and jab locks are totally independent, and they're addressed as such in Bbrawl. A jab lock basically interrupt a normal "slamming into the ground" that you could tech with a jab and then gets the other guy stuck flopping. A footstool gimmick involves doing a footstool on an aerial opponent (important note: all characters under the "stun" effect from Zero Suit Samus count as airborne) low enough to the ground that they slam into the ground while in the footstool falling state. This causes them to go to a unique hitting the ground animation that offers no chance to tech (and R.O.B. has an especially bad animation here). It's completely independent from jab locks mechanically, and Bbrawl addressed it separately by using a conditional action modifier to change the "footstool fall" to "footstool land' animation transition to a "footstool fall" to "hard landing (from fastfall)" transition. Originally I wanted to make it a normal landing so it could be teched, but this caused bugs with Zero Suit Samus's stun that were completely unacceptable so I went with the current and bug-free implementation.

I actually haven't implemented any of the universal stuff via .pacs or new methods at all yet. The current internal build of Bbrawl has no hitbox or throw modifier (those codes are now obsolete to us), but it still has small frame speed and conditional modifiers that I hope to remove from the final release. Here are the codes:

Frame speed:

065A9400 00000020
0100003B 3FAAAAAB
FF000040 3FAAAAAB
FF000041 3FD55555
FF0E0054 40A00000


Conditional:

065A9128 00000010
FF000071 004A0016
FF00008D 008A008E


To document those for non-code junkies...

The first lines of both are basically headers that tell the larger engine codes that data is going to follow. Feel free to ignore them.

The next three lines of the frame speed all address grab breaks. The one that starts with 01 is the speed up to Donkey Kong's grab release as the grabber (Donkey Kong is character 01 internally; that's not the first one since 00 Mario exists). The next two are ground break universal speed-up and jump break universal speed-up respectively (FF in these engines means it applies to all characters). The final line in frame speed is the jab lock fix; it speeds up animation 54h on frame 0Eh by a factor of 3 which prevents jab locks.

The conditionals cover two cases. The first is a fix to banana locks (if you're sitting on the ground in a tripped state, which is different from the initial tripping state, and are inflicted with a "begin to forcibly trip as in hit by a move" state, you do a get up from trip animation instead of being tripped again). The second is the fix to footstool abuse which I described somewhat more at length above.

I want to move these to better implementation methods, and I'm not wholly opposed to acceptable changes to behavior that accompany (the current behavior is simply what was both acceptable and implementable). However, do understand this is non-trivial, and I hope there's an appreciation that on all accounts the current behavior is much desirable to the original game's behavior (jab locks, grab release chaingrabs, banana locks, and footstool abuse are seriously stupid no matter how much your character benefits from it... or is really hurt by other stuff here as is the case with Lucas!).

 

[Eldiran]

Frame speed:

065A9400 00000020
0100003B 3FAAAAAB
FF000040 3FAAAAAB
FF000041 3FD55555
FF0E0054 40A00000


Conditional:

065A9128 00000010
FF000071 004A0016
FF00008D 008A008E

I want to move these to better implementation methods, and I'm not wholly opposed to acceptable changes to behavior that accompany (the current behavior is simply what was both acceptable and implementable). However, do understand this is non-trivial, and I hope there's an appreciation that on all accounts the current behavior is much desirable to the original game's behavior (jab locks, grab release chaingrabs, banana locks, and footstool abuse are seriously stupid no matter how much your character benefits from it... or is really hurt by other stuff here as is the case with Lucas!).

A code that short actually seems like a great implementation to me! Maybe even better than modifying any .pac. Are there (aside from the normal/heavy landing thing) unwanted implications in the above code, or are we just trying to move away from codes in general?

 

[rPSIvysaur]

This has some disadvantages and at least one misunderstanding. Allow me to explain.

The disadvantage is that you are unclear on where you're adding this code, but either way is potentially a problem. Both ways we need a free bit variable (do we have one that's universally free on every character? Feel free to name off all the free variables, bit and otherwise, you know of since that could be helpful in many ways). If you're adding it to every character, that increases the file size of every .pac by a fairly non-trivial amount probably; this could end up making characters close to the limit go over and either way limits our ability to do other stuff within those .pacs. If you're doing it via a fighter.pac edit, well, that doesn't have that issue but is not exactly easy to make; I confess I've never made one, and the process isn't easy as far as I can tell. You need to find where fighter.pac maps to memory (which I don't know), trace out a specific place to insert code, replace it with a goto (you're writing all this as a .gct style code so you are basically typing out hex stuff that corresponds to the human readable PSA logic), point it to some free region of memory (hypothetically we'd use the region of memory that greater than 256 line code files usually use... since Bbrawl is going to be under 256 lines with the next release), and then write your new code. That's non-trivial, and it's sounding like what you have done is a thought experiment and not an implementation so maybe you don't realize how tricky the implementation can be. Also, having a complete set of circumstances to clear that variable is probably non-trivial too. You would need to insert a clear function in every animation you want to clear the variable... which could be quite a lot.

The misconception comes to footstooling. Footstool issues and jab locks are totally independent, and they're addressed as such in Bbrawl. A jab lock basically interrupt a normal "slamming into the ground" that you could tech with a jab and then gets the other guy stuck flopping. A footstool gimmick involves doing a footstool on an aerial opponent (important note: all characters under the "stun" effect from Zero Suit Samus count as airborne) low enough to the ground that they slam into the ground while in the footstool falling state. This causes them to go to a unique hitting the ground animation that offers no chance to tech (and R.O.B. has an especially bad animation here). It's completely independent from jab locks mechanically, and Bbrawl addressed it separately by using a conditional action modifier to change the "footstool fall" to "footstool land' animation transition to a "footstool fall" to "hard landing (from fastfall)" transition. Originally I wanted to make it a normal landing so it could be teched, but this caused bugs with Zero Suit Samus's stun that were completely unacceptable so I went with the current and bug-free implementation.

I actually haven't implemented any of the universal stuff via .pacs or new methods at all yet. The current internal build of Bbrawl has no hitbox or throw modifier (those codes are now obsolete to us), but it still has small frame speed and conditional modifiers that I hope to remove from the final release. Here are the codes:

Frame speed:

065A9400 00000020
0100003B 3FAAAAAB
FF000040 3FAAAAAB
FF000041 3FD55555
FF0E0054 40A00000


Conditional:

065A9128 00000010
FF000071 004A0016
FF00008D 008A008E


To document those for non-code junkies...

The first lines of both are basically headers that tell the larger engine codes that data is going to follow. Feel free to ignore them.

The next three lines of the frame speed all address grab breaks. The one that starts with 01 is the speed up to Donkey Kong's grab release as the grabber (Donkey Kong is character 01 internally; that's not the first one since 00 Mario exists). The next two are ground break universal speed-up and jump break universal speed-up respectively (FF in these engines means it applies to all characters). The final line in frame speed is the jab lock fix; it speeds up animation 54h on frame 0Eh by a factor of 3 which prevents jab locks.

The conditionals cover two cases. The first is a fix to banana locks (if you're sitting on the ground in a tripped state, which is different from the initial tripping state, and are inflicted with a "begin to forcibly trip as in hit by a move" state, you do a get up from trip animation instead of being tripped again). The second is the fix to footstool abuse which I described somewhat more at length above.

I want to move these to better implementation methods, and I'm not wholly opposed to acceptable changes to behavior that accompany (the current behavior is simply what was both acceptable and implementable). However, do understand this is non-trivial, and I hope there's an appreciation that on all accounts the current behavior is much desirable to the original game's behavior (jab locks, grab release chaingrabs, banana locks, and footstool abuse are seriously stupid no matter how much your character benefits from it... or is really hurt by other stuff here as is the case with Lucas!).

Yeah, I added the code directly to the .pac, but it really just increases it trivialy seeing that it only affects four parts of the .pac (and maybe PW might help with the file size thing in the future, but there are only a few characters that are going to have file size issues) It worked an all forms of the lock were gone and is not unescabable in anyway and only works to combo (much like the new Bananas).

Also, Set Bit Variable= Runtime Longterm, Float, #100 is a universally free one IIRC (it's the one I used)

 

[prOAPC]

i have already tried to change their mind Mike, hope you have some better luck
and lol at "Tyr Combo"

 

[Amazing Ampharos]

A code that short actually seems like a great implementation to me! Maybe even better than modifying any .pac. Are there (aside from the normal/heavy landing thing) unwanted implications in the above code, or are we just trying to move away from codes in general?

Oh, if that was all of it it would be great, but I suppose I let it go without saying that the corresponding engines were still in:

Frame Speed Mod Engine

C2766C20 00000012
3C008180 807D0008
8063FFFC 7C030000
4080000C 80630030
48000008 386000FF
809D0014 C0240040
FC40081E 81240058
61298000 D8410008
8001000C 80BD007C
80A50038 38C200D8
84E60008 2C070000
41820038 7CE8C671
41A0000C 7C081800
4082FFE8 54E8863E
7C004000 41A0FFDC
54E8043E 7C082800
4182000C 7C084800
4082FFC8 C0060004
D01F0010 00000000
C2766FB8 00000003
2C1D0001 4182000C
C0230010 48000008
C02283C8 00000000


Conditional Action Modifier Engine

C277F780 0000000E
2C030000 41820060
3C008180 80BF0008
80A5FFFC 7C050000
4080004C 80A50030
80DE0038 38E2FE00
85070008 7D09C671
41820034 2C09FFFF
41A2000C 7C092800
4082FFE8 5509043E
7C093000 4082FFDC
81070004 5509843E
7C09E000 4082FFCC
551C043E 60000000
939E0038 00000000


The frame speed engine causes freezing with at least Captain Falcon's Final Smash at that, and it breaks the timer item. I want the next release of Bbrawl to have zero item related bugs.

Also, oh, you really did it rocket PSI. Hmm, could you link to such a .pac if you've made it? Just throw it up on filefront or something. It will be several hours before I look into it (I work in an hour and a half, not enough time to do real coding), but it would be helpful. If it really works out, it's acceptable to me.

 

[Eldiran]

Oh, right. :/ You'd think I'd have remembered how big those codes actually were, after having seen 'em around so much. It would certainly be very nice to eliminate the timer and Final Smash bugs, so I can definitely see doing away with those.

After that is fixed, does that mean BBrawl will be totally bug-free?

 

[rPSIvysaur]

Oh, if that was all of it it would be great, but I suppose I let it go without saying that the corresponding engines were still in:

Frame Speed Mod Engine

C2766C20 00000012
3C008180 807D0008
8063FFFC 7C030000
4080000C 80630030
48000008 386000FF
809D0014 C0240040
FC40081E 81240058
61298000 D8410008
8001000C 80BD007C
80A50038 38C200D8
84E60008 2C070000
41820038 7CE8C671
41A0000C 7C081800
4082FFE8 54E8863E
7C004000 41A0FFDC
54E8043E 7C082800
4182000C 7C084800
4082FFC8 C0060004
D01F0010 00000000
C2766FB8 00000003
2C1D0001 4182000C
C0230010 48000008
C02283C8 00000000


Conditional Action Modifier Engine

C277F780 0000000E
2C030000 41820060
3C008180 80BF0008
80A5FFFC 7C050000
4080004C 80A50030
80DE0038 38E2FE00
85070008 7D09C671
41820034 2C09FFFF
41A2000C 7C092800
4082FFE8 5509043E
7C093000 4082FFDC
81070004 5509843E
7C09E000 4082FFCC
551C043E 60000000
939E0038 00000000


The frame speed engine causes freezing with at least Captain Falcon's Final Smash at that, and it breaks the timer item. I want the next release of Bbrawl to have zero item related bugs.

Also, oh, you really did it rocket PSI. Hmm, could you link to such a .pac if you've made it? Just throw it up on filefront or something. It will be several hours before I look into it (I work in an hour and a half, not enough time to do real coding), but it would be helpful. If it really works out, it's acceptable to me.

Well duh I did it. I wouldn't post it in here if I hadn't already tried it. I only have it applied to Lucas to test if it would work though. I'm in the library right now so I'll put the DL when I get home.

 

[Amazing Ampharos]

Well duh I did it. I wouldn't post it in here if I hadn't already tried it. I only have it applied to Lucas to test if it would work though. I'm in the library right now so I'll put the DL when I get home.

Okay, sorry it's just that some people post theory stuff and aren't clear about it being just theory and I am overly suspicious. Sounds good; I appreciate the effort and possibly the contribution.

Oh, right. :/ You'd think I'd have remembered how big those codes actually were, after having seen 'em around so much. It would certainly be very nice to eliminate the timer and Final Smash bugs, so I can definitely see doing away with those.

After that is fixed, does that mean BBrawl will be totally bug-free?

Well, for one, you have to remember bug-free is in the context of the original game. This doesn't address bugs like IDC or Sheik's chain glitch which are Sakurai's bugs and not ours (though if I could figure them out, I'd certainly like to address them!).

For two, there would be one remaining bug, and it's one I really want to fix if I can. The code that changes the speed of stages isn't one I've found a way to remove (though I have been able to remove the death boundary code via stage .pacs). This code causes stages that are ordinarily frozen during character intros to progress during them. The only stages like that, to my knowledge, are Rumble Falls and Halberd. On Rumble Falls, this causes some characters to spawn in the air which is very bad if Pokemon Trainer is the one doing that (he airspawns in t-pose), and on Halberd it dramatically reduces the duration of the starting area before the ship launches (though it causes no PT issues).

---

EDIT NOTE

Does anyone know what character is closest to the PSA size limit? I seem to recall it being either Samus, Zero Suit Samus, or Pit, but I don't remember which one is the absolute closest. When I test out .pac by .pac additions, I would like to do all testing on whichever character is going to be the biggest problem.

 

[Eldiran]

Well, for one, you have to remember bug-free is in the context of the original game. This doesn't address bugs like IDC or Sheik's chain glitch which are Sakurai's bugs and not ours (though if I could figure them out, I'd certainly like to address them!).

For two, there would be one remaining bug, and it's one I really want to fix if I can. The code that changes the speed of stages isn't one I've found a way to remove (though I have been able to remove the death boundary code via stage .pacs). This code causes stages that are ordinarily frozen during character intros to progress during them. The only stages like that, to my knowledge, are Rumble Falls and Halberd. On Rumble Falls, this causes some characters to spawn in the air which is very bad if Pokemon Trainer is the one doing that (he airspawns in t-pose), and on Halberd it dramatically reduces the duration of the starting area before the ship launches (though it causes no PT issues).

---

EDIT NOTE

Does anyone know what character is closest to the PSA size limit? I seem to recall it being either Samus, Zero Suit Samus, or Pit, but I don't remember which one is the absolute closest. When I test out .pac by .pac additions, I would like to do all testing on whichever character is going to be the biggest problem.

True that. I bet we might find a way to fix the bugs with Shiek and MK by editing the .pacs in PSA. In fact, I bet you could fix the infinite cape by simply putting a Change Action Requirement: Button Pressed: (appropriate button) in the right place. I don't recall the exact execution of the infinite cape, though, so I might be a bit off.

If we do get Rumble Falls to a proper counterpick, then a temporary solution could be to edit the spawn points in a way that fixes the problem.

As for character size... I've heard the most complaints about Samus and ZSS, and have heard rumors that their limit is 7 Kb extra. Not the most solid info though.

 

[rPSIvysaur]

DL for Lucas .pac which has the jab lock effect I told you about AA:
http://www.mediafire.com/?i3yg42tjnej

It only applies to Lucas for right now so try to Jab Lock against a Lucas.

 

[Big O]

Hey guys, I've been looking into some Jab lock stuff and I found away to keep the forced get-up and remove the infinite part. This could help characters like Link and Lucas who use it as a large part of the damage dealing game and killing game (arrow lock combos and Tyr combos) without it "comboing" into itself.

What do you think AA, if we can just get rid of the infinite part and make it just a combo part, it would definitely benefit some lower-tier characters since some of them got their kill set-ups taken away. (oh and BTW, the Lucas mains don't play BBrawl b/c there is not jab lock )

All you have to do to make Lucas Dtilt force get-ups is to change the angle back to the old one. Forced get-ups were never taken out. Only the flopping animation was sped up.

 

[rPSIvysaur]

All you have to do to make Lucas Dtilt force get-ups is to change the angle back to the old one. Forced get-ups were never taken out. Only the flopping animation was sped up.

What I really meant was having the flopping animations slowed down so it can actually combo into stuff like F-smash and U-smash >.>, but yes, the angle should be changed back if we implement this.

 

[IrohDW]

Won't changing the angle of Lucas's dtilt get rid of the extra frame advantage he currently has in bbrawl?

 

[Mit]

Just something I was curious of, have you ever commented about the programming error from Ganondorf's fair?

That seems like something that, if fixed, would fit with the spirit of this project. It's something that was actually intended to be in the game, and then was messed up by an error. It really looks quite ridiculous when Ganondorf is almost fully returned to his normal air pose after using fair, only to hit the ground a split-second too early and endure FULL landing lag, returning to his fair-looking landing position.

If fixed, it'd have a more natural landing comparable to every other character's typical aerials, and should actually help out Ganon's aerial game. Of course, if it makes the move a lot more useful, it might need some minor nerfs due to the less risk involved (although really, it was originally intended to do that same amount of damage with the autocancel properties), but that's something that I'd love to see implemented, especially since it was the original programmers' intention to have it behave that way.

 

[Eldiran]

Just something I was curious of, have you ever commented about the programming error from Ganondorf's fair?

That seems like something that, if fixed, would fit with the spirit of this project. It's something that was actually intended to be in the game, and then was messed up by an error. It really looks quite ridiculous when Ganondorf is almost fully returned to his normal air pose after using fair, only to hit the ground a split-second too early and endure FULL landing lag, returning to his fair-looking landing position.

If fixed, it'd have a more natural landing comparable to every other character's typical aerials, and should actually help out Ganon's aerial game. Of course, if it makes the move a lot more useful, it might need some minor nerfs due to the less risk involved (although really, it was originally intended to do that same amount of damage with the autocancel properties), but that's something that I'd love to see implemented, especially since it was the original programmers' intention to have it behave that way.

Unfortunately, that would equate to a huge timing change and a correspondingly large playstyle change, which may not fit well with this project's goals. Even though it'd work great, make sense, and help with balance, I hope it isn't changed, because after playing with that change, the next time I pick up vBrawl Ganon I'll suck because I'll keep trying to Fair when it's not safe.

Not that I don't agree with your points and everything, Mit, I'm pretty much just throwing in my vote against the change.

 

[rPSIvysaur]

Won't changing the angle of Lucas's dtilt get rid of the extra frame advantage he currently has in bbrawl?

Actual Lucas mains shouldn't be using D-tilt unless it's in a d-tilt lock or tripped, so we really don't mind the lack of frame advantage. All we really care about is the d-tilt lock combos, that's why alot of Lucas mains don't play BBrawl.

 

[prOAPC]

yeah, that frame advantage is a nice addition, jab cancel combos are great, but if i have to choose between dtilt lock and jab to dtilt, i'd choose the first one

but, if it is possible, give Lucas both techs lol

 

[MK26]

Unfortunately, that would equate to a huge timing change and a correspondingly large playstyle change, which may not fit well with this project's goals. Even though it'd work great, make sense, and help with balance, I hope it isn't changed, because after playing with that change, the next time I pick up vBrawl Ganon I'll suck because I'll keep trying to Fair when it's not safe.

Not that I don't agree with your points and everything, Mit, I'm pretty much just throwing in my vote against the change.

iirc, there's a synchronous timer at the end of the script for ganon's fair at some ridiculous number like 40 frames, preventing any possibility of an autocancel. I recall figuring out that changing the 'synchronous' to 'asynchronous' and leaving the number value there would match up perfectly to the animation, causeing autocancels at teh right time...

As for disliking the v/BGanon split, might i ask how you can possibly play vYoshi without side-b suiciding?

and if anybody cares, the same thing occurs with DK's fair as well. Same fix, too.

 

[Eldiran]

As for disliking the v/BGanon split, might i ask how you can possibly play vYoshi without side-b suiciding?

No, see, that's totally different. The difference is... I don't play as Yoshi.

But to be more serious... I can see the similarity. I'm sure training yourself to side+B to save yourself from death would really suck in vBrawl, where it instead guarantees it.

I honestly dislike the nature of that side+B change; it's more of a necessary evil, I suppose. However, at the very least, the difference between freefalling and not freefalling is distinct and clear, and you need only retrain your reflexes for the most part.

If Fair became a viable approach, I'd have to rework my intuitive understanding of approaching with Ganon... if that makes any sense. It'd be sort of akin to making Falcon's knee autocancel better. Maybe.

Anyway, I can't explain it well enough right now so I'll drop it. But suffice to say, it's a drastic gameplay change and thus I endorse finding alternate solutions. (Even in spite of the fact that if it were changed, I would happily play with it and think it was awesome. I would just know in the back of my mind that it is making me worse at vBrawl.)

 

[A2ZOMG]

The timer on Ganon's autocanceled F-air requires a buffered fullhop, so it's still largely useless, even though I believe it allows the option of a frame perfect execution of the Flight of Ganon AT.

 

[Linkshot]

Except, in the end, the goal of this project is to be akin to a patch to vBrawl, meaning that you would not have to ever go back to vBrawl, since this is its replacement.

All coding errors should be fixed. That's what patching is for.

 

[Eldiran]

Except, in the end, the goal of this project is to be akin to a patch to vBrawl, meaning that you would not have to ever go back to vBrawl, since this is its replacement.

All coding errors should be fixed. That's what patching is for.

You have a point there. As a pessimist, I treat it as a substitute that lets me enjoy playing Brawl in unofficial settings. It would be delightful if it were made an official replacement though, naturally.

Aside from officialness, I also want to able to perform well if I ever play some vBrawlers for fun.

Anyway, intentions aside, there is this claim for BBrawl's goals on the OP:

In other words, no one should have any problem moving between standard Brawl and Balanced Brawl. There should be nothing to learn, relearn, or unlearn as you play one or the other.

I don't think BBrawl has strictly lived up to having "nothing" to (re/un)learn, but the closer to nothing, the better.

 

[A2ZOMG]

I don't think BBrawl has strictly lived up to having "nothing" to (re/un)learn, but the closer to nothing, the better.

My personal opinion is that the things that require the most relearning are KO percents. Even though KO percents are fundamentally not the most important issue when it comes to character balance (until you talk about characters that already have the right tools for being competitive), they are by far one of the most important factors for playstyle due to how huge stale moves is in Brawl.

As for ZSS, I remember hearing that her Dash attack supposedly combos into itself a lot and could do that to very high damages. Does someone know the specific details about that move?

 

[Amazing Ampharos]

I'm looking at Rocket's code, and I have some real doubts just looking at it.

For one, you use set bit variable on a float. That's probably a no-no itself.

For two, if the flop animation is terminated by any method other than standing up, the variable doesn't clear. If I do something like set up for a jab lock but then hit you with an attack that launches you, the bit will be set until I repeat the set up again and let you out for free which would be non-intuitive to say the least.

For three, code doesn't necessarily execute in order in PSA. It may set that to true and then do the if check despite the order the code is writen in.

Regardless though, I'm going to test it in-game and report my results.

(Also, since when does Lucas's usmash have full invincibility on start-up? If I'm reading PSA right, it should be f1 invincible! I'll be testing this too...)

A casual inspection indicates that issues one and three aren't problems (though I think changing the variable from a float to a bit can only improve the code, just less memory it's hungry for), but issue 2 sure is and in spades. I don't think it's worth the non-intuitive mechanics to have things as suggested. Anytime you hit someone off lying on the ground hard enough to launch them, you cause the jab lock potential to change. If they get up in a way other than standing up (rolling, get-up attack), you have the same issue. Worst of all, if you force them to get up via hitting them late, the jab lock potential doesn't reset! It only resets if they stand up either via normal stand-up on their own (by tapping up) or by just lying there long enough for the character to do it automatically. At the very least, a reset to this variable needs to be added in such a way to cover all that which is starting to get substantial. I really, really suck at executing jab locks too (since G&W doesn't have one) so it's obnoxious for me to test directly...

I want to stress any sort of lock is not in the game regardless. Locks are bad!

However, for the even additional code (and how much does it take to cover all cases?), what is the real gain here? You lose a few gimmicky tricks that honestly you should not be landing anyway. It would seem easier and more intuitive to design these characters to not rely on these gimmicks, especially when they're largely seing substantial reworking on their behalf to make them safe from other gimmicks. Seriously, the extent to which Lucas is destroyed by grab release by so many characters, not just Marth, is really probably misunderstood by Lucas players (Lucas actually has it substantially worse than Ness because his jump break is bad, unlike with Ness); people don't exploit this stuff because it's not worth learning since Lucas is bad anyway, but really the extent to which he's infinitely more viable with it gone is really hard to understate.

Also, I did check it. Lucas's usmash really is f1 invincible! Lucas's usmash is invincible f1-4, but it doesn't hit until f28 which is kinda a killjoy. Still, it's a f1 invincible move you can use straight OoS; I'm sure there are situations it would come in handy. That it has this property is also really funny.

Also, fun fact, Ivysaur's Bullet Seed is also f1 invincible.

 

[ぱみゅ]

Any change implies a relearn... Most angles, knockbacks, and general changes means you're playing something (slighlty) different.

MU's now are being relearned; not to do CGs, infinites, nor locks implies changes. Some more than others, but changes anyways...