I don't really know much about these files, but I think they'll be very important to edit in the future as they very likely contain what we need to really be able to tweak a wide variety of stages. Brawlbox lets us break them down far enough to be manageable files; we should be able to make great strides on this with determination (someone with real hacking skill would probably do even better). I hope this thread will be of use for people to post what they know and the results of their experiments in messing with them.
Here is what I know.
The Type1[2] file that is present in every stage I've seen is collision data. This is fairly flexible, and I know solid ground, ledges, and platforms all count under collision. Final Destination and Battlefield swap collision flawlessly (if you reverse them, the graphics are a lie but property wise they are exact switches). Battlefield is willing to impose on Mushroomy Kingdom 1-1 just fine and imposes its collision data in the reference frame of the camera, and it seems as though the blocks are not a part of Mushroomy Kingdom 1-1's collision data as they remain regardless, and they are the only interactive element that give the stage actual scrolling properties like this (graphically it's scrolling, but that doesn't really matter). There are segments near the end of Battlefield's Type1[2] file that I was able to zero out with a hex editor to remove collision from pieces of the stage (the main ground and each individual platform). They all start with 00 0N 00 XX and end with 00 00 FF FF (you can see for yourself if you're into that sort of thing). The N values go 0-3 like they're indexing parts of the stage, and the XX values are all 01 for the platforms and 10 for the main ground. There's a bunch of stuff that looks like "content" in the middle (many non-zero values in a row), but removing them all without removing the other stuff has seemingly no effect.
The other exploration I've done is into PictoChat. PictoChat's model data [10] through [270] very obviously correspond to the 27 drawings, and there are also obviously type1[10] through type1[270] by increments of 10 that seem to be properties files for each drawing. However, they can't be swapped around very easily. I tried replacing every drawing's model data with that for drawing [70] which is the side spikes (floating in the air on each side, do 20% damage). This seems to have caused the stage to be in a perpetual state of every drawing having collision at once except no damaging hazards, no moving pieces, and the left ledge is grabbable. The graphics for drawing [70] rapidly draw and undraw in a fairly awkward way. Replacing all the type1[N] data has bad effects; the many lines drawing had only some of the lines have collision, and the ferris wheel drawing locked the game with type1[70] data being loaded for it. I looked at the type1[N] files for PictoChat in a hex editor, and they are very short, but nothing in them is particularly obvious. type1[70] very obviously does not have hitbox data for the side spikes in it; nothing about the files is really very obvious to me just looking at them.
So, my results were fairly disappointing and inconclusive at best, but maybe someone finds them helpful. If anyone else has some exploration that was more fruitful, I think it would do us all some good.
Here is what I know.
The Type1[2] file that is present in every stage I've seen is collision data. This is fairly flexible, and I know solid ground, ledges, and platforms all count under collision. Final Destination and Battlefield swap collision flawlessly (if you reverse them, the graphics are a lie but property wise they are exact switches). Battlefield is willing to impose on Mushroomy Kingdom 1-1 just fine and imposes its collision data in the reference frame of the camera, and it seems as though the blocks are not a part of Mushroomy Kingdom 1-1's collision data as they remain regardless, and they are the only interactive element that give the stage actual scrolling properties like this (graphically it's scrolling, but that doesn't really matter). There are segments near the end of Battlefield's Type1[2] file that I was able to zero out with a hex editor to remove collision from pieces of the stage (the main ground and each individual platform). They all start with 00 0N 00 XX and end with 00 00 FF FF (you can see for yourself if you're into that sort of thing). The N values go 0-3 like they're indexing parts of the stage, and the XX values are all 01 for the platforms and 10 for the main ground. There's a bunch of stuff that looks like "content" in the middle (many non-zero values in a row), but removing them all without removing the other stuff has seemingly no effect.
The other exploration I've done is into PictoChat. PictoChat's model data [10] through [270] very obviously correspond to the 27 drawings, and there are also obviously type1[10] through type1[270] by increments of 10 that seem to be properties files for each drawing. However, they can't be swapped around very easily. I tried replacing every drawing's model data with that for drawing [70] which is the side spikes (floating in the air on each side, do 20% damage). This seems to have caused the stage to be in a perpetual state of every drawing having collision at once except no damaging hazards, no moving pieces, and the left ledge is grabbable. The graphics for drawing [70] rapidly draw and undraw in a fairly awkward way. Replacing all the type1[N] data has bad effects; the many lines drawing had only some of the lines have collision, and the ferris wheel drawing locked the game with type1[70] data being loaded for it. I looked at the type1[N] files for PictoChat in a hex editor, and they are very short, but nothing in them is particularly obvious. type1[70] very obviously does not have hitbox data for the side spikes in it; nothing about the files is really very obvious to me just looking at them.
So, my results were fairly disappointing and inconclusive at best, but maybe someone finds them helpful. If anyone else has some exploration that was more fruitful, I think it would do us all some good.
