• Welcome to Smashboards, the world's largest Super Smash Brothers community! Over 250,000 Smash Bros. fans from around the world have come to discuss these great games in over 19 million posts!

    You are currently viewing our boards as a visitor. Click here to sign up right now and start on your path in the Smash community!

Updated Engine Codes

Almas

Smash Lord
Joined
Jul 6, 2008
Messages
1,588
Okay, I still need to do the Framespeed and Hitbox Modifier codes, but I thought I'd let you know that some reformatting would be nice. I've added a few features to the Launch/Grav codes that hopefully you'll find useful for when I release them (still have to fix bugs but I'd rather do that once I have a full set of betas).

  • I'd like you to change it so that in the 16 float values used for assigning fractions to multiply things by, "0" corresponds to float 1 (3F800000). It's mainly for convenience for people who will want to use these codes when the clone engine is released.
  • The new system doesn't require the two-digit character ID at the start of the 8 digits which describe the features. Its new format will be ABCDEFGH XXXXXXXX 00000000 00000000, where A-H are float multipliers, and Xs are the character's momentum (as a 32-bit float). The 0s are used by the system for the Frame Speed and Hitbox codes as an index. This list will be arranged in character order. Missing IDs will be padded with 0s. The ID 0x10 must remain unused.
  • As part of the Launch Code you'll be able to choose which values are assigned to which location using a new code. So for ABCDEFGH, A would always be overall grav, but the role of B-H (e.g. if they modify DGrav, FF etc.) would be done by another easy-to-use code.
  • As part of the Grav code, you'll be able to add specific gravity to different animations using another data code, which includes a wildcard for character choice.
  • Frame Speed Modifications must be arranged by character, than arranged by animation ID within each character. I realised I could use a much more efficient searching algorithm, allowing limitless animation changes rather than 80-90, but it throws on this extra restriction.
  • For the Float Values of the Animation changes: change the penultimate digit of the float multiplier to the position in the list of changing the same animation that something is, and the last digit to how many changes to the animation have been made in tota... The explanation is tricky, there's an example at the end. A similar thing needs to be done to hitbox changes.
  • The codes will all be appended to each other at the end to make one collossal "Brawl+ Physics Engine Data" code. This code will work in any region without requring any porting. Thus, updating a codeset will be a matter of swapping out the appropriate collossal code.

Velocity Modifiers Format:
Code:
06580500 BYTECOUN
0000000Z AAAA000B
CCCC000D EEEE000F
AAAA/CCCC/EEEE is a specific value that corresponds to each velocity type, and I'll provide a sample list with the code. B/D/F correspond to the position in the 8 digit data block; Z is the position of the Overall Gravity Modifier.

01234567
ABCDEFGH

16 Floats Code Format:
Code:
06580520 00000040
AAAAAAAA BBBBBBBB
CCCCCCCC DDDDDDDD
EEEEEEEE FFFFFFFF
GGGGGGGG HHHHHHHH
IIIIIIII JJJJJJJJ
KKKKKKKK LLLLLLLL
MMMMMMMM NNNNNNNN
OOOOOOOO PPPPPPPP
where AAA etc. are the 16 floats in order from 0 to F.

Custom Gravity Modifiers Format:
Code:
06580600 BYTECOUN
XX0ZYYYY AA0BCCCC
Where XX/AA are a character ID (or 0xFF for a wildcard), YYYY/CCCC are the last 16-bits of the action ID (generally this is just the action ID but there are some cases where this is not true; for example, Metaknight's Tornado Gravity after he touches the floor gains the value 0x4FD8). Z/B are a value corresponding to one of the 16 Floats describing which one to use for this specific action in place of the character's normal gravity change. Information on how to collect specific information will be provided with the codes.

Data Index Format:
Code:
06580000 BYTECOUN
ABCDEFGH NNNNNNNN
00000000 00000000 
ZYXWVUTS MMMMMMMM 
00000000 00000000

For each character in order, with ABCDEFGH being the positions of the fractions defined by the Velocity Modifiers code, and NNNNNNNN being a 32-bit value for momentum (75% is 0.75).

Frame Speed Float Changes:
Consider:
Code:
065A9400 00000020
120E002F 3F266666
141C0024 40400000
14140024 3F000000
14000024 40600000
This would be changed to:
Code:
065A9400 00000020
120E002F 3F2666[color=blue]0[/color][color=red]0[/color]
141C0024 404000[color=blue]0[/color][color=red]2[/color]
14140024 3F0000[color=blue]1[/color][color=red]2[/color]
14000024 406000[color=blue]2[/color][color=red]2[/color]
The actual change to speed will be negligible as a result, but this is required for the code to function at its most efficient.

Hitbox Changes:

Characters must have all their data written together (in any order). All non-character (e.g. projectile) changes should be listed together. Within each list, items should be organized by Action ID (from lowest to highest).

Code:
065A9800 00000014
GGHHIIJJ KKLLLMMM
NNOOPPQQ RRRRAABB
SSSSSSSS PPPPPPPP

GG character id
HH original damage
II original KB gain
JJ original Base KB
KK original Element
LLL original launch angle
MMM action id
NN new damage
OO new KB gain
PP new Base KB
QQ new Element
RRRR new launch angle
SSSSSSSS new SFX
PPPPPPPP new hitbox size
AA Number of change to action ID
BB Total number of changes to action ID
I realise this is quite a large change, but I like making you sweat.
 

Almas

Smash Lord
Joined
Jul 6, 2008
Messages
1,588
Updated my list of demands. I couldn't figure out how to ensure that moves with multiple animation changes would function with my new plan for the Frame Speed Engine, but I finally sorted something out. Only issue is that it requires a slight tweak to the thingies.
 

leafgreen386

Dirty camper
Joined
Mar 20, 2006
Messages
3,577
Location
Playing melee and smash ultimate
Great news, although I do have some concerns.

I'd like you to change it so that in the 16 float values used for assigning fractions to multiply things by, "0" corresponds to float 1 (3F800000). It's mainly for convenience for people who will want to use these codes when the clone engine is released.
Seems kinda annoying that it'll skip from .95 to 1.05 in the list when there's actually a value in between there. Seems like it'd cause more confusion than it would solve. Overall pretty trivial, though.

The new system doesn't require the two-digit character ID at the start of the 8 digits which describe the features. Its new format will be ABCDEFGH XXXXXXXX 00000000 00000000, where A-H are float multipliers, and Xs are the character's momentum (as a 32-bit float). The 0s are used by the system for the Frame Speed and Hitbox codes as an index. This list will be arranged in character order. Missing IDs will be padded with 0s. The ID 0x10 must remain unused.
Huh? I don't really get this. How is it identifying what character it's modifying? Actually, better yet, how do we identify what character it's modifying besides by consulting a list that says which location a character is stored at in the code? Honestly, it's cool and all that you found a way to not have to list the character ID, but that just makes it more annoying to modify. I'd much rather search for a known character ID in the code than consult a list to determine the proper location for a character, which could also result in miscounting if you're not paying attention and thus modifying the wrong values.

As part of the Launch Code you'll be able to choose which values are assigned to which location using a new code. So for ABCDEFGH, A would always be overall grav, but the role of B-H (e.g. if they modify DGrav, FF etc.) would be done by another easy-to-use code.
We'd probably end up adopting a standardized format, anyway, but cool.

As part of the Grav code, you'll be able to add specific gravity to different animations using another data code, which includes a wildcard for character choice.
You rock, almas.

Frame Speed Modifications must be arranged by character, than arranged by animation ID within each character. I realised I could use a much more efficient searching algorithm, allowing limitless animation changes rather than 80-90, but it throws on this extra restriction.
Sounds good.

For the Float Values of the Animation changes: change the last digit of the float multiplier to the position in the list of changing the same animation that something is... The explanation is tricky, there's an example at the end.
So... what happens when you go over 16 changes in the list...?

The codes will all be appended to each other at the end to make one collossal "Brawl+ Physics Engine Data" code. This code will work in any region without requring any porting. Thus, updating a codeset will be a matter of swapping out the appropriate collossal code.
I'd rather not, actually. Swapping out a couple different codes all in a row is no harder than swapping out one gigantic code, but modifying one gigantic code is a lot more annoying than modifying multiple smaller codes broken up into logical parts.

Also, if you're going to be redoing the hitbox code, could you make the format include a half-line of 00000000 after the sound value? That way each change takes up a whole number of lines, making it much less annoying to modify.

It's great to hear you're making progress.
 

Almas

Smash Lord
Joined
Jul 6, 2008
Messages
1,588
Great news, although I do have some concerns.


Seems kinda annoying that it'll skip from .95 to 1.05 in the list when there's actually a value in between there. Seems like it'd cause more confusion than it would solve. Overall pretty trivial, though.
I'd like this so that when I implement clones, it'll be easier for people to use them without playing Brawl+. I guess it's not absolutely necessary, but I'm sure some people would appreciate it.

Huh? I don't really get this. How is it identifying what character it's modifying? Actually, better yet, how do we identify what character it's modifying besides by consulting a list that says which location a character is stored at in the code? Honestly, it's cool and all that you found a way to not have to list the character ID, but that just makes it more annoying to modify. I'd much rather search for a known character ID in the code than consult a list to determine the proper location for a character, which could also result in miscounting if you're not paying attention and thus modifying the wrong values.
The codes identify the character by multiplying the character's ID by 0x10 then adding it to an offset. So Metaknight (ID 0x16) would have his information found at 0x160. This is why any gaps in character ID would need to be padded with 0s. I recommend using a Hex Editor in order to do this, because then you can set it to be one character per line. You'd just look in your list of character IDs, mentally multiply it by 0x10, and look at that address.

So... what happens when you go over 16 changes in the list...?
This numbering system is for individual animations, not each character. If you intend to use over 16 changes to a single animation, let me know.

I'd rather not, actually. Swapping out a couple different codes all in a row is no harder than swapping out one gigantic code, but modifying one gigantic code is a lot more annoying than modifying multiple smaller codes broken up into parts.
For people who play around with codes, your point is valid, but for the layman, it'd be a lot simpler for them to just have one big thing to copy/paste across without thinking about. I'd rather focus on making life easier for idiots.

Also, if you're going to be redoing the hitbox code, could you make the format include a half-line of 00000000 after the sound value? That way each change takes up a whole number of lines, making it much less annoying to modify.
I guess I can do that. But once again, I'd recommend using a Hex Editor. That way, you can set it to one hitbox change per line - making it a lot easier to read. Once you're done changing values, you can swap it back to the standard way that codes are viewed.
 
D

Deleted member

Guest
this all looks pretty awesome, can't wait for the results

EDIT: read again, and I wonder how you're gonna do the region free thing, I suppose you will use the new F6 codetype, but the data storage was always register dependant. but I'm sure you'll find/have found a way around that.

this also made me wonder, how about making all codes region free? this way we wouldn't have the difference between regions and I could focus on making new codes instead of porting. I would be glad to make this happen.
 

Almas

Smash Lord
Joined
Jul 6, 2008
Messages
1,588
The data codes will be region-free because they all either write to ~80580000 (which is unused in all regions), or are C0 codetypes (which have the same set of unused registers in all regions).

If the method of making the single .gct work is what I think it is, we might be able to put them as a code patch instead. So updating codesets would be a matter of swapping out .gpf files (which would be region-independant), while a .gct file is only updated rarely (e.g. when new codes are released).
 

shanus

Smash Hero
Joined
Nov 17, 2005
Messages
6,055
This is fairly complicated lol

This will not be fun to reprogram/retest hundreds of lines of character code changes :p
 

Yeroc

Theory Coder
BRoomer
Joined
Feb 28, 2004
Messages
3,273
Location
In a world of my own devising
I just wanna say for now that I'm with leaf on the "default" physics value. Changing the order that the floats occur in will just complicate things for everyone trying to make changes. Wouldn't it be just as easy to tell people looking for clones in VBrawl to just put 4's for everything? If one's clever enough to understand how the code works, he should be able to understand that much. Plus then you won't make it extra tedious (which it already appears like it's going to be even without this imposition) on those of us who will tweak the codes at least somewhat regularly.
 

goodoldganon

Smash Champion
Joined
Mar 17, 2008
Messages
2,946
Location
Cleveland, Ohio
If I'm understanding it right, we'd change to the new system once all of this is final. So people wouldn't need to make changes. It would be used for the official Gold version. If you want to tweak it, keep the old codes.
 
D

Deleted member

Guest
I think what almas means is that there will be one "codes" file which will never or almost never change again, and one "data" file
 

Almas

Smash Lord
Joined
Jul 6, 2008
Messages
1,588
We can put a fixed set of codes in a .gct file, and then the specific data changes in a .gpf file. .gct updates would only happen, then, when a new code was available, whilst people could swap out .gpf files to try different physics stuff. If that's how we wanted to do it.

I think I'll update my list of demands again, to annoy you.
 

Almas

Smash Lord
Joined
Jul 6, 2008
Messages
1,588
Okay, all the codes are done apart from the Hitbox, and now I know what I'm doing that shouldn't be hard. I do still have to debug them though, but it'd be a LOT easier if someone were to write some data thingies for me. I know it's a pain, but think about the system efficiency increase!

Paprika offered but I'd rather he be working on new codes. I'm no good at new codes. As far as I can recall all the information in that post is accurate.

2EF0: Friction
2F00: Dash
2F14: Fullhop/Double Jump
2F20: Shorthop
2F40: DGrav
2F5C: Fastfall

Metaknight's Tornado IDs are 112 (startup), 117 (in the air), 4FD8 (if he touches the floor).

I think all the info is there.

Once this gets done, I can do a few tweaks to add the first phase of clones. But I really only have this week till I have to go back into inactivity for another wave of exams. And I'm hoping to get the Japanese Port done during this time too. Most if it is done but I need to teest it. And show B+ to a tournament organizer while I'm at it =).

I'll add a little bit to the grav code to put it where it currently is to make life easier for you, I guess. And in the 00000000 00000000 bit for character data, you can write anything you want provided the first digit of each block is less than 8. So 0FFFFFFF is fine, 80000000 is not
 
Top Bottom