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

Dan Salvato · Oct 8, 2012

This is not a user-friendly guide.
Unless you are an experienced user, please
do not expect to get anything out of this.

Alright, so I started exploring stage files recently, and this thread will serve as an info dump for everything I have learned and discovered.
Note that most of the information currently in this thread has likely been discovered by others (such as Tcll and Milun), but sadly, there is no existing documentation, so I am re-discovering everything.

Stage files are prefixed by "Gr". Here is a list of all stage files:

[COLLAPSE="Stage files"]

Code:

FILE            STAGE

GrBb.dat        Big Blue
GrCn.dat        Corneria (JP)
GrCn.usd        Corneria (US)
GrCs.dat        Princess Peach's Castle
GrEF1.dat       Trophy 1
GrEF2.dat       Trophy 2
GrEF3.dat       Trophy 3
GrFs.dat        Fourside
GrFz.dat        Flat Zone
GrGb.dat        Great Bay
GrGd.dat        Kongo Jungle
GrGr.dat        Green Greens
GrHe.dat        All-Star safe room
GrHr.dat        Home-Run Contest (JP)
GrHr.usd        Home-Run Contest (US)
GrI1.dat        Mushroom Kingdom
GrI2.dat        Mushroom Kingdom 2
GrIm.dat        Icicle Mountain
GrIz.dat        Fountain of Dreams
GrKg.dat        Jungle Japes
GrKr.dat        Brinstar Depths
GrMc.dat        Mute City
GrNBa.dat       Battlefield
GrNBr.dat       F-Zero adventure mode race
GrNFg.dat       Bonus Stage (collect trophies)
GrNKr.dat       Mushroom Kingdom adventure mode stage
GrNLa.dat       Final Destination
GrNPo.dat       ??
GrNSr.dat       Hyrule adventure mode stage
GrNZr.dat       ??
GrOk.dat        Kongo Jungle 64
GrOp.dat        Dream Land 64
GrOt.dat        Onett (JP)
GrOt.usd        Onett (US)
GrOy.dat        Yoshi's Story 64
GrPs.dat        Pokemon Stadium (JP)
GrPs.usd        Pokemon Stadium (US)
GrPs1.dat       Pokemon Stadium transform 1
GrPs2.dat       Pokemon Stadium transform 2
GrPs3.dat       Pokemon Stadium transform 3
GrPs4.dat       Pokemon Stadium transform 4
GrPu.dat        Poke Floats
GrRc.dat        Rainbow Cruise
GrSh.dat        Hyrule Temple
GrSt.dat        Yoshi's Story
GrTCa.dat       TT: Captain Falcon
GrTCl.dat       TT: Young Link
GrTDk.dat       TT: Donkey Kong
GrTDr.dat       TT: Dr. Mario
GrTe.dat        "TEST" stage
GrTFc.dat       TT: Falco
GrTFe.dat       TT: Roy
GrTFx.dat       TT: Fox
GrTGn.dat       TT: Ganondorf
GrTGw.dat       TT: Mr. Game & Watch
GrTIc.dat       TT: Ice Climbers
GrTKb.dat       TT: Kirby
GrTKp.dat       TT: Bowser
GrTLg.dat       TT: Luigi
GrTLk.dat       TT: Link
GrTMr.dat       TT: Mario
GrTMs.dat       TT: Marth
GrTMt.dat       TT: Mewtwo
GrTNs.dat       TT: Ness
GrTPc.dat       TT: Pichu
GrTPe.dat       TT: Peach
GrTPk.dat       TT: Pikachu
GrTPr.dat       TT: Jigglypuff
GrTSk.dat       TT: Sheik (test stage)
GrTSs.dat       TT: Samus
GrTYs.dat       TT: Yoshi
GrTZd.dat       TT: Zelda
GrVe.dat        Venom (JP)
GrVe.usd        Venom (US)
GrYt.dat        Yoshi's Island
GrZe.dat        Brinstar

[/COLLAPSE]

For practice or testing, I recommend "GrTFe.dat", Roy's Target Test stage. It's the second smallest stage, and it's better than "GrTSk.dat" because it actually has textures and multiple stage objects. Any examples I list in this post will reference GrTFe.dat, so feel free to follow along.

IMPORTANT NOTE: Add 0x20 to ALL pointers unless otherwise specified, because the file header is 0x20 in size.

[Header and String Table]

Code:

HEADER
00: File size
04: Pointer to pointer table
08: Number of pointer table entries
0C: Number of bases (those strings at the bottom)
10: Number of refs (?)
14: Stages have '30 30 31 42' here, a couple other files do as well
20: Data starts here

The strings at the bottom of the file are very important. Stage files have a table which match up these strings to pointers, where we can find the relevant information. To get to the string table:
Go to offset (pointer to pointer table) + (number of pointer table entries * 4)

For instance, in GrTFe.dat:
Pointer to pointer table: 00 01 6F E0
Number of pointer table entries: 00 00 02 2B
(16FE0) + (22B * 4) = 1788C

So, the string table starts at 1788C (Remember to add 0x20, to get 178AC). To check your work, the value there is: 00 01 3D B0

So, now you have the string table. It works like this:

Code:

0: Pointer to data
4: String offset

This repeats until the end of the table. If you're writing a program to read these automatically, you can use the value at address '0C' in the header to get the number of these. In this case, that value is, well, '0C', so we know there will be 12 strings.
By "String offset" I mean the number of bytes from the start of the first string. So, the first letter of the first string is offset 00. Here is the string table for GrTFe.dat:

Code:

00 01 3D B0   00 00 00 00   ALDYakuAll
00 01 64 00   00 00 00 0B   GrdTargetBack00_CMPR_image
00 01 54 00   00 00 00 26   GrdTargetEmblemFloorA_CMPR_image
00 01 4C 00   00 00 00 47   GrdTargetEmblemFloorB_CMPR_image
00 01 5C 00   00 00 00 68   GrdTargetEmblemFloorD_CMPR_image
00 01 3C 1C   00 00 00 89   coll_data
00 01 3C AC   00 00 00 93   grGroundParam
00 01 3D 88   00 00 00 A1   itemdata
00 00 01 60   00 00 00 AA   map_head
00 01 49 00   00 00 00 B3   map_plit
00 01 6F C8   00 00 00 BC   quake_model_set
00 01 3D 90   00 00 00 CC   yakumono_param

Now we have pointers to a whole bunch of neat things! That's it for this section; the following sections will make sense of some of these. Note that there are additional types not listed here; GrTFe.dat doesn't make use of every type.

[map_head]

I don't yet fully understand this format, but this is everything I know.

This area contains object and arena information, including:
-Object nodes for stage elements (holding size, position, and properties of each object)
-Blast zones and camera boundaries
-Spawn and halo locations
This does NOT contain collision data, so moving a platform with this alone will not work. However, aesthetic elements that do not have collision boxes can be moved freely.

To edit stage elements, you travel like this:
map_head --> object group --> head node --> keep going to "child" or "next" nodes until you find the one you want to edit

In our GrTFe.dat example, our string table tells up map_head is at: 00 00 01 60. So, go to address 0x180 (since we add 0x20) to get object group pointers. You'll find a format like this:

Code:

0: Pointer to object group
4: ID?

This repeats until we hit 00 00 00 00. In GrTFe.dat, it looks like this:

Code:

00 00 00 54   00 00 00 02
00 00 00 74   00 00 00 03

This means we have one object group at address 0x54 and another at address 0x74. I do not yet know what the additional ID value is for.

So, now we go to our object groups. The object group follows this format:

Code:

0: Pointer to head node
4: ??
8: ??

I know 4 and 8 are important, but I don't yet know what they are for. Anyway, GrTFe.dat looks like this at the first address:

Code:

00 00 C9 88 00 00 00 00 00 00 00 0E

And at the second address:

Code:

00 01 49 E0 00 00 00 00 00 00 00 00

So, one of our object groups begins at 0xC988, and the other begins at 0x149E0. (Don't forget to add 0x20 when navigating to these.)

For our example, let's go to 0x149E0. This is the node tree for a bunch of stage-related nodes, including camera boundaries, blast zones, character spawns, halo spawns, and item spawns. I figured this out by trial and error, but I'm pretty sure there's some kind of ID or label in the stage file that tells you what's what - I just have yet to find it.

The node structure looks like this:

Code:

0: Empty
4: flags
8: pointer to child node
C: pointer to next node
10: pointer to node data
14: RotateX
18: RotateY
1C: RotateZ
20: SizeX
24: SizeY
28: SizeZ
2C: LocationX
30: LocationY
34: LocationZ
38: inverse (??)
3C: Empty

The X, Y, and Z values are all 32-bit floats. "Pointer to node data" is used for joints and polygons, so this will always be "00000000" in our example.

Usually, the head node contains a "child" but not a "next". Changing values in the head node affect its child nodes as well, so this is usually undesirable as you're moving around the whole stage instead of just single elements. Some more complex stages might contain a more complex hierarchy with multiple parent/child nodes, but I haven't seen this yet. Generally, the head node branches to a "child" and from there, you see no more children, but all "next" nodes. The last node has no child and no next, so that's how you know you've reached the end of the node tree.

I don't yet know what the flags are for.

Here is my map of node tree 0x149E0 in GrTFe.dat; see if you can follow along. Again, I determined what node does what simply by changing values and loading the stage to see what's different.
[COLLAPSE="GrTFe.dat Node Tree 1"]

Code:

		Node 1 (Parent Object)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: 14A20
		Next: None
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 00
		LY: 00
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 2 (??)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 14A60
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 00
		LY: 00
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 3 (Left/top camera boundary)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 14AA0
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: C320
		LY: 433E
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 4 (Right/bottom camera boundary)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 14AE0
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 430C
		LY: C2F0
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 5 (Left/top blast zone)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 14B20
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: C348
		LY: 4352
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 6 (Right/bottom blast zone)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 14B60
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 4334
		LY: C320
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 7 (Spawn point 1)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 14BA0
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 00
		LY: 4170
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 8 (Halo point 1)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: None
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 00
		LY: 41A0
		LZ: 00
		inverse: 00
		Unk2: 00

[/COLLAPSE]
More complex stages contain more nodes, such as more player spawns, more player halos, and item spawns. Again, I have no idea how the game determines which node is which, especially when different stages have different numbers of nodes in different orders.

As reference, here is Mushroom Kingdom II which contains a more complex node tree, with more spawns.

[COLLAPSE="GrI2.dat Node Tree 1"]

Code:

		Node 1 (Parent object)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: 15EC8
		Next: None
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 3649539C
		LY: B68637BD
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 2 (??)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 15F08
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 00
		LY: 00
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 3 (Left/top camera boundary)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 15F48
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: C316
		LY: 4310
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 4 (Right/bottom camera boundary)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 15F88
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 4318
		LY: C238
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 5 (Left/top blast zone)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 15FC8
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: C356
		LY: 4372
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 6 (Right/bottom blast zone)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 16008
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 4356
		LY: C2E4
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 7 (Item spawn 1?)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 16048
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 00
		LY: 41F00002
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 8 (Item spawn 2?)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 16088
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: C1F0
		LY: 41F00002
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 9 (Item spawn 3?)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 160C8
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 41F0
		LY: 41F00002
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 9 (Item spawn 4?)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 16108
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: C2B4
		LY: 42700001
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 10 (Item spawn 5?)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 16148
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 42B4
		LY: 42700001
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 11 (Item spawn 6?)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 16188
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: C307
		LY: 42A00001
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 12 (Item spawn 7?)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 161C8
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 4307
		LY: 42A00001
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 12 (Spawn point 1)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 16208
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: C1F00002
		LY: 40E00000
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 13 (Spawn point 2)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 16248
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 41F00000
		LY: 40E00000
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 14 (Spawn point 3)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 16288
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: C2BE0000
		LY: 42140000
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 15 (Spawn point 4)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 162C8
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 42BE0000
		LY: 42140000
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 16 (Halo point 1)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 16308
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 00
		LY: 42960000
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 17 (Halo point 2)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 16348
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 00
		LY: 42960000
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 18 (Halo point 3)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: 16388
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 00
		LY: 42960000
		LZ: 00
		inverse: 00
		Unk2: 00
		
		Node 19 (Halo point 4)
		Unk1: 00 00 00 00
		Flags1: 00 00 00 08
		Child: None
		Next: None
		Data ptr?: 00
		RX: 00
		RY: 00
		RZ: 00
		SX: 3F80
		SY: 3F80
		SZ: 3F80
		LX: 00
		LY: 42960000
		LZ: 00
		inverse: 00
		Unk2: 00

[/COLLAPSE]
Also note that I listed many XYZ values as 16-bit values instead of 32-bit. I did this to be concise. "3F80" is really "3F800000", for example.

There are always at least two object groups, one for stage objects and another for camera, blast zone, and spawn objects. The only way I currently know to figure out which is which is simply by experimenting; change the size or position of objects, load the level, and see what changes. Using the Dolphin emulator, save states, and an extracted Melee iso, this can be done quite rapidly. However, I hope to soon figure out how the stage file knows which node is which, and I will write here when I do.

[grGroundParam]

I am currently working on deciphering the values of the grGroundParam section. I haven't yet figured out what all the values are for. Here is a table of grGroundParam values from GrTFe.dat which I will regularly update with my findings. Values with a "?" are ones which have not yet been verified.

[COLLAPSE="GrTFe.dat grGroundParam table"]

Code:

000	3F 80 00 00	Entire stage size
004	00 C0 00 00
008	00 0A 00 00
00C	00 00 03 20
010	00 00 04 4C
014	FF FF FF F6	?Minimum tilt & tilt scaling
018	00 00 00 00	?Horizontal rotation factor
01C	00 00 00 00	?Vertical rotation factor
020	40 00 00 00	"Fixed"-ness of camera - higher is more fixed
024	3F 80 00 00	?Character bubble buffer multiplier OR character bubble front mult.
028	3F E6 66 66	Camera speed smoothness - higher is tighter
02C	00 00 00 0A	?Unknown 1
030	00 00 05 78	?Pause minimum Z position
034	00 00 05 DC	?Pause initial Z position
038	00 00 05 DC	?Pause max Z position
03C	00 00 00 00
040	00 00 00 00	?Pause max angle up
044	00 00 00 00	?Pause max angle left
048	00 00 00 00	?Pause max angle right
04C	00 00 00 00	?Pause max angle down
050	C1 70 00 00	?Unknown 3
054	42 F0 00 00	?Unknown 4
058	43 F5 00 00	?Unknown 5
05C	41 F0 00 00	?Unknown 6
060	C1 00 00 00
064	00 00 00 00
068	00 00 00 00
06C	00 00 00 00
070	00 00 00 00
074	00 00 00 00
078	00 00 00 00
07C	00 00 00 00
080	00 00 00 00
084	00 00 00 00
088	00 00 00 00
08C	00 00 00 00
090	00 00 00 00
094	00 00 00 00
098	00 00 00 00
09C	00 00 00 00
0A0	00 00 00 00
0A4	00 00 00 00
0A8	00 00 00 00
0AC	00 00 00 00
0B0	00 01 3C 48	Pointer to ? table
0B4	00 00 00 01	Number of entries in ? table
0B8	07 00 2A FF	Bubble color - top left
0BC	07 00 2A FF	Bubble color - top middle
0C0	07 00 2A FF	Bubble color - top right
0C4	00 07 36 FF	Bubble color - sides top
0C8	00 07 36 FF	Bubble color - sides middle
0CC	00 07 36 FF	Bubble color - sides bottom
0D0	00 12 33 FF	Bubble color - bottom left
0D4	00 12 33 FF	Bubble color - bottom middle
0D8	00 12 33 FF	Bubble color - bottom right
0DC	00 01 48 60
0E0	00 00 00 00
0E4	00 00 00 00
0E8	2C 00 00 06
0EC	03 00 00 00
0F0	00 00 00 00
0F4	05 06 40 00
0F8	05 00 00 07
0FC	10 F4 50 00
000	00 00 00 00
104	00 00 00 00
108	00 01 3D 94
10C	00 00 00 00
110	00 00 00 00
114	42 84 5D F5
118	43 05 4B E4
11C	44 67 7F 7A
120	00 00 00 00
124	00 00 00 00
128	42 84 5D F5
12C	42 21 2D 5C
130	C0 80 F1 24
134	00 00 00 00
138	00 00 00 00
13C	00 00 00 01
140	00 00 02 80
144	00 00 01 E0
148	00 00 02 80
14C	00 00 01 E0
150	00 01 3D BC
154	00 01 3D D0
158	00 00 00 00
15C	00 00 00 00
160	3D CC CC CD
164	47 00 00 00
168	41 D8 00 00
16C	3F 97 0A 3D
170	00 01 3D E4
174	00 00 00 00
178	00 00 00 00
17C	42 84 5D F5
180	43 0A 4B E4
184	44 67 7F 7A
188	00 00 00 00
18C	3F 7D 70 A4
190	46 1C 40 00
194	00 00 00 03
198	00 00 00 00
19C	00 00 00 00
1A0	00 0E 00 00
1A4	FF FF FF FF
1A8	00 01 3E 24
1AC	00 00 00 00
1B0	00 01 3E 38
1B4	00 01 3E 44
1B8	00 00 00 00
1BC	00 00 00 00
1C0	00 00 00 00
1C4	00 04 00 00
1C8	CC CC CC FF
1CC	00 00 00 00
1D0	00 00 00 00
1D4	00 00 00 00
1D8	00 01 3E 68
1DC	00 00 00 00
1E0	00 01 3E 84
1E4	00 01 3E 60
1E8	00 00 00 00
1EC	00 00 00 00
1F0	00 00 00 00

[/COLLAPSE]

Dan Salvato · Oct 8, 2012

Changelog

10/11/2012
-Added grGroundParam table and some accompanying info

10/10/2012
-Added MKII node tree for reference in comparison to Roy TT tree

10/8/2012
-Added map_head and node info

10/7/2012
-Created post, added Header and String Table info

Milun · Oct 9, 2012

Wooooooow. You're doing a lot better than me. I never really bothered with the pointers and oriented myself using the "magnifier data".

Dan Salvato · Oct 9, 2012

Milun said:
Wooooooow. You're doing a lot better than me. I never really bothered with the pointers and oriented myself using the "magnifier data".

Suppose you move a platform with your technique. Does that move both the model and the collision data, or do you have to do both separately?

Milun · Oct 9, 2012

Depends. If the platform is static, like Battlefields, then no. The collisions must be moved separately. BUT, if the platform does move, like the lifts in MK, then yes, the collision comes with them. If you need help finding where collision data is stored, look through my site. Pretty sure I documented it...

Dan Salvato · Oct 9, 2012

Milun said:
Depends. If the platform is static, like Battlefields, then no. The collisions must be moved separately. BUT, if the platform does move, like the lifts in MK, then yes, the collision comes with them. If you need help finding where collision data is stored, look through my site. Pretty sure I documented it...

I already found it, there's a "coll_data" string which points to the node entries. I haven't explored it yet, but that should be it. I'll check the site anyway, though, in case it has information I haven't found.

Milun · Oct 9, 2012

It doesn't have much on how to find the data, but it does cover the different kinds you'll encounter and how to decipher it.

Dan Salvato · Oct 9, 2012

Are you willing to do more stage work? I've already run into some values with which I'm unfamiliar, so if you feel like exploring then I'd appreciate the help. (This goes for anyone else, too. It's quite tiring to go through so much on my own.)

Milun · Oct 9, 2012

I am, unfortunately, not for a few months. I can't really do stages or any big projects while my Uni is on.

Dan Salvato · Oct 10, 2012

I'm currently documenting the GrGroundParam element, which includes stage size, loads of camera parameters including tile angles, focal length, and pause angles, and Milun's bubble color data. It might also contain stage timers but that's only a working theory as of now. There's a lot left to explore in this area.

Fun fact: Battlefield is scaled down to 0.8x its actual size.

Tcll · Oct 10, 2012

I'll be keeping an update on here

nube · Oct 11, 2012

Sup Tcll, its been a while. You and Revel still workin on crackin them models?

OT: I once tinkered with the pause camera's zoom/panning capabilities a bit, but it was all based on Milun's stage information, so it wasn't really anything new. Milun, I wonder your stage documentation is still available on the web somewhere?

InternetExplorer: This thread contains a lot of information that may be helpful. There are many other old model-related threads scattered across this and other boards (Emutalk comes to mind), but the linked thread seems to contain the most complete/thorough documentation.

Massive · Oct 11, 2012

Milun said:
If you need help finding where collision data is stored, look through my site. Pretty sure I documented it...

Assuming your site is http://meleestages.webfreehosting.net/melee.html, it has been down for months.

Dan Salvato · Oct 11, 2012

Massive said:
Assuming your site is http://meleestages.webfreehosting.net/melee.html, it has been down for months.

Milun sent me an archive file of the website.

Also, Milun, you may be interested in looking at the grGroundParam section, as it contains your "magnifier data", but in actual context to the rest of the section. If you know anything that I may find around this area, please let me know.

Tcll · Oct 12, 2012

nube said:
Sup Tcll, its been a while. You and Revel still workin on crackin them models?

oh please XD
I've been keeping updated over at KC-MM as that's the only website I can access by phone... sadly...

and I can't seem to get in contact with Revel8n...
I've tried countless time via email and chat since I sent him UMC 3.0a dev1

and for even more sad news (but not entirely)
I'm not touching the scripts for a while since I'm working on my GUI =D

check this out:

I do intend to get back into the scripts and hope to add stage support as well

Dan Salvato · Oct 12, 2012

Looks pretty sweet. At some point I'd like to write my own Python app for stage dissecting and editing. Perhaps we can combine the two to support advanced stage editing and texture replacement?

Tcll · Oct 13, 2012

InternetExplorer said:
Looks pretty sweet. At some point I'd like to write my own Python app for stage dissecting and editing. Perhaps we can combine the two to support advanced stage editing and texture replacement?

I would like to add mod support to turn this thing into somewhat of a decent editor...
but I don't know where to start yet. XD

meh... I'm currently looking at ideas toward implamenting my own scripting language using node-based programming...
see here: http://blenderartists.org/forum/showthread.php?256747-The-Hive-system-version-0-83-released

this is intended for use with converting Python game-scripts to Wii .elf files
(I do intend to support many other programming languages as well)

hey IE =D
you know a good portion of ASM...
maybe you could help us out by explaining how certain aspects of the script properties should work

such as the aspects I described over at BA which I need help with... :3

Dan Salvato · Oct 14, 2012

Tcll said:
I would like to add mod support to turn this thing into somewhat of a decent editor...
but I don't know where to start yet. XD

meh... I'm currently looking at ideas toward implamenting my own scripting language using node-based programming...
see here: http://blenderartists.org/forum/showthread.php?256747-The-Hive-system-version-0-83-released

this is intended for use with converting Python game-scripts to Wii .elf files
(I do intend to support many other programming languages as well)

hey IE =D
you know a good portion of ASM...
maybe you could help us out by explaining how certain aspects of the script properties should work
such as the aspects I described over at BA which I need help with... :3

Sadly, I am completely incapable of writing ASM apps from scratch and I have no knowledge of the Wii SDK. However, since the Wii SDK is in fact available, you should do some research on that, as well as some other existing homebrew apps.

Tcll · Oct 14, 2012

InternetExplorer said:
Sadly, I am completely incapable of writing ASM apps from scratch and I have no knowledge of the Wii SDK. However, since the Wii SDK is in fact available, you should do some research on that, as well as some other existing homebrew apps.

I've been trying...

GX is almost exactly like OpenGL except for the vertex attributes...
GX adds that for even greater efficiency over OpenGL.
(yes, GX is better than GL)

but there's a few problems keeping me from building my revolution library for UMC...
I can't really understand C++ too well, and the SDK only includes header files...

I'm guessing the src files are already pre-compiled in CW_RVL >_>

I'm nowhere near capable of being able to read .dol files yet >_>

but hey...
I'm not asking you to write an app...
I'm just asking you to use what you know

heh... that's what I'm doing ^_^

I still have yet to implament dynamic meshes into UMC... XD
(I still cant get the curve generation aglorithm correct)

if you havn't guessed, I want UMC to turn more than just into a global game editor and converter...
I want this thing to be able to support AII and dynamic sound generation as well.
(stuff to be supported by my game system)

imagine that XDD

Dan Salvato · Oct 14, 2012

If you need to generate graphics using ASM, then I have no idea how. All I know about PPC ASM is the instruction set and what each instruction does. I don't know anything about the Wii's library of ASM routines.

Tcll · Oct 14, 2012

hmm...

I have a PDF of the IBM Gekko (GCN) CPU
but I just read of the IBM Broadway (WII) CPU

for what I know, the Broadway was a derivative of the Gekko,
so if I'm right, they should have near the same architecture

here it is: (the wii CPU)
http://raidenii.net/files/datasheets/cpu/ppc_broadway.pdf

all you had to do was ask XDD

but anyways... I was asking for my language...
since my language works off of ASM to produce script blocks, which in turn produce code...
the script blocks also break down code to be broken down into ASM...

but IDK anything about ASM which is why I'm asking for your help

if you're willing to help, I'll see you on BA

Dan Salvato · Oct 14, 2012

Taking a minor break from stage hacking to work on school, then Project M. I'll continue after a couple weeks from now.

Tcll · Feb 20, 2013

lemme know when you get back...

I'd like to know how to load the stage files properly

Dan Salvato · Feb 21, 2013

I don't know enough about the format to help much. I won't be working on this for a while, probably.

Tcll · May 10, 2013

GrNZr.dat is the countdown level after you beat samus in adventure mode

and I'm not sure, but I think GrNPo.dat is the "race to the finish" level

Yax · Feb 9, 2014

Hi, I have been working on stage hacking recently and this thread has been REALLY helpful.

I put everything I learnt from this thread and all my discoveries in this google drive:
https://docs.google.com/spreadsheet...ZqVi0wWlkxZlhVZFdHb1lDckE&usp=drive_web#gid=0

There are a lot of things missing but I hope it will help people who want to work on stage editing and maybe some people will complete it.

Still, it's a good base and here is what I could do with it:
https://www.youtube.com/watch?v=Tlqa9syye8Q

Achilles1515 · Feb 8, 2015

@

CeLL

Could you write a program to spit out the String Table pointers like Dan talks about at the very beginning of this thread? It's a super simple process, just becomes tedious to do manually when there are a s**t ton of strings at the end of a file (like mushroom kingdom adventure for example). Melee Toolkit automatically does this process, but the program can't open up every dat file for whatever reason.

I feel like this would be pretty simple for you.

Tcll · Feb 8, 2015

achilles1515 said:
but the program can't open up every dat file for whatever reason.

the program was built on the old string method designed by Revel8n which isn't expected to work with everything...
it's probably coughing on the image names for the root nodes.

I was working on some templates for HexEdit, though I'm turning away from that now since my new working pathfinder method causes HexEdit to freeze upon loading a large DAT file such as PlPkNr.dat
but it can load small DAT files just fine.

my old HexEdit template requires design mode enabled for some reason before it'll display everything properly...

have you been following my HAL_DAT format page??
http://wiki.tockdom.com/wiki/HAL_DAT_(File_Format)
that should help out with finding the string pointers

EDIT:
hey @

Yax : how come you didn't document that on my page?? :3
could've sworn I mentioned it before with you around...

lol

CeLL · Feb 9, 2015

achilles1515 said:
@ CeLL

Could you write a program to spit out the String Table pointers like Dan talks about at the very beginning of this thread? It's a super simple process, just becomes tedious to do manually when there are a s**t ton of strings at the end of a file (like mushroom kingdom adventure for example). Melee Toolkit automatically does this process, but the program can't open up every dat file for whatever reason.

I feel like this would be pretty simple for you.

Yeah, pretty simple, but how do you find the offset of the strings at the bottom? Like the offset of the first character, in the case of GrTFe.dat, "A"
I can't seem to find it in Dan's post.

Edit: nvm it's immediately following the string table

Edit 2: nvm apparently that's not always true? At this point that's the only non-functional part of the program.

CeLL · Feb 16, 2015

@

Achilles1515

Sorry, I got sidetracked on textures and was out of town since Thursday.

So in some files there's a bit of stuff between the end of the string table and the start of the actual strings, and I have no idea what it is. So if it doesn't have this stuff, then it can get the strings fine automatically, but if it does, you have to check the checkbox and put in the offset of where the actual strings start, i.e. the offset of the first A in ALDYakuAll for GrTFe.dat. Easy enough to scroll to the bottom and just look to see where they start.

http://www.mediafire.com/download/cus9b8e101e19ld/String_Table.zip

shuall · Feb 17, 2015

CeLL said:
@ Achilles1515

Sorry, I got sidetracked on textures and was out of town since Thursday.

So in some files there's a bit of stuff between the end of the string table and the start of the actual strings, and I have no idea what it is. So if it doesn't have this stuff, then it can get the strings fine automatically, but if it does, you have to check the checkbox and put in the offset of where the actual strings start, i.e. the offset of the first A in ALDYakuAll for GrTFe.dat. Easy enough to scroll to the bottom and just look to see where they start.

http://www.mediafire.com/download/cus9b8e101e19ld/String_Table.zip

which files have stuff in between string table and start of strings? How are you calculating the start of the string table?

GrTe.dat: { datasz = 0x95760, relocation table num = 11761 (0x2df1), root nodes (section headers, whatever) = 13 (0xd) primary, 1 secondary } -> 20 + 95760 + 2df1*4 + (d+1)*8 = a0fb4, which is where the string table starts.

EDIT: ( https://drive.google.com/open?id=1TIFquuPCrFEANPAH_CM7A138SX07BQ3c4Q2Wms5I1OU&authuser=0 plug for my WIP dat file specification, has info like header layout, file layout etc. Currently working on trying to give names to matanim_joint structures, and adding some map_coll structures. ) EDIT2: just noticed Tcll 's page too. Ha, we'll have to consolidate, and work on consistent names.

Though I just noticed GrTe.dat has another value in it's header, interesting. Anyone know what the data after the secondary root number is? I've got it as 0x30303142 as a 4 byte word, which doesn't mean much to me.

CeLL · Feb 17, 2015

shuall said:
which files have stuff in between string table and start of strings? How are you calculating the start of the string table?

GrTe.dat: { datasz = 0x95760, relocation table num = 11761 (0x2df1), root nodes (section headers, whatever) = 13 (0xd) primary, 1 secondary } -> 20 + 95760 + 2df1*4 + (d+1)*8 = a0fb4, which is where the string table starts.

EDIT: ( https://drive.google.com/open?id=1TIFquuPCrFEANPAH_CM7A138SX07BQ3c4Q2Wms5I1OU&authuser=0 plug for my WIP dat file specification, has info like header layout, file layout etc. Currently working on trying to give names to matanim_joint structures, and adding some map_coll structures. ) EDIT2: just noticed Tcll 's page too. Ha, we'll have to consolidate, and work on consistent names.

Though I just noticed GrTe.dat has another value in it's header, interesting. Anyone know what the data after the secondary root number is? I've got it as 0x30303142 as a 4 byte word, which doesn't mean much to me.

Oh wow that fixes it. I was just using Dan's post and he doesn't mention adding the value at 0x10. Updated link above.

Tcll · Feb 17, 2015

wait a minute, GrTe has a reference node?? =o

shuall said:
just noticed Tcll 's page too. Ha, we'll have to consolidate, and work on consistent names.

if you're talking about the 3D termage, I went with UMC's termage to make things less confusing.
and the structures like Bone > Object > Mesh was based off these terms.

UMC's termage comes from a compilation of the terms of various 3D formats.
Wavefront OBJ files have the cleanest termage and syntax, though this conflicts with OpenGL termage.

I renamed "Polygon" to "Object" because that's how Blender, and alot of common formats including OBJ identifies them.
"Mesh" is only the sub-data of the object.
(the sub-data can be anything from a light to a NURBS)

'Facepoint' names what's commonly called "vertex" among 3D standards, and was derrived from OBJ facepoints, and blender faces
'Vert' names the "vertex position" or "vertice", and is also called "vertex" in collada format

there's more than that, but those are the largest applications.
ImaginaryZ has a problem understanding these... heh
(I personally can't see how you can mistake these if you know the difference between a face/polygon and a vertice/position)

so yea, my terms are the sensible results from a compilation of a bunch of terms.

shuall · Feb 17, 2015

Tcll said:
wait a minute, GrTe has a reference node?? =o

if you're talking about the 3D termage, I went with UMC's termage to make things less confusing.
and the structures like Bone > Object > Mesh was based off these terms.

UMC's termage comes from a compilation of the terms of various 3D formats.
Wavefront OBJ files have the cleanest termage and syntax, though this conflicts with OpenGL termage.

I renamed "Polygon" to "Object" because that's how Blender, and alot of common formats including OBJ identifies them.
"Mesh" is only the sub-data of the object.
(the sub-data can be anything from a light to a NURBS)

'Facepoint' names what's commonly called "vertex" among 3D standards, and was derrived from OBJ facepoints, and blender faces
'Vert' names the "vertex position" or "vertice", and is also called "vertex" in collada format

there's more than that, but those are the largest applications.
ImaginaryZ has a problem understanding these... heh
(I personally can't see how you can mistake these if you know the difference between a face/polygon and a vertice/position)

so yea, my terms are the sensible results from a compilation of a bunch of terms.

Oh, I wasn't criticizing you, I was commenting that there are a lot of different posts and resources that call the different data structures different names. Root nodes = root structure = section headers as an example (Bone = joint is a more classic example not particular to melee). Hopefully it's not too confusing to people reading the guides seperately.

Tcll · Feb 17, 2015

> Oh, I wasn't criticizing you

haha, don't worry, I was only taking what you said as a statement

I was only providing extra info to show my knowledge with my comparisons.

> (Bone = joint is a more classic example not particular to melee)

I've ran into this

same for weights vs skin

EDIT:
btw, you'll find most of the terms were originally by Revel8n, overwritten by my comparisons

Achilles1515 · Feb 23, 2015

CeLL said:
@ Achilles1515

Sorry, I got sidetracked on textures and was out of town since Thursday.

So in some files there's a bit of stuff between the end of the string table and the start of the actual strings, and I have no idea what it is. So if it doesn't have this stuff, then it can get the strings fine automatically, but if it does, you have to check the checkbox and put in the offset of where the actual strings start, i.e. the offset of the first A in ALDYakuAll for GrTFe.dat. Easy enough to scroll to the bottom and just look to see where they start.

http://www.mediafire.com/download/cus9b8e101e19ld/String_Table.zip

Dude, Cell…this is phenomenal and exactly what I was looking for!! Thank you so much.

Are you willing to make additions to this program? I could see it becoming an amazing tool for stage hacking if we combine info from IE, Yax, Milun, zankyou, and everyone else. Although eventually ideal, I’m not talking about adding a bunch of functionality for an all-in-one viewer and editor – just an easy info viewer/decipherer.

First off, are you able to make some sort of drop down box to the left of each of these strings that can give more information/important offsets from each item? Something like this:

For example, every stage has the grGroundParam and offsets of interest from this location include these items (copied from the main post, this is from GrTFe):

Code:

000  3F 80 00 00  Entire stage size

004  00 C0 00 00

008  00 0A 00 00

00C  00 00 03 20

010  00 00 04 4C

014  FF FF FF F6  ?Minimum tilt & tilt scaling

018  00 00 00 00  ?Horizontal rotation factor

01C  00 00 00 00  ?Vertical rotation factor

020  40 00 00 00  "Fixed"-ness of camera - higher is more fixed

024  3F 80 00 00  ?Character bubble buffer multiplier OR character bubble front mult.

028  3F E6 66 66  Camera speed smoothness - higher is tighter

02C  00 00 00 0A  ?Unknown 1

030  00 00 05 78  ?Pause minimum Z position

034  00 00 05 DC  ?Pause initial Z position

038  00 00 05 DC  ?Pause max Z position

03C  00 00 00 00

040  00 00 00 00  ?Pause max angle up

044  00 00 00 00  ?Pause max angle left

048  00 00 00 00  ?Pause max angle right

04C  00 00 00 00  ?Pause max angle down

050  C1 70 00 00  ?Unknown 3

054  42 F0 00 00  ?Unknown 4

058  43 F5 00 00  ?Unknown 5

05C  41 F0 00 00  ?Unknown 6

060  C1 00 00 00

064  00 00 00 00

068  00 00 00 00

06C  00 00 00 00

070  00 00 00 00

074  00 00 00 00

078  00 00 00 00

07C  00 00 00 00

080  00 00 00 00

084  00 00 00 00

088  00 00 00 00

08C  00 00 00 00

090  00 00 00 00

094  00 00 00 00

098  00 00 00 00

09C  00 00 00 00

0A0  00 00 00 00

0A4  00 00 00 00

0A8  00 00 00 00

0AC  00 00 00 00

0B0  00 01 3C 48  Pointer to ? table

0B4  00 00 00 01  Number of entries in ? table

0B8  07 00 2A FF  Bubble color - top left

0BC  07 00 2A FF  Bubble color - top middle

0C0  07 00 2A FF  Bubble color - top right

0C4  00 07 36 FF  Bubble color - sides top

0C8  00 07 36 FF  Bubble color - sides middle

0CC  00 07 36 FF  Bubble color - sides bottom

0D0  00 12 33 FF  Bubble color - bottom left

0D4  00 12 33 FF  Bubble color - bottom middle

0D8  00 12 33 FF  Bubble color - bottom right

0DC  00 01 48 60

0E0  00 00 00 00

0E4  00 00 00 00

0E8  2C 00 00 06

0EC  03 00 00 00

0F0  00 00 00 00

0F4  05 06 40 00

0F8  05 00 00 07

0FC  10 F4 50 00

000  00 00 00 00

104  00 00 00 00

108  00 01 3D 94

10C  00 00 00 00

110  00 00 00 00

114  42 84 5D F5

118  43 05 4B E4

11C  44 67 7F 7A

120  00 00 00 00

124  00 00 00 00

128  42 84 5D F5

12C  42 21 2D 5C

130  C0 80 F1 24

134  00 00 00 00

138  00 00 00 00

13C  00 00 00 01

140  00 00 02 80

144  00 00 01 E0

148  00 00 02 80

14C  00 00 01 E0

150  00 01 3D BC

154  00 01 3D D0

158  00 00 00 00

15C  00 00 00 00

160  3D CC CC CD

164  47 00 00 00

168  41 D8 00 00

16C  3F 97 0A 3D

170  00 01 3D E4

174  00 00 00 00

178  00 00 00 00

17C  42 84 5D F5

180  43 0A 4B E4

184  44 67 7F 7A

188  00 00 00 00

18C  3F 7D 70 A4

190  46 1C 40 00

194  00 00 00 03

198  00 00 00 00

19C  00 00 00 00

1A0  00 0E 00 00

1A4  FF FF FF FF

1A8  00 01 3E 24

1AC  00 00 00 00

1B0  00 01 3E 38

1B4  00 01 3E 44

1B8  00 00 00 00

1BC  00 00 00 00

1C0  00 00 00 00

1C4  00 04 00 00

1C8  CC CC CC FF

1CC  00 00 00 00

1D0  00 00 00 00

1D4  00 00 00 00

1D8  00 01 3E 68

1DC  00 00 00 00

1E0  00 01 3E 84

1E4  00 01 3E 60

1E8  00 00 00 00

1EC  00 00 00 00

1F0  00 00 00 00

Alright, now I had this idea the other day and it would be….******* incredible. This is veering a little aways from the simpleness of the above stuff, but is something could certainly be an addition to that program.

The Spot Coordinate Viewer

- “Spots” are the terms used for the coordinate points that create the stage geometry. A “link” is the actual ground that is created when a line is drawn from one spot to another.

- Obviously, spots are super important for stage hacking, because if you want to add or remove collisions, you’ll need to edit the spots.

Over in the other stage hacking thread, I posted this image which is the start of the Spot Coordinate Table for Luigi’s Target Stage (the table starts at the first edit I made)

http://smashboards.com/attachments/capture-png.38478/[/IMG]

And it’s really quite simple…spots consist of two 32-bit floating point values, one right after the other. The first value is the X coordinate, and the second is the Y coordinate. And then the next value is the X coordinate of the next spot, etc.

So in the above picture, the spots look like this:

Spot 1: (-80,-80)
Spot 2: (-80,80)
Spot 3: (80,80)
Spot 4: (80,-80)
Etc.

So all these spots basically make up the stage geometry.

THE IDEA:
- And I really don’t think it’s all that farfetch’d…

A program that parses the spot table and
- converts all the 32-bit floating point numbers into decimals so we humans can read them easily
- organizes the values into spot numbers
- (!!) Plots each point onto a graph to get a visual of all the stage coordinates.\

For the beginning, we don’t even need to connect the dots. Just getting a visual of what it looks like would be good enough to know what is going on.

Then you can hover your mouse over a spot on the graph and it will tell you exactly which one it is in the table (spot number * 0x8), so you know what to modify.

This would be the start of amazing stage hacks. Let me know your thoughts on this!

Tcll · Feb 23, 2015

now why hadn't I thought of that '3'
oh right... HexEdit and UMC_SIDE

hey @

CeLL , would that work on Linux or WinXP??

it would help me out on my script for UMC...
HexEdit won't load my new pathfinder w/o freezing...
(note: the pathfinder works with any HAL format, not just Melee)

as for combining info, you guys have my wiki page you can post to

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

I really need more info about stages and such, so please help me out :/

shuall · Feb 23, 2015

Tcll said:
now why hadn't I thought of that '3'
oh right... HexEdit and UMC_SIDE

hey @ CeLL , would that work on Linux or WinXP??

it would help me out on my script for UMC...
HexEdit won't load my new pathfinder w/o freezing...
(note: the pathfinder works with any HAL format, not just Melee)

as for combining info, you guys have my wiki page you can post to
http://wiki.tockdom.com/wiki/HAL_DAT_(File_Format)

I really need more info about stages and such, so please help me out :/

If you want stuff that works on linux, I've got handful of simple c programs that print out dat file strings, the relocation table, headers, root nodes, and any other node type that I've got programmed in at any location in the file. Check it out at https://github.com/shua/dolface and run 'make datbody'. Type the command names without any arguments to get the usage.

In the spirit of unix, it's a collection of small programs that do specific tasks, with output you can pipe through grep, sort, etc. I've added an example script I use instead of hexedit for viewing unknown dat files and their structs called 'insp.sh'.

CeLL · Feb 23, 2015

achilles1515 said:
Dude, Cell…this is phenomenal and exactly what I was looking for!! Thank you so much.

Are you willing to make additions to this program? I could see it becoming an amazing tool for stage hacking if we combine info from IE, Yax, Milun, zankyou, and everyone else. Although eventually ideal, I’m not talking about adding a bunch of functionality for an all-in-one viewer and editor – just an easy info viewer/decipherer.

First off, are you able to make some sort of drop down box to the left of each of these strings that can give more information/important offsets from each item? Something like this:

View attachment 40151

For example, every stage has the grGroundParam and offsets of interest from this location include these items (copied from the main post, this is from GrTFe):

Code:

000 3F 80 00 00 Entire stage size 004 00 C0 00 00 008 00 0A 00 00 00C 00 00 03 20 010 00 00 04 4C 014 FF FF FF F6 ?Minimum tilt & tilt scaling 018 00 00 00 00 ?Horizontal rotation factor 01C 00 00 00 00 ?Vertical rotation factor 020 40 00 00 00 "Fixed"-ness of camera - higher is more fixed 024 3F 80 00 00 ?Character bubble buffer multiplier OR character bubble front mult. 028 3F E6 66 66 Camera speed smoothness - higher is tighter 02C 00 00 00 0A ?Unknown 1 030 00 00 05 78 ?Pause minimum Z position 034 00 00 05 DC ?Pause initial Z position 038 00 00 05 DC ?Pause max Z position 03C 00 00 00 00 040 00 00 00 00 ?Pause max angle up 044 00 00 00 00 ?Pause max angle left 048 00 00 00 00 ?Pause max angle right 04C 00 00 00 00 ?Pause max angle down 050 C1 70 00 00 ?Unknown 3 054 42 F0 00 00 ?Unknown 4 058 43 F5 00 00 ?Unknown 5 05C 41 F0 00 00 ?Unknown 6 060 C1 00 00 00 064 00 00 00 00 068 00 00 00 00 06C 00 00 00 00 070 00 00 00 00 074 00 00 00 00 078 00 00 00 00 07C 00 00 00 00 080 00 00 00 00 084 00 00 00 00 088 00 00 00 00 08C 00 00 00 00 090 00 00 00 00 094 00 00 00 00 098 00 00 00 00 09C 00 00 00 00 0A0 00 00 00 00 0A4 00 00 00 00 0A8 00 00 00 00 0AC 00 00 00 00 0B0 00 01 3C 48 Pointer to ? table 0B4 00 00 00 01 Number of entries in ? table 0B8 07 00 2A FF Bubble color - top left 0BC 07 00 2A FF Bubble color - top middle 0C0 07 00 2A FF Bubble color - top right 0C4 00 07 36 FF Bubble color - sides top 0C8 00 07 36 FF Bubble color - sides middle 0CC 00 07 36 FF Bubble color - sides bottom 0D0 00 12 33 FF Bubble color - bottom left 0D4 00 12 33 FF Bubble color - bottom middle 0D8 00 12 33 FF Bubble color - bottom right 0DC 00 01 48 60 0E0 00 00 00 00 0E4 00 00 00 00 0E8 2C 00 00 06 0EC 03 00 00 00 0F0 00 00 00 00 0F4 05 06 40 00 0F8 05 00 00 07 0FC 10 F4 50 00 000 00 00 00 00 104 00 00 00 00 108 00 01 3D 94 10C 00 00 00 00 110 00 00 00 00 114 42 84 5D F5 118 43 05 4B E4 11C 44 67 7F 7A 120 00 00 00 00 124 00 00 00 00 128 42 84 5D F5 12C 42 21 2D 5C 130 C0 80 F1 24 134 00 00 00 00 138 00 00 00 00 13C 00 00 00 01 140 00 00 02 80 144 00 00 01 E0 148 00 00 02 80 14C 00 00 01 E0 150 00 01 3D BC 154 00 01 3D D0 158 00 00 00 00 15C 00 00 00 00 160 3D CC CC CD 164 47 00 00 00 168 41 D8 00 00 16C 3F 97 0A 3D 170 00 01 3D E4 174 00 00 00 00 178 00 00 00 00 17C 42 84 5D F5 180 43 0A 4B E4 184 44 67 7F 7A 188 00 00 00 00 18C 3F 7D 70 A4 190 46 1C 40 00 194 00 00 00 03 198 00 00 00 00 19C 00 00 00 00 1A0 00 0E 00 00 1A4 FF FF FF FF 1A8 00 01 3E 24 1AC 00 00 00 00 1B0 00 01 3E 38 1B4 00 01 3E 44 1B8 00 00 00 00 1BC 00 00 00 00 1C0 00 00 00 00 1C4 00 04 00 00 1C8 CC CC CC FF 1CC 00 00 00 00 1D0 00 00 00 00 1D4 00 00 00 00 1D8 00 01 3E 68 1DC 00 00 00 00 1E0 00 01 3E 84 1E4 00 01 3E 60 1E8 00 00 00 00 1EC 00 00 00 00 1F0 00 00 00 00

Alright, now I had this idea the other day and it would be….******* incredible. This is veering a little aways from the simpleness of the above stuff, but is something could certainly be an addition to that program.

The Spot Coordinate Viewer

- “Spots” are the terms used for the coordinate points that create the stage geometry. A “link” is the actual ground that is created when a line is drawn from one spot to another.

- Obviously, spots are super important for stage hacking, because if you want to add or remove collisions, you’ll need to edit the spots.

Over in the other stage hacking thread, I posted this image which is the start of the Spot Coordinate Table for Luigi’s Target Stage (the table starts at the first edit I made)

http://smashboards.com/attachments/capture-png.38478/[/IMG]

And it’s really quite simple…spots consist of two 32-bit floating point values, one right after the other. The first value is the X coordinate, and the second is the Y coordinate. And then the next value is the X coordinate of the next spot, etc.

So in the above picture, the spots look like this:

Spot 1: (-80,-80)
Spot 2: (-80,80)
Spot 3: (80,80)
Spot 4: (80,-80)
Etc.

So all these spots basically make up the stage geometry.

THE IDEA:
- And I really don’t think it’s all that farfetch’d…

A program that parses the spot table and
- converts all the 32-bit floating point numbers into decimals so we humans can read them easily
- organizes the values into spot numbers
- (!!) Plots each point onto a graph to get a visual of all the stage coordinates.\

For the beginning, we don’t even need to connect the dots. Just getting a visual of what it looks like would be good enough to know what is going on.

Then you can hover your mouse over a spot on the graph and it will tell you exactly which one it is in the table (spot number * 0x8), so you know what to modify.

This would be the start of amazing stage hacks. Let me know your thoughts on this!

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

Achilles1515 · Feb 23, 2015

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

Your program gives the offset for "coll_data".
Go to that address, pull that pointer, then add 0x20.

I believe the spot table goes until the next 0x00000000.
EDIT: actually I dont think this is true (the table end, that is). nvm.

I feel like this would be a fun program to make. Wish I knew Python.

From the start of "coll_data" :
0x00 = Pointer to spot table
0x04 = Number of spots
0x08 = Pointer to link table (generally underneath the spot table)
0x0c = number of links
...more...

From here, look at Yax's google doc and it will start to make sense.

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

IE

IE

Smash Ace

IE

Smash Ace

IE

Smash Ace

IE

Smash Ace

IE

Smash Lord

Smash Apprentice

Smash Champion

IE

Smash Lord

IE

Smash Lord

IE

Smash Lord

IE

Smash Lord

IE

Smash Lord

IE

Smash Lord

Smash Rookie

Smash Master

Smash Lord

Smash Lord

Smash Lord

Smash Apprentice

Smash Lord

Smash Lord

Smash Apprentice

Smash Lord

Smash Master

Smash Lord

Smash Apprentice

Smash Lord

Smash Master

Information

Network