Metroid Prime hacking research

2014-09-01 01:02:45 am

@Parax, lol yeah I wouldn't be surprised.

@Caveberry, Blender's default cube is a fairly decent stand-in for obstacles, it fits a large portion of the common objects in a map (e.g: crates)

Aruki

Edit history:

Aruki: 2014-09-01 01:19:02 am

2014-09-01 01:09:29 am

Yeah, sorry. :/ Awkward angles, lack of lighting/environmental detail and little context makes it kinda hard to take good pictures.

I've got no idea on the measurements. I can try to take some after I'm done with my stream.

Also, I kinda wonder what a full-game mod made as a collaboration by the m2k2 community would be like. I'd imagine it being very level design-focused which would be really cool IMO.

Antidote

2014-09-01 01:11:53 am

@Caveberry: case in point

BioSpark

2014-09-01 02:02:28 am

Quote from Paraxade:

Also, I kinda wonder what a full-game mod made as a collaboration by the m2k2 community would be like. I'd imagine it being very level design-focused which would be really cool IMO.

obviously we would fix dash jumps and make it linear.

Aruki

Edit history:

Aruki: 2014-09-01 02:04:22 am

2014-09-01 02:04:16 am

makes sense. here at m2k2 we hate glitches and love linear level design.

Antidote

2014-09-01 02:04:43 am

Fixing dash jumps would require modifying the binary I think, I'm not sure if it's available in a tweak.

Aruki

2014-09-01 02:05:13 am

Well then in that case forget it. Let's lock the thread. We can't fix dash jump guys, no point hacking the game anymore. I give up.

Antidote

2014-09-01 02:05:48 am

Eh wut?

MilesSMB

2014-09-01 02:09:40 am

Let's all make a Corruption mod instead.

Antidote

2014-09-01 02:10:11 am

Yep, lets do it, it's only 5x more complicated :P

Aruki

2014-09-01 02:15:45 am

No, Corruption was flawed. I think we should just make every area Skytown. Corruption didn't have enough Skytown.

Antidote

2014-09-01 02:16:08 am

xD, don't forget more blue
It needs more blue

Aruki

Edit history:

Aruki: 2014-09-01 06:13:56 am

2014-09-01 06:12:42 am

k Caveberry, so here's some numbers for you. If you need a unit of measurement, let's go with meters; that seems accurate since the morph ball model is exactly 1 meter tall before being scaled ingame.

* Samus is ~2.5 meters tall. (If that sounds stupid tall, she's 1.8 meters before the model gets scaled.)
* The morph ball is ~1.25 meters tall.
* A single jump/single bomb jump with Space Jump reaches about ~3 meters high.
* A double bomb jump reaches about ~6 meters high.
* A UBJ/HBJ reaches about ~8 meters high.
* A jump + space jump reaches about ~8 meters high.
* A UBJ unmorph reaches about ~11-12 meters high.

I don't think I can get any distance measurements since I'm not sure of a good place to test them out, and I'm not sure they would be all that helpful anyway. Keep in mind all these measurements are relative. Aside from being relatively imprecise, there's also about a million things that can affect how high/far any given jump gets, including bomb jump unmorphs, ghettos, rodeo jumping, twisting, L-jumping, etc. I doubt any level design sketch that intends to take advantage of those mechanics is going to work very well without being actually tested ingame and tweaked based on the results of that. Not to discourage you, but keep that in mind.

k Caveberry, so here's some numbers for you. If you need a unit of measurement, let's go with meters; that seems accurate since the morph ball model is exactly 1 meter tall before being scaled ingame.

* Samus is ~2.5 meters tall. (If that sounds stupid tall, she's 1.8 meters before the model gets scaled.)
* The morph ball is ~1.25 meters tall.
* A single jump/single bomb jump with Space Jump reaches about ~3 meters high.
* A double bomb jump reaches about ~6 meters high.
* A UBJ/HBJ reaches about ~8 meters high.
* A jump + space jump reaches about ~8 meters high.
* A UBJ unmorph reaches about ~11-12 meters high.

I don't think I can get any distance measurements since I'm not sure of a good place to test them out, and I'm not sure they would be all that helpful anyway. Keep in mind all these measurements are relative. Aside from being relatively imprecise, there's also about a million things that can affect how high/far any given jump gets, including bomb jump unmorphs, ghettos, rodeo jumping, twisting, L-jumping, etc. I doubt any level design sketch that intends to take advantage of those mechanics is going to work very well without being actually tested ingame and tweaked based on the results of that. Not to discourage you, but keep that in mind.

Drewseph

Edit history:

Drewseph: 2014-09-01 01:05:23 pm

2014-09-01 01:04:37 pm

I actually kind of like the dash jump in prime 2 as apposed to the completely broken one in prime 1. perhaps if there was a way to mod in actual air resistance for a realistic decelleration while dash jumping instead of magically losing all momentum like in prime 2/3

Antidote

2014-09-01 04:41:11 pm

Good news about MP3 is, while they changed practically everything, collision is identical to MP2

MilesSMB

2014-09-01 04:42:59 pm

That's a good thing?

Antidote

2014-09-01 04:43:27 pm

It's one less format, but otherwise probably not lol

Caveberry

2014-09-01 05:04:30 pm

getting there...

Thanks for putting those numbers up Parax. I realize all levels would need to be tasted pretty extensively, but this gives me a rough starting point.

Ironically enough, the mod I have in mind would be extremely linear. Very anti-Metroid right?

Aruki

2014-09-01 05:07:36 pm

Quote from Caveberry:

I realize all levels would need to be tasted pretty extensively

Sounds like a yummy level

Antidote

Edit history:

Antidote: 2014-09-01 05:13:07 pm

2014-09-01 05:11:11 pm

I bet it tastes like chocolate.

Edit:
The room where you first talk to admiral dane

Caveberry

2014-09-01 05:43:40 pm

getting there...

I just hope we can acquire all the ingredients necessary...

Aruki

Edit history:

Aruki: 2014-09-01 08:37:17 pm

Aruki: 2014-09-01 07:45:37 pm

2014-09-01 07:44:44 pm

Miles and I have the MP1 collision format mostly completely figured out by this point. After a small header, it starts with an octree. An octree node can be either a branch or a leaf. A branch has eight child nodes; it starts with a u16 bitflag that specifies the type of node each child is (01 for branch, 10 for leaf, 00 for a node that doesn't actually exist). Following that is two bytes of padding, then eight offsets, one per child. A leaf node contains coordinates for an axis-aligned bounding box, then a small list of faces; then it pads to the next multiple-of-4 offset.

The purpose of subdividing it this way is that for a collision check on any given object, they can use the octree to narrow down all the room's collision geometry to a very small list of faces that the object could potentially be colliding with; then they can check the collision on just those faces. That allows them to only have to check a small number of faces per check, instead of the hundreds or thousands they would need to check otherwise, which would be horribly inefficient.

Following the octree is a number of arrays:
A. an array of u32 values that we're pretty sure are bitflags specifying multiple sets of collision properties. It's gonna take some trial and error to work out exactly what each bit does here.
B. an array of u8 values that assign a collision property set to each vertex.
C. an array of u8 values that assign a collision property set to each line.
D. an array of u8 values that assign a collision property set to each face.
E. an array of u16 values that create lines by connecting a pair of vertices.
F. an array of u16 values that create faces by connecting a trio of lines.
G. an array of vertex positions (floats).

So that's pretty much it. I'm not sure what the point of using lines is or why each vertex/line needs properties assigned to them when faces already have them, so if anyone's got any ideas on that that'd be cool. Only thing left to do here is figure out what the properties are.

edit: now that I've thought about it I think the purpose of using lines is to assist in the octree generation. Suppose they have this polygon (excuse horrible MS Paint skills), from a top-down view, with the black lines representing a subsection of the octree. Going strictly off vertex positions, there is no way to tell this polygon is inside the upper-left quadrant. That is bad. Using the lines, you can actually tell and generate a more accurate octree. That being said, I'm still not sure why vertices and lines have collision properties.

Miles and I have the MP1 collision format mostly completely figured out by this point. After a small header, it starts with an octree. An octree node can be either a branch or a leaf. A branch has eight child nodes; it starts with a u16 bitflag that specifies the type of node each child is (01 for branch, 10 for leaf, 00 for a node that doesn't actually exist). Following that is two bytes of padding, then eight offsets, one per child. A leaf node contains coordinates for an axis-aligned bounding box, then a small list of faces; then it pads to the next multiple-of-4 offset.

The purpose of subdividing it this way is that for a collision check on any given object, they can use the octree to narrow down all the room's collision geometry to a very small list of faces that the object could potentially be colliding with; then they can check the collision on just those faces. That allows them to only have to check a small number of faces per check, instead of the hundreds or thousands they would need to check otherwise, which would be horribly inefficient.

Following the octree is a number of arrays:
A. an array of u32 values that we're pretty sure are bitflags specifying multiple sets of collision properties. It's gonna take some trial and error to work out exactly what each bit does here.
B. an array of u8 values that assign a collision property set to each vertex.
C. an array of u8 values that assign a collision property set to each line.
D. an array of u8 values that assign a collision property set to each face.
E. an array of u16 values that create lines by connecting a pair of vertices.
F. an array of u16 values that create faces by connecting a trio of lines.
G. an array of vertex positions (floats).

So that's pretty much it. I'm not sure what the point of using lines is or why each vertex/line needs properties assigned to them when faces already have them, so if anyone's got any ideas on that that'd be cool. Only thing left to do here is figure out what the properties are.

edit: now that I've thought about it I think the purpose of using lines is to assist in the octree generation. Suppose they have [url=http://i.imgur.com/QQPw89q.png]this polygon[/url] (excuse horrible MS Paint skills), from a top-down view, with the black lines representing a subsection of the octree. Going strictly off vertex positions, there is no way to tell this polygon is inside the upper-left quadrant. That is bad. Using the lines, you can actually tell and generate a more accurate octree. That being said, I'm still not sure why vertices and lines have collision properties.

Caveberry

Edit history:

Caveberry: 2014-09-01 08:12:34 pm

Caveberry: 2014-09-01 08:10:05 pm

2014-09-01 07:47:39 pm

getting there...

I just roughed this one out in 10 minutes while drinking a beer. Mondays are awesome.

^= hazard (phazon, lava, etc.) I assume health will be set to 01 on most of these.
////= pit There are no terminal falls in this game, so these are more or less deeper hazards.
o= dash point
missile looking thing= missile In this map, it works like a key, allowing you to exit through the missile door at the end.

This is just sort of a basic scan dash course. You hold your lock while making short dashes over all the hazards (novices will probably just jump over them). Then you use your unbroken lock on through the wall to dash over the expansive pit. The next portion exercises your ability to bend dashes. First with an easy bend forward to the missile expansion, second with a harder bend backwards, then finally with an extreme bend backwards to the exit (think dash to ice door in MQA).

I've got a ton of more ambitious ideas, but I'm finding graph paper to be a bit limiting. I'll try to do more soon though.

I just roughed this one out in 10 minutes while drinking a beer. Mondays are awesome.

[IMG]http://i.imgur.com/z5DzI2U.jpg[/IMG]

^= [b]hazard[/b] (phazon, lava, etc.) I assume health will be set to 01 on most of these.
////= [b]pit[/b] There are no terminal falls in this game, so these are more or less deeper hazards.
o= [b]dash point[/b]
missile looking thing= [b]missile[/b] In this map, it works like a key, allowing you to exit through the missile door at the end.

This is just sort of a basic scan dash course. You hold your lock while making short dashes over all the hazards (novices will probably just jump over them). Then you use your unbroken lock on through the wall to dash over the expansive pit. The next portion exercises your ability to bend dashes. First with an easy bend forward to the missile expansion, second with a harder bend backwards, then finally with an extreme bend backwards to the exit (think dash to ice door in MQA).

I've got a ton of more ambitious ideas, but I'm finding graph paper to be a bit limiting. I'll try to do more soon though.

MrSinistar

2014-09-02 02:51:24 am

Finally got 3DS Max installed. Absolutely loving the scripts, Para, thanks so much!!

How did you get the reflections and alpha channels to work in the preview window in 3DS Max? I have the 2010 version and I saw in the Imgur gallery that the models look like they're ingame. I apologize if there was a discussion about this earlier.

Just for a quick test, I rendered a closeup of Lightsuit Samus. I can't wait for the bones to be supported so I can do some animations :)

Aruki

Edit history:

Aruki: 2014-09-02 02:58:59 am

Aruki: 2014-09-02 02:58:02 am

2014-09-02 02:55:50 am

I didn't. I took those pictures in Prime World Editor, not Max.

In Max though, you just need to select the material (press M to open the material editor, use the eyedropper tool on Samus). The script imports materials kind of messy so you might prefer to go into edit poly mode on the model, select the polygon(s) you want and then check what their material ID is set to. You can make use of the settings in the material editor to set an opacity map, reflection map, transparency... etc. on the model.

Also don't think bones will be supported at least until ANCS is completely cracked, because those are stored in separate files and are linked to the model through ANCS.