Important Melee, Hacks, and You -- New Hackers Start Here, in the OP!

[Myougi]

Someone please explain why there's a function that checks for when Mr. Saturn hits another Mr. Saturn?
80283588 __sins_Item_MrSaturn_SaturnOnSaturnCollision

I almost couldn't resist naming it "SaturnOnSaturnViolence"

Do note that this doesn't occur when objects other than Mr. Saturns collide with each other. Like, what the hell? lmfao

Isn't there a chance for an explosion to occur if two Saturns hit one another?
I personally haven't researched this any farther than hearsay.

 

[SinsOfApathy]

Isn't there a chance for an explosion to occur if two Saturns hit one another?
I personally haven't researched this any farther than hearsay.

Is there? As soon as I saw this, I looked up the Smash Wiki and saw nothing of it.

I think it's simply because Mr. Saturn is one of the only items capable of colliding with itself and other objects. Homerun Bats don't, etc..

 

[Doq]

I think it's simply because Mr. Saturn is one of the only items capable of colliding with itself and other objects. Homerun Bats don't, etc..

Turnips.

 

[SinsOfApathy]

Turnips.

I haven't actually looked at Turnip functions, but all projectiles (Fox's, Mario's, etc.) are items. They just have OnCollision checks like other items. I'd imagine Turnip is the same thing.

Mr. Saturn is specifically a Mr. Saturn only collision function. It still has a normal OnCollision check.

 

[flieskiller]

Maybe it's to set their knockback when they hit each other. Or the explosion thing. Or having their sound only 1 time (instead of hearing 2 different sounds at the same time, didn't check if that is the case though).

 

[SinsOfApathy]

Maybe it's to set their knockback when they hit each other. Or the explosion thing. Or having their sound only 1 time (instead of hearing 2 different sounds at the same time, didn't check if that is the case though).

It's their OnDamage function, which is generally used for BreakRNG type stuff. I may've overlooked hitting it with other items, because I was just throwing Mr Saturns at each other, so the one being hit was causing the breakpoint. There's a number of asserts, so I may just see a string for it in IDA.

I'll review it later and update my CSM post if that's the case.

 

[SinsOfApathy]

So, realized 0x2480 of the character struct is the start of Article Floating Point data. Really doesn't map 1:1 with Dantarion's wiki notes due to some padding 0s it seems. But working it with Fox, I could modify certain values like Firefox travel distance and see the results immediately. On the other hand, things like Reflection Bubble position couldn't be modified.

All these values reset on death, so it could be interesting mechanically to do something akin to Lucario's damage scaled recovery.

 

[SinsOfApathy]

The link to tcll's wiki in the OP is completely broken. It's not even a URL, just FYI.

 

[tatatat0]

Notes on rough animation hacking:

Spoiler

Rough animation hacking
What you will need:
A hexeditor (preferably HxD, I tell you how to optimize it for almost all of melee's files later) (download: https://mh-nexus.de/en/hxd/)
GCR (For opening your iso, you can get it here: https://www.dropbox.com/s/kh5npupjkqymtb4/gcr_v1.0.rar?dl=0)
Optimizing HxD:
View -> Bytes per row: 32
View -> Byte group size: 4
Reason for doing this: Almost ALL of melee's code is grouped into this size, with all floating points being this size. The change in bytes per row is to see more byte groups with a huge change in the size of the byte group.
Now onto the actual stuff:
Extract a characters Pl**Aj.dat using GCR. You prob know how to do this right? I can help you with it if you need it.
Leave GCR open, you'll need it.
Open it up in HXD
Organization:
What you are going to want to do is open up a empty notepad (You'll need it for temporarily storing data)
Look through Crazy Hand Subactions (All) list for the subaction you wish to edit. Take note of its string name (Attack10, AttackAirF, Walldamage, CatchDash, TurnRun, etc...)
In HXD press ctrl+f -> search direction: ALL; Datatype: Text-string
and search the string name of the subaction
Upon the first result you will see something like PlyCHARACTER5K_SHARE_ACTION_Subactionstringname_figatree
This is the header of the animation. This will ALWAYS take up two "lines" in HxD if you formatted HxD correctly, otherwise it takes up 0x40. If the stringname doesn't take up the entire two lines the end will be padded with FF's.
After these FF's are the start of the animation.
Precautions:
Make a backup of Pl**Aj.dat just in case
Write down the starting offset of the animation as 0xSTARTHEXADDRESS-
(We will fill in the other portion later)
Begin to highlight from that position until the 00000000 before the next animation header you see.
Write down the end offset in notepad as 0xSTARTHEXADDRESS-ENDHEXADDRESS:
What you just wrote was the animation offsets and will be referred as such from this point on.
paste the entire contents you highlighted afterwards, if you ever screw up you can just revert the entire animation.
Throw some newlines(Enters) after that. Its always good to have some spare enters at the bottom of the notepad so you don't have to scroll sideways all the time.
Breakdown of the animation:
The animation is split into thre main parts:
The header(We went over this earlier)
the body,
and the footer.
The body is the main part of the animation responsible for all the good stuff, it begins right after the header.
The footer will look something like
00000ABC 00000AC8 00000AD4 00000AE0 00000AEC 00000AF8 00000B04 00000B10
00000B1C 00000B28 00000B34 00000B40 00000B4C 00000B58 00000B64 00000B70
00000B7C 00000B88 00000B94 00000BA0 00000BAC 00000BB8 00000BC4 00000BD0
00000BDC 00000BE8 00000BF4 00000C00 00000C0C 00000C18 00000C24 00000C30
00000C3C 00000C48 00000C54 00000C60 00000C6C 00000C78 00000C84 00000C90
00000C9C 00000CA8 00000CB4 00000CC0 00000CCC 00000CD8 00000CE4 00000CF0
00000CFC 00000D08 00000D14 00000D20 00000D2C 00000D38 00000D44 00000D50
00000D5C 00000D68 00000D74 00000D80 00000D8C 00000D98 00000DA4 00000DB0
Its point is unknown, previous experiences make me conclude it is pointless for anything I would need (no documented effects of changing it)
However, There is a common pattern to the footer
The footer is broken down into 8 collumns, with each collumn containing a number
as you move down a collumn, the number increments by 0x60.
That is what is known.
Now onto actual animation hacking.
In the body highlight a random section of hex of about 3 lines (0x60)
copy it, create an animations offsets in notepad for it (0xSTARTHEXADDRESS-ENDHEXADDRESS: HEX)
(Do not immediately save after performing the following)
Right click on the highlighted hex
Click fill selection -> Random Bytes -> Ok (this will be referred to as random byting)
Now still do not save
Highlight the now red text
Ctrl-S (Save)
Open up GCR(alt+tab)
Right click on the Pl**AJ.dat and import the now edited file
Play it in dolphin and use the desired move
Take note of the bones that are moving
If you want for example, to perform an upper-cut of some sort, check to see if the arms are moving. If they are GREAT(Note, crazy flailing if it includes the bones desired is OK), Move onto, Process of elimations:
Otherwise, you ran out of luck. Open up hexedit and paste over the still highlighted region the original hex and try again.
Process of elimnation:
Great you identified a bone you want to change, "What do I do now?".
So you have the region you changed to get the desired result, paste the original hex over the highlighted region.
Split that region into several sub-regions, making an animation offset for each.
Go through each subregion, random byting the region (still following the optimization steps with highlighting regions)
and loading dolphin up with the changes.
Use the process of elimination to determine which sub-region contains the hex that controls the desired bone.
Once you have the determined the sub-region, split that up into sub-sub-regions until you find the exact hex that controls it.
You now have what you want.
Fiddle with that as you please.
Notes:
Some of the animation body can't be random byted as it contains op-code read by the game and will cause a crash. Its no big deal, just revert the hex and skip over it.

Sinsofapathy, please don't destroy me for explaining something slightly off.

 

[morkymork]

thanks

Notes on rough animation hacking

 

[SinsOfApathy]

In regards to the stage structure @Absolome put in the data sheet, I've moved it to a stage specific tab. It's a struct, which is used by various functions. The Stgs_SpawnInteractObjs function I put in the CSM thread uses the base pointer + 0x6C0, so I think this functions roughly like the static player block, except it's the static stage block.

I realized a really quick way to identify functions using these static structs in IDA, can you see what it is?

So yeah, gonna see if I can get **** done after my midterms this week.

 

[tatatat0]

I haven't actually looked at Turnip functions, but all projectiles (Fox's, Mario's, etc.) are items. They just have OnCollision checks like other items. I'd imagine Turnip is the same thing.

Mr. Saturn is specifically a Mr. Saturn only collision function. It still has a normal OnCollision check.

It makes a special noise, and they bounce off I believe.

 

[SinsOfApathy]

It makes a special noise, and they bounce off I believe.

Every item bounces off each other and they always make the noise.

I'm pretty sure I was just mistaken in my testing, but I still haven't gone back to check it.

Edit: I decided to zero static_stage.0x6C0, which controls non-static objects.

DEAR GOD WHAT HAS SCIENCE DONE

 

[Achilles1515]

SinsOfApathy

Stage Info
---------------------------------------

Start - 8049e6c8

0x0000   float  camera left limit
0x0004   float  camera right limit
0x0008   float  camera top limit
0x000C   float  camera bottom limit
0x0010   float  camera x-axis offset (limits start from here)
0x0014   float  camera y-axis offset 
0x001C   float  camera vertical axis tilt

Note: 0x20-0x30 copied directly from stage grGroundParam data

0x0020   float  camera dynamic rotation about y-axis
0x0028   float  camera fixedness around characters (higher shows more stage along with all chars, pseudo-zoom value)
0x002C   float  camera fixedness zoom when not moving? (higher = further out)
0x0030   float  camera speed smoothness
                - 0 freezes camera in place
0x0034   float  camera character zoom (?) (set to 0 and camera doesn't move)
0x0044   float  camera pause initial z-axis position
0x004C   float  ?? camera pause initial _ position
0x0050   float  ?? camera pause initial _ position
0x0054   float  ?? camera pause initial _ position
0x0058   float  ?? camera pause initial _ position
0x005C   float  fixed camera, x-axis offset
0x0060   float  fixed camera, y-axis offset
0x0064   float  fixed camera, depth max
0x0068   float  fixed camera, zoom or something (8049e730)
0x006c   float  fixed camera, tilt about x-axis
0x0070   float  fixed camera, focus point x-axis
0x0074   float  Blastzone left
0x0078   float  Blastzone right
0x007C   float  Blastzone top
0x0080   float  Blastzone bottom
0x0084   word   ??
                or'ed with (00000020) once 0 targets remain in BtT. Maybe flag to end game of some sort? Haven't tested.
0x0088    word    Internal Stage ID (0x4 from Gr__.dat ASCII in DOL)
0x008C    byte   ??
        (00000004) - ?? set in stage initialization
        (00000008) - stage has multiple respawn points per player
0x0098   word   Music ID currently playing (49e760)
0x009C   word   Bombrain - frame of last bomb drop, other uses?
0x0180    point    ??
0x0184    point    ?? 801c2ba4
0x0280    point  P1 spawn point bone
0x0284    point  P2 spawn point bone
0x0288    point  P3 spawn point bone
0x028C    point  P4 spawn point bone
0x0290    point  P1 Respawn point bone
0x0294    point  P2 Respawn point bone
0x0298    point  P3 Respawn point bone
0x029C    point  P4 Respawn point bone
0x04D4   point  camera limit, left-top, stage file info
0x04D8   point  camera limit, right-bottom, stage file info
0x04DC   point  blastzone, left-top, stage file info
0x04E0   point  blastzone, right-bottom, stage file info
0x06A8   point  itemdata stage file info
0x06AC   point  coll_data stage file info
0x06B0   point  grGroundParam file info
                 --> 0x004C = 
0x06B4    point  ALDYakuAll stage file info
0x06B8    point    map_ptcl stage file info
0x06BC    point  map_texg stage file info
0x06C0   point  yakumono_param stage file info
0x06C4   point  map_plit stage file info
0x06CC   point  quake_model_set stage file info
0x06E0   float  Home-run Contest Distance?? load function 801c57f0
0x06E4   word   Vs mode / single player flag of some sort
0x06D4   short  Number of Targets left [Break the Targets]
0x06D8   word   ?? load function 801c5764
0x06DC   short  ?? load function 801c5774
0x0724   float  ?? load & store function 801c4368 (BtT?)
0x0728   float  ?? 
0x0740   word   ?? load function 801c5794

--- 8049EE10 ---
0x0748   point  Gr_.dat file offset start in RAM
0x074C    point    Gr_.dat, Map_Head offset
0x08A8    float  P1 Spawn Point - x coord
0x08AC    float    P1 Spawn Point - y coord

 

[SinsOfApathy]

Achilles1515 Thanks. I'll get that migrated over to the spreadsheet tomorrow. Most of that I figured out earlier, but there's a few things to be corrected, etc..

 

[zankyou]

Notes on rough animation hacking:

Spoiler

Rough animation hacking
What you will need:
A hexeditor (preferably HxD, I tell you how to optimize it for almost all of melee's files later) (download: https://mh-nexus.de/en/hxd/)
GCR (For opening your iso, you can get it here: https://www.dropbox.com/s/kh5npupjkqymtb4/gcr_v1.0.rar?dl=0)
Optimizing HxD:
View -> Bytes per row: 32
View -> Byte group size: 4
Reason for doing this: Almost ALL of melee's code is grouped into this size, with all floating points being this size. The change in bytes per row is to see more byte groups with a huge change in the size of the byte group.
Now onto the actual stuff:
Extract a characters Pl**Aj.dat using GCR. You prob know how to do this right? I can help you with it if you need it.
Leave GCR open, you'll need it.
Open it up in HXD
Organization:
What you are going to want to do is open up a empty notepad (You'll need it for temporarily storing data)
Look through Crazy Hand Subactions (All) list for the subaction you wish to edit. Take note of its string name (Attack10, AttackAirF, Walldamage, CatchDash, TurnRun, etc...)
In HXD press ctrl+f -> search direction: ALL; Datatype: Text-string
and search the string name of the subaction
Upon the first result you will see something like PlyCHARACTER5K_SHARE_ACTION_Subactionstringname_figatree
This is the header of the animation. This will ALWAYS take up two "lines" in HxD if you formatted HxD correctly, otherwise it takes up 0x40. If the stringname doesn't take up the entire two lines the end will be padded with FF's.
After these FF's are the start of the animation.
Precautions:
Make a backup of Pl**Aj.dat just in case
Write down the starting offset of the animation as 0xSTARTHEXADDRESS-
(We will fill in the other portion later)
Begin to highlight from that position until the 00000000 before the next animation header you see.
Write down the end offset in notepad as 0xSTARTHEXADDRESS-ENDHEXADDRESS:
What you just wrote was the animation offsets and will be referred as such from this point on.
paste the entire contents you highlighted afterwards, if you ever screw up you can just revert the entire animation.
Throw some newlines(Enters) after that. Its always good to have some spare enters at the bottom of the notepad so you don't have to scroll sideways all the time.
Breakdown of the animation:
The animation is split into thre main parts:
The header(We went over this earlier)
the body,
and the footer.
The body is the main part of the animation responsible for all the good stuff, it begins right after the header.
The footer will look something like
00000ABC 00000AC8 00000AD4 00000AE0 00000AEC 00000AF8 00000B04 00000B10
00000B1C 00000B28 00000B34 00000B40 00000B4C 00000B58 00000B64 00000B70
00000B7C 00000B88 00000B94 00000BA0 00000BAC 00000BB8 00000BC4 00000BD0
00000BDC 00000BE8 00000BF4 00000C00 00000C0C 00000C18 00000C24 00000C30
00000C3C 00000C48 00000C54 00000C60 00000C6C 00000C78 00000C84 00000C90
00000C9C 00000CA8 00000CB4 00000CC0 00000CCC 00000CD8 00000CE4 00000CF0
00000CFC 00000D08 00000D14 00000D20 00000D2C 00000D38 00000D44 00000D50
00000D5C 00000D68 00000D74 00000D80 00000D8C 00000D98 00000DA4 00000DB0
Its point is unknown, previous experiences make me conclude it is pointless for anything I would need (no documented effects of changing it)
However, There is a common pattern to the footer
The footer is broken down into 8 collumns, with each collumn containing a number
as you move down a collumn, the number increments by 0x60.
That is what is known.
Now onto actual animation hacking.
In the body highlight a random section of hex of about 3 lines (0x60)
copy it, create an animations offsets in notepad for it (0xSTARTHEXADDRESS-ENDHEXADDRESS: HEX)
(Do not immediately save after performing the following)
Right click on the highlighted hex
Click fill selection -> Random Bytes -> Ok (this will be referred to as random byting)
Now still do not save
Highlight the now red text
Ctrl-S (Save)
Open up GCR(alt+tab)
Right click on the Pl**AJ.dat and import the now edited file
Play it in dolphin and use the desired move
Take note of the bones that are moving
If you want for example, to perform an upper-cut of some sort, check to see if the arms are moving. If they are GREAT(Note, crazy flailing if it includes the bones desired is OK), Move onto, Process of elimations:
Otherwise, you ran out of luck. Open up hexedit and paste over the still highlighted region the original hex and try again.
Process of elimnation:
Great you identified a bone you want to change, "What do I do now?".
So you have the region you changed to get the desired result, paste the original hex over the highlighted region.
Split that region into several sub-regions, making an animation offset for each.
Go through each subregion, random byting the region (still following the optimization steps with highlighting regions)
and loading dolphin up with the changes.
Use the process of elimination to determine which sub-region contains the hex that controls the desired bone.
Once you have the determined the sub-region, split that up into sub-sub-regions until you find the exact hex that controls it.
You now have what you want.
Fiddle with that as you please.
Notes:
Some of the animation body can't be random byted as it contains op-code read by the game and will cause a crash. Its no big deal, just revert the hex and skip over it.

Sinsofapathy, please don't destroy me for explaining something slightly off.

Can you tell what file you are using so I can see what you are calling the footer.

 

[tatatat0]

Can you tell what file you are using so I can see what you are calling the footer.

Sure, sometime later this afternoon I'll try to clear that up. Perhaps not every animation has one, but I have noticed it in every single animation I have checked.
Edit: I'm almost certain its on every single one. If you find any exceptions you should probably document that.

 

[tatatat0]

You can visibly see the collumns(literal collumns, ALWAYS has the same amount of collumns, otherwise it probably wouldn't be visible with the amount of bytes per row) The footer is always above the header of the next animation. If you still can't find it can you maybe tell me what character you are looking at + the subaction?
Edit: Nevermind on the footer being harmless/doing nothing. Changing it can cause crauses/hangs. There is some really interesting stuff you can do with it like a floating wait animation

Spoiler

Btw the special pattern could probably be simplified to as it goes right it increments by 0xC. I probably just saw the collumns first as it was very obvious. The footer seems to contain bone positions. This atrocity came out of fiddling

Spoiler

Definitely some sort of bone positions. This seems like something big.
I really wonder if one of these values controls the ECB?
This is a huge deal.

 

[zankyou]

Okay I just wanted to confirm that the footer was the relocation table. You should look at the animation hacking documentation thats already out and see if you can add to that if you are willing to brute force it.
Also its been a while since Ive looked at the aj files but that header the string table for the data before it.

 

[tatatat0]

Okay I just wanted to confirm that the footer was the relocation table. You should look at the animation hacking documentation thats already out and see if you can add to that if you are willing to brute force it.
Also its been a while since Ive looked at the aj files but that header the string table for the data before it.

Didn't even know there was documentation, most of the time people just say nobody has anything on it and its like the dark arts of melee hacking.

 

[SinsOfApathy]

Didn't even know there was documentation, most of the time people just say nobody has anything on it and its like the dark arts of melee hacking.

The OP of this thread has documentation the format.

 

[tatatat0]

The OP of this thread has documentation the format.

Where is this documentation? Edit: That little thread of Itaru's? rip

 

[SinsOfApathy]

Melee dat format… - created by revel8n - DAT files are the primary type of data file that Melee uses to store stages, characters, trophies, menus, images, fonts, and more. This thread walks you through the hierarchy of how they're made up. Needless to say, this is for advanced hacking purposes.

http://smashboards.com/threads/animation-hacking-documentation.426374/

 

[zankyou]

Where is this documentation? Edit: That little thread of Itaru's? rip

I added the format of the file at the end of the thread.
Also I dont really recommend trying to brute force it that way since animations are formatted in different ways and itd probably be hard to find a pattern. My theory is that the animation code is the missing piece. Itd be really nice if someone who understand brawl's animation format (@Tcll) would help us out.

 

[SinsOfApathy]

I added the format of the file at the end of the thread.
Also I dont really recommend trying to brute force it that way since animations are formatted in different ways and itd probably be hard to find a pattern. My theory is that the animation code is the missing piece. Itd be really nice if someone who understand brawl's animation format (@Tcll) would help us out.

http://wiki.tockdom.com/wiki/CHR0_(File_Format)

Are you looking for something like this?

 

[Decipio-Carmen]

Hey guys. This wasn't covered in the HPS Hacking guide so I'll ask it here.

When creating your own custom stage music, hps_insert will create a file equal to temp.hps (30,194 KB) this is very huge. In another tutorial, "Custom Music Guide that Makes Sense", he sort of just deletes stuff without really explaining what will cause the game to crash and what will not.

Let's say you create an .hps file using hps_insert. If the last block that your music is contained in is block number X, you can delete block X+1, and everything after it. Sometimes though, you can delete some of the bytes in block X, and the song will loop just fine.

I suspect that such cases, the timer (calculated by number N = (seconds)(sample rate)(16/14)+15)) counts down to 0 before the last byte in block X is reached. However, as far as I can tell, the number N does not equal to the number of pcm data bytes that the game reads before it loops. i.e. if you delete the Nth data byte and onwards, the game crashes, because the last byte that is actually read before looping is some number of bytes after the Nth data byte. Is there any way to precisely determine the last offset that is read before the audio loops? This is not too big of a deal since deleting block X+1 onwards helps a lot in reducing file sizes, but audio file sizes could be reduced a little more.

 

[zankyou]

http://wiki.tockdom.com/wiki/CHR0_(File_Format)

Are you looking for something like this?

Thats what Im basing my assumption on. I just dont have a way of testing it and seeing if the animation code works the same way. I doubt it does exactly because brawl orders the translation/rotation/scale differently than melee. basically I hit a brick wall as far as the animation code goes. I have an idea of where it appears but cant go from there.

 

[Achilles1515]

Hey guys. This wasn't covered in the HPS Hacking guide so I'll ask it here.

When creating your own custom stage music, hps_insert will create a file equal to temp.hps (30,194 KB) this is very huge. In another tutorial, "Custom Music Guide that Makes Sense", he sort of just deletes stuff without really explaining what will cause the game to crash and what will not.

Let's say you create an .hps file using hps_insert. If the last block that your music is contained in is block number X, you can delete block X+1, and everything after it. Sometimes though, you can delete some of the bytes in block X, and the song will loop just fine.

I suspect that such cases, the timer (calculated by number N = (seconds)(sample rate)(16/14)+15)) counts down to 0 before the last byte in block X is reached. However, as far as I can tell, the number N does not equal to the number of pcm data bytes that the game reads before it loops. i.e. if you delete the Nth data byte and onwards, the game crashes, because the last byte that is actually read before looping is some number of bytes after the Nth data byte. Is there any way to precisely determine the last offset that is read before the audio loops? This is not too big of a deal since deleting block X+1 onwards helps a lot in reducing file sizes, but audio file sizes could be reduced a little more.

Just use MeleeHPS.

 

[zankyou]

Hey guys. This wasn't covered in the HPS Hacking guide so I'll ask it here.

When creating your own custom stage music, hps_insert will create a file equal to temp.hps (30,194 KB) this is very huge. In another tutorial, "Custom Music Guide that Makes Sense", he sort of just deletes stuff without really explaining what will cause the game to crash and what will not.

Let's say you create an .hps file using hps_insert. If the last block that your music is contained in is block number X, you can delete block X+1, and everything after it. Sometimes though, you can delete some of the bytes in block X, and the song will loop just fine.

I suspect that such cases, the timer (calculated by number N = (seconds)(sample rate)(16/14)+15)) counts down to 0 before the last byte in block X is reached. However, as far as I can tell, the number N does not equal to the number of pcm data bytes that the game reads before it loops. i.e. if you delete the Nth data byte and onwards, the game crashes, because the last byte that is actually read before looping is some number of bytes after the Nth data byte. Is there any way to precisely determine the last offset that is read before the audio loops? This is not too big of a deal since deleting block X+1 onwards helps a lot in reducing file sizes, but audio file sizes could be reduced a little more.

Did you change the last blocks pointer so that it points back to the beginning?

 

[tatatat0]

Did you change the last blocks pointer so that it points back to the beginning?

I noticed in one of the audio guides that the default for the HPS builder (I believe it was Achilles guide Here) has the loop 5 blocks before the end and has it loop to 1 block after the starting block? Whats up with this? Is there 5 pointless blocks at the end and is the first block a header or something? Why 5 & 1?

 

[SinsOfApathy]

I noticed in one of the audio guides that the default for the HPS builder (I believe it was Achilles guide Here) has the loop 5 blocks before the end and has it loop to 1 block after the starting block? Whats up with this? Is there 5 pointless blocks at the end and is the first block a header or something? Why 5 & 1?

Pretty sure it's arbitrarily chosen to make the song not sound **** like when there's pauses/gaps or sudden change in pace.

 

[tatatat0]

Pretty sure it's arbitrarily chosen to make the song not sound **** like when there's pauses/gaps or sudden change in pace.

Its actually done much more harm then good, I (as I hope other people do as well) trim my audio beforehand, expecting just the entire thing to loop. Well at least now I can be sure that it is what I thought it was. thanks.

 

[zankyou]

I noticed in one of the audio guides that the default for the HPS builder (I believe it was Achilles guide Here) has the loop 5 blocks before the end and has it loop to 1 block after the starting block? Whats up with this? Is there 5 pointless blocks at the end and is the first block a header or something? Why 5 & 1?

Well the game reads part of the audio stream in advance so the extra 5 blocks is probably just to make sure nothing breaks. A while back I would create my own blocks but I dont remember exactly how I dealt with that. Just that the game would crash on loop if it tried to read in advance and it hit the end of the file. If I had to guess first block is just there to adjust the loop as to minimize the silence if you didnt make your audio sample rate fit in the blocks.

 

[tatatat0]

I was wondering, would it be possible to change the offset(physical placement on screen) of the selection radius of the CSS hand? I want to make a smaller css hand that is centered a little bit lower.

 

[Achilles1515]

@Magus420 , I believe your old hitbox subaction event information is inaccurate for the last word of hitbox data.

Originally Posted:

.....16..........17..........18..........19
| BBBB BBBB | BEEE EEVL | LLLL LLFF | FFFF FFTT |

B: Base Knockback
E: Element
V: Unknown-4
L: Shield Damage
F: Sound FX
T: Hurtbox Interaction


-------------------------------------------------------------------------------------------------------------

Proposed Change:

.....16..........17..........18..........19
| BBBB BBBB | BEEE EELL | LLLL LLVV | VFFF FFTT |

B: Base Knockback
E: Element
L: Shield Damage
V: Unknown-4
F: Sound FX
T: Hurtbox Interaction

-------------------------------------------------------------------------------------------------------------

Support (Game code reading this hitbox data):
8007147C stores the pointer to the last word of the hitbox data.

@Ampers @Tater

 

[Achilles1515]

schmooblidon @Gentlefox
Reports about the Melee Calculator say the knockback formula is incorrect when attacks are staled. I just looked at the game code - the regular knockback formula is as follows:

Knockback[regular] = {(0.01 * knockback growth) * {{1.4 * {{{0.05 * {attack damage unstaled * [attack damage staled + floor(current damage)]}} + [attack damage staled + floor(current damage)] * 0.1} * {2.0 - [2.0 * (weight * 0.01)] / [1.0 + (weight * 0.01)]}}} + 18} + base knockback} * VicimDefenseRatio * AttackerOffenseRatio * GlobalDamageRatio

If Knockback > 2500, then Knockback = 2500.

Other multipliers (crouch canceling, smash attack charging, etc) are applied later in a separate function.

 

[Achilles1515]

I noticed in one of the audio guides that the default for the HPS builder (I believe it was Achilles guide Here) has the loop 5 blocks before the end and has it loop to 1 block after the starting block? Whats up with this? Is there 5 pointless blocks at the end and is the first block a header or something? Why 5 & 1?

That's just how MeleeHPS reads inputs. The value of 5 was used because I chose to loop the track on block 6.

Think of the BlockStart value as how many blocks get read before entering the looping block section.
Think of the BlockLoop value as how many blocks encompass the loop before actually looping back. Then on the second line of data in BlockLoop: from the .asm file, it has one more block with a loop back to the start of BlockLoop. (I'm looking at the picture in the "Outputting the HPS file" portion of the guide).

But really, you don't need to know any of this and just follow the directions.

 

[schmooblidon]

Achilles you babe!

Wait hold up:

Other multipliers (crouch canceling, smash attack charging, etc) are applied later in a separate function.

I thought smash charge only changed the damage?

damage *= 1 + (chargeFrames * (0.3671/60)) ?

Is this not correct? Does it change knockback in a different way?

 

[tatatat0]

Achilles you babe!

Wait hold up:


I thought smash charge only changed the damage?

damage *= 1 + (chargeFrames * (0.3671/60)) ?

Is this not correct? Does it change knockback in a different way?

I believe it used to be a well known thing that it multiplied knockback by 1.2. Idk if what Achilles found matches up with that though.

 

[tatatat0]

CSS notes:

Spoiler

MnSlChr.usd offsets (tatatat0):
0x50E4-50F0: CSS Selector puck lighting (ASM)
0x4F40-50BF: CSS moving background controls (ASM)
0x5138: Some sort of layer(?) color overlay for entire CSS?
0x513F: Some sort of layer(?) color overlay for entire CSS?
0x5150: CSS layer camera zoom-out level (Lower values = zoomed in, higher values = zoomed out)
0x5170: Integer: usually 1. 2/3 causes black screen upon CSS, 0/4/5/probably rest of numbers causes freeze. (Screen focus maybe?)
0x5174: Integer: CSS layer Horizontal Stretch
0x5178: Integer: CSS layer Vertical Stretch
0x517C: Integer: Controls background object movement looping??
0x5180: Integer: CSS Layer height?(if lowered, part of or all of screen is black)
0x5184: Integer?: No clue(value probably must be 5124, otherwise screen is black)
0x5188: Integer?: Unknown (value is 5138)(Read every single frame)
0x5194: Unknown (3DCCCCCD)
0x5198: Unknown (459C4000)
0x519C: CSS screen size/zoom? (41C7FFFF) (making this smaller you can see the full background objects, being able to confirm any changes to them)
0x51A0: CSS screen Aspect ratio/ Horizontal compression? (Higher values compresses the screen a LOT)
Notes: Did you know some of the giant moving background objects are just text that say "SELECT" (http://i.imgur.com/4LNLQEQ.gif)
Difference between CSS layer and screen:
The CSS screen contains the entire CSS, foreground background, anything else. It is like a wrapper for the entire thing.
Changing the zoom on the CSS screen to be zoomed out will show the background objects(Giant "SELECT"s, and will show black space http://imgur.com/4LNLQEQ)
Anyways its kinda hard to explain, just remember that the CSS Screen CONTAINS the CSS layer, and the CSS Layer is what contains all the stuff on the CSS. It has to do with the organization of the CSS.
Don't always trust me on identifying which is which, because its kinda of hard. There definitely is a difference though.
The entire start of the file is ASM that controls things like the giant moving background objects' color and lighting, background lighting, and stuff like that.

Taking a lot of notes today, probably will update this post more.