Melee Stage Hacking Documentation (WARNING: Not User-Friendly)

[CeLL]

In working on this I realized I did something wrong with the string table and that some pointers were mixed up between the strings, and some strings would simply not be included. I fixed it now, sorry.

Also those values you listed for grGroundParam, what type of data are those? 32-bit floats? It's not listed on Yax's doc.

 

[zankyou]

Yeah I think I can do that, but how do I get to the start of the spot table?

This sounds incredibly useful. Since floats are relative to each other I can get the idea of where everything is by looking at the table but this could make it easier to see the direction of the links.

 

[Achilles1515]

In working on this I realized I did something wrong with the string table and that some pointers were mixed up between the strings, and some strings would simply not be included. I fixed it now, sorry.

Also those values you listed for grGroundParam, what type of data are those? 32-bit floats? It's not listed on Yax's doc.

I think I experienced that string problem with Pokemon Stadium. Cool.

And some are floats and some are ints. Just look at the GroundParam section on IE's post.

 

[Achilles1515]

Probably a stupid question, but why do "Areas" exist? Why isn't the entire space within a blastzone the default area?

--------------
One more thing while I'm thinking about it Cell, if you do end up working on the spot coordinate plotter, can you add in an option to multiply all values by X amount? I guess it would be nice to make this variable editable to whatever you want, but it will generally be the "Stage Size" value, which is 0x00 from the start of GroundParam.

For most stages, this value is 1. But others (like Battlefield) have this value as 0.8 or something else. When a stage is chosen and the stage geometry is being created, the game takes the stage size and multiplies every spot coordinate by this amount. And that gives you the new coordinates for your stage at, say, 80% default size.

For example, when I was figuring out how to RAM hack Battlefield, I noticed the platform heights were 27.2 (by looking at the Y coordinate of a player while standing on the platform). So I searched GrNBa.dat for that floating point value and found nothing, which confused the hell out of me, especially because I was modifying multiple values of 27.2 in the RAM and this would move the platform texture/coordinates. But then I realized the stage was scaled down to 80%, did a search for 34 instead and then found the coordinates in the dat file relating to the platform.

(34 * 0.8 = 27.2)

Sorry to keep throwing ideas/requests your way.

 

[CeLL]

Probably a stupid question, but why do "Areas" exist? Why isn't the entire space within a blastzone the default area?

--------------
One more thing while I'm thinking about it Cell, if you do end up working on the spot coordinate plotter, can you add in an option to multiply all values by X amount? I guess it would be nice to make this variable editable to whatever you want, but it will generally be the "Stage Size" value, which is 0x00 from the start of GroundParam.

For most stages, this value is 1. But others (like Battlefield) have this value as 0.8 or something else. When a stage is chosen and the stage geometry is being created, the game takes the stage size and multiplies every spot coordinate by this amount. And that gives you the new coordinates for your stage at, say, 80% default size.

For example, when I was figuring out how to RAM hack Battlefield, I noticed the platform heights were 27.2 (by looking at the Y coordinate of a player while standing on the platform). So I searched GrNBa.dat for that floating point value and found nothing, which confused the hell out of me, especially because I was modifying multiple values of 27.2 in the RAM and this would move the platform texture/coordinates. But then I realized the stage was scaled down to 80%, did a search for 34 instead and then found the coordinates in the dat file relating to the platform.

(34 * 0.8 = 27.2)

Sorry to keep throwing ideas/requests your way.

Yeah I'll make it automatically throw the multiplier from the stage size value onto every point, and then let you change it to whatever. Trivially easy.

 

[CeLL]

@ Achilles1515 I added a bit. What do you think of the format? Like I'm going to switch coll_data from raw points to a graph, among other things, and clean up grGroundParam and add a save button to it, too (), but like the idea of the menu to get more information about specific sections. Btw the spots are multiplied by the stage size value right now. I'm not sure I got the right data type for everything in grGroundParam, either. Are the really big numbers actually negative and I'm just not converting them correctly?

 

[Achilles1515]

@ Achilles1515 I added a bit. What do you think of the format? Like I'm going to switch coll_data from raw points to a graph, among other things, and clean up grGroundParam and add a save button to it, too (), but like the idea of the menu to get more information about specific sections. Btw the spots are multiplied by the stage size value right now. I'm not sure I got the right data type for everything in grGroundParam, either. Are the really big numbers actually negative and I'm just not converting them correctly?

Awesome. Can't wait to try it out after work.

If the first bit of a floating number is 1, then the number is negative. If it is 0, then it is positive.\

Er wait you prpbably know this... are you talking about ints?
0xFFFFFFFF = -1
0xFFFFFFFE = -2
0xFFFFFFFD = -3
Etc.

 

[CeLL]

Awesome. Can't wait to try it out after work.

If the first bit of a floating number is 1, then the number is negative. If it is 0, then it is positive.\
View attachment 40354

Er wait you prpbably know this... are you talking about ints?
0xFFFFFFFF = -1
0xFFFFFFFE = -2
0xFFFFFFFD = -3
Etc.

Oh Python has built in conversion tools, I just don't think that I am giving them the correct parameters for the data that turn out to be like 8 digit ints after "conversion." I just tried assuming they were signed ints and floats and picked whichever one looked more likely to be correct, but some still look wrong to me.

 

[CeLL]

I made it a bit cleaner and added a plus to the name. http://www.mediafire.com/download/dffo8l4s2fi2rgn/String_Table+.zip

 

[Achilles1515]

I made it a bit cleaner and added a plus to the name. http://www.mediafire.com/download/dffo8l4s2fi2rgn/String_Table .zip

@ CeLL I'm digging it, man. Thanks a lot for putting time into this! It's going to be a great stage hacking tool. The plotter is going to be stellar.

If anyone is curious, I changed the "Area" dimensions for Battlefield to mirror the blastzone values and everything seems to be normal and collisions can be placed anywhere on the screen. (From what I can tell).

 

[flieskiller]

@ CeLL
If anyone is curious, I changed the "Area" dimensions for Battlefield to mirror the blastzone values and everything seems to be normal and collisions can be placed anywhere on the screen. (From what I can tell).

Is there the glitch of Falcon automatic walljumping from the edge?

 

[Achilles1515]

Is there the glitch of Falcon automatic walljumping from the edge?

Yeah, that's unaffected. This Area I'm talking about is an invisible box in which stage collisions can occur. If you were to put the coordinates of a stage element outside of the Area, then it wouldn't act normal and, generally, the character would just pass through the element instead of colliding with it.

So with Battlefield, I was moving platforms far left/right, and once I moved them so far, the characters would just fall through the platforms instead of landing on them. Last night I modified the Area limites to encapsulate the entire space within the blastzone, and then the platforms acted normal.

This is why I was curious as to why Areas even exist. Maybe they're more for stages that move or something.

And as Milun said, the instant walljump is moreso a mechanic than a glitch, I think. And it just doesn't happen on the tourney legal stages because their ledge geometry is unique and not just straight vertical. Although, FD's is vertical for a significant portion and you can instant walljump of it.

 

[zankyou]

Yeah, that's unaffected. This Area I'm talking about is an invisible box in which stage collisions can occur. If you were to put the coordinates of a stage element outside of the Area, then it wouldn't act normal and, generally, the character would just pass through the element instead of colliding with it.

So with Battlefield, I was moving platforms far left/right, and once I moved them so far, the characters would just fall through the platforms instead of landing on them. Last night I modified the Area limites to encapsulate the entire space within the blastzone, and then the platforms acted normal.

This is why I was curious as to why Areas even exist. Maybe they're more for stages that move or something.

And as Milun said, the instant walljump is moreso a mechanic than a glitch, I think. And it just doesn't happen on the tourney legal stages because their ledge geometry is unique and not just straight vertical. Although, FD's is vertical for a significant portion and you can instant walljump of it.

Im not entirely sure that it doesnt happen on tourney stages for that reason. Why I made that Yoshi Island stage it was a perfect square but he only doraki walljumped on the side I made. I think theres something to the order of links. But fixing the angle is probably the easiest way not to have to deal with the games shenanigans.

 

[Achilles1515]

Im not entirely sure that it doesnt happen on tourney stages for that reason. Why I made that Yoshi Island stage it was a perfect square but he only doraki walljumped on the side I made. I think theres something to the order of links. But fixing the angle is probably the easiest way not to have to deal with the games shenanigans.

zankyou, what the hell did you do to that right edge so that you cannot doraki on it???? On the default stage, you can do it on that ledge...I'm just so confused and been looking at it all night (wasting time at this point maybe).

 

[zankyou]

zankyou, what the hell did you do to that right edge so that you cannot doraki on it???? On the default stage, you can do it on that ledge...I'm just so confused and been looking at it all night (wasting time at this point maybe).

If I did anything I have no idea what it was and failed to replicate it. I just assumed it had something to do with the links going clockwise or maybe the length of the top connecting links. But I was too tedious to test for something like that when you have no idea what the game is doing.

 

[SinsOfApathy]

This is why I was curious as to why Areas even exist. Maybe they're more for stages that move or something.

Probably used for sequences like the Triforce dungeon in Adventure mode. Objects outside of the area are made invisible, scene background transitions, and the area is adjusted so they no longer have collision.

Otherwise, their stage tool probably auto-adjusted the area size to reduce processing needs, assuming it's part of one of the two player "think" functions and has some instruction cycle if a player exists within the bounds.

 

[CeLL]

@ Achilles1515 What are the maximum and minimum values for 32-bit floats? I'm restricting what you can type in the entry field for them and I need to know what the decimal equivalents that you can't go past are. Like 32-bit signed integers can't go above 2147483647 or below -2147483648.

 

[SinsOfApathy]

@ Achilles1515 What are the maximum and minimum values for 32-bit floats? I'm restricting what you can type in the entry field for them and I need to know what the decimal equivalents that you can't go past are. Like 32-bit signed integers can't go above 2147483647 or below -2147483648.

Should be 1.2E-38 to 3.4E+38, assuming it's the same as any C language. The data sheets don't have it, but if that's the upper limit of a long, I'd imagine 32-bit floats follow the same conventions.

 

[Achilles1515]

Should be 1.2E-38 to 3.4E+38, assuming it's the same as any C language. The data sheets don't have it, but if that's the upper limit of a long, I'd imagine 32-bit floats follow the same conventions.

I think that's what Wikipedia says

 

[SinsOfApathy]

I think that's what Wikipedia says

I went with Cplusplus tutorials, cause I always forget the length of data types larger than an signed integer.

 

[Achilles1515]

grGroundParam

0B0     Pointer to background music table
0B4     Number of stage variations with different Stage IDs

Music Table

00     Stage ID (different variations have different IDs)
04     BGM ID
08     Alternate BGM ID ( =0xFFFFFFFF if no alt BGM)
0C     BGM ID (again?)
10     Alternate BGM ID (again?)
14     Value used to pull an address from a pointer table to know where to branch to within the alt music function
       halfword, =0x0006 for stages with alt music, =0x0000 for stages with no alt music
16     Percent chance of getting alternate music
       halfword, =0x000c (12%) as default, =0x0001 for stages with no alt music

[Next Stage Variation Info]
64     Stage ID
...

I do not have a list of the BGM IDs. I do know that
Menu1 = 0x34
Menu2 = 0x36
Trophy = 0x35
Pokemon Battle Theme = 0x3F
Pokemon Stadium = 0x40

@ Dan Salvato @ CeLL

 

[Tcll]

ok, so I've started looking into stage data and am having a bit of trouble trying to figure out the header (map_head)...

I'm using GrTSk.dat as the smallest stage...
here's the header struct as given by HexEdit: (pointers marked in green)

00 00 00 2C 00 00 00 01
00 00 00 3C 00 00 00 03 00 00 00 00 00 00 00 00
00 00 00 D8 00 00 00 10 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00

I just need to know what does what
thanks

 

[shuall]

I can give you a lot of structural info on the file, like all the different structs found in a map file and how to read them, but I don't know what they do in the game, and I've just named them MapHeadA, MapHeadB, etc.

For instance, each of those pointers point to arrays of different types of structs, and the numbers after them are the size of the array.
EDIT: but I imagine there's an increasing amount of people who can do this, yourself included.

 

[Tcll]

I can give you a lot of structural info on the file, like all the different structs found in a map file and how to read them, but I don't know what they do in the game, and I've just named them MapHeadA, MapHeadB, etc.

For instance, each of those pointers point to arrays of different types of structs, and the numbers after them are the size of the array.
EDIT: but I imagine there's an increasing amount of people who can do this, yourself included.

that's fine, I just need to write vars and know how the structures work
got any structure overview notes anywhere??

 

[Achilles1515]

that's fine, I just need to write vars and know how the structures work
got any structure overview notes anywhere??

Doesn't Yax have some general documentation about this on his google page from the comments on the first page of this thread?

 

[Tcll]

thanks achilles
I'd only read the page about half way through before getting a tad steamed about the lack of good docs on this.

 

[shuall]

that's fine, I just need to write vars and know how the structures work
got any structure overview notes anywhere??

I made up a rough doc, I've been meaning to add these to my and your file specs. parse.txt is some notes on reading some weird structs.

I can make up a post, but I want to do some runtime analysis to figure out what the non-pointers are.
I know achilles posted about the use of one of the structs which I think is my MapHeadB. (EDIT: GroundParam, and GroundParamA, you were the one with questions about the struct I will call MapHeadB until a more descriptive name is formulated).

 

[Tcll]

sweet, thanks
I should have something working tomorrow with this! =D

EDIT:
btw shuall, you might want to update your terms in your docs with this info
http://wiki.tockdom.com/wiki/HAL_DAT_(File_Format)

 

[Tcll]

BOOM!


EDIT:
more stuff here:
http://smashboards.com/threads/univ...velopment-thread.334292/page-11#post-18908735

 

[shuall]

I made up a rough doc, I've been meaning to add these to my and your file specs. parse.txt is some notes on reading some weird structs.

I can make up a post, but I want to do some runtime analysis to figure out what the non-pointers are.
I know achilles posted about the use of one of the structs which I think is my MapHeadB. (EDIT: GroundParam, and GroundParamA, you were the one with questions about the struct I will call MapHeadB until a more descriptive name is formulated).

Just to stress this is still a WIP, it is perfectly correct for a handful of Gr* files, gets 2 or 3 things wrong on a bunch others, and in a couple reads a lot of stuff wrong.
I know MapHeadC's are getting read in places they aren't, so one of the structs has a relevant flag somewhere I need to figure out.
Also, I've found some more pointers on the MapHeadB struct that I need to describe.
Most Pl* costume files are described perfectly by these. Haven't looked much into the *AJ or It* files, that's next after Gr* is done. Maybe Pl??.dat fighter files as well.
Lastly, without runtime analysis, which thankfully a lot of you are doing, I won't know what the non-pointers are, so they will just be 'unknown0x34' etc, and the structs will all be undescriptively named after their rootnode strings + {A,B,C,...}.
When I'm done, I'll update Tcll's wiki and my spec docs.

 

[Tcll]

many thanks

also, why not help me improve my DAT script??
https://copy.com/GhS6PAbuBH7MedUI (alot of the stuff here needs to be redone)
you got skype right??
add me: Tcll5850 (DarkPikachu)
I'll share my synced repo with you

also, I intend to port my script to use the UT functions, meaning no more transformation code in my script

 

[shuall]

many thanks

also, why not help me improve my DAT script??
https://copy.com/GhS6PAbuBH7MedUI (alot of the stuff here needs to be redone)
you got skype right??
add me: Tcll5850 (DarkPikachu)
I'll share my synced repo with you

also, I intend to port my script to use the UT functions, meaning no more transformation code in my script

Nice, you should stick you code up on github/bitbucket/something, it might make it easier for people to view it and submit patches. Not google code though, I think google is trying to kill that.

 

[Tcll]

Nice, you should stick you code up on github/bitbucket/something, it might make it easier for people to view it and submit patches. Not google code though, I think google is trying to kill that.

oh trust me, I have plans to place the release on GH

F G-code XD
ever since I could DL a zip of my repo on GH, G-code was thrown in the trash :3

and yes, google is kill it, which tbh, I praise, SVN sucks

I don't really care for the idea of pull requests though...
if you'd get on skype, I'd share my info with you on a synced development environment with file histry.

I stress that if you're doing anything big, make a local copy to work on, and then patch the public copy when finished.

if anything goes wrong, I can always revert back to previous edits

 

[shuall]

Anyone understand how the secondary root nodes* in GrPs files work?
They have offsets to strange places in the file (like an offset to a Joint right in the middle of some other struct; it is clearly not a Joint), and I first though the secondary root nodes in GrPs1,Ps2,Ps3 etc were pointing to offsets in GrPs.dat, but that doesn't seem to be the case.

They're making me think about whether we are making incorrect assumptions on secondary root nodes in other files like Pl**, etc.

*by "secondary root nodes" I am referring to the second array of root nodes specified by the 4 byte value at 0x10 in the header.

 

[Tcll]

ah, reference nodes
@revel8n knows a thing or 2 about them

 

[shuall]

Wait a second, I think I understand, at least in the GrPs files, the second list, is the offset of some offset, similar to the relocation table, but the name is to whatever struct the offset *should* point to.
So, I'm guessing there is some list of named structs like "GrdPStadiumWater_TopN_joint" that is stored at runtime with absolute memory offsets, and the proper way to read the secondary table is to look up these named structs which should already be loaded into memory, and replace the offset in the data block that is pointed to by the secondary (reference) node with the correct memory address.

EDIT: Also, semi-related to this topic, but more to dat files in general.
Joint structs with flags == 4008, or with the 14th bit set (with 1 == flag 0), have alternate JointData (or tcll's Object) structs.
Similarly, I've found that Joints with flags == 1005088 will end their next list with an unknown struct of pointers. So Joint->next->next->next->etc until next is 0, the last Joint in the next list will have a list of offsets after it. I'm pretty sure it's one of the flags, because some next linked lists don't end in this list, but 10050088 all end in them.

ex: GrBb.dat : (aff28 Joint), 'next' linked list ends at (b0028 Joint) with (b0068 Unknown) having a single offset aff28, our starting Joint.
I'm pretty sure this is my MapDataFtr struct, but I have to look more into it. That's my update for now.