Retro Modding Wiki - User contributions [en]

Template talk:Research

2015-03-14T15:12:56Z

Embyr 75: /* Categories */ @Parax

==Categories==
So this template is equipped to replace [[:Template:Researchminor]], [[:Template:Researchmoderate]], and [[:Template:Researchmajor]]. Those three templates each categorize to different categories; I can rig this template to categorize to three separate categories as well, if preferred (at the moment, they all categorize to [[:Category:Research needed]]). I wanted to get input before I did that. My question is, do we need three categories? Or would we prefer to lump them together? Also, if this template is adequate, those other three templates can be deleted by someone with sufficient userrights. [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 18:49, 29 January 2015 (CST)

:IMO having three templates for it is a good idea. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 20:14, 29 January 2015 (CST)

::Derp, I just realized that you said you'd rather have three ''templates''; for some reason when I read this my brain processed it as three ''categories'' and I never gave it a second thought. Would you like me to go back and re-implement the first three templates? (I just replaced them all with this one.) ^_^; [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 10:12, 14 March 2015 (CDT)

PAK (Metroid Prime 3)

2015-03-14T15:06:37Z

Embyr 75: {{research}}

''See [[PAK (File Format)]] for the other revisions of this format.''

The '''.pak format''' in Metroid Prime 3 and Donkey Kong Country Returns is a new version of the pak format with some slight changes. The most notable change is that resource IDs have been extended from 32 bits to 64 bits. The new format also aligns to 64-byte boundaries, rather than 32. Aside from that, the other changes are mainly organizational; it's still largely the same data as older versions of the format.

Note that the Metroid Prime 3 E3 prototype uses a slightly modified version of the Metroid Prime pak format, not this one. See the [[PAK (Metroid Prime)]] page for more info on that revision of the format.

{{research|1|Research needs to be done on how to order files to optimize loads. Also, the very first part of the header is mostly unknown.}}

__TOC__

== Format==

The header is split into a number of smaller chunks that are each padded to the next 64-byte offset.

=== Header ===

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| {{unknown|'''Unknown'''. Always 2.}}
|-
| 0x4
| 4
| '''Header size'''
|-
| 0x8
| 16
| '''MD5 hash''' of the entire pak after the first 64 bytes.
|-
| 0x18
| colspan=2 {{unknown|End of header; pad to 64 bytes}}
|}

=== Table of Contents ===

The next part of the file, starting at 0x40, is a brief list of each section in the pak and its size. Although it uses a count value, this section always lists the same data in the same order.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Section count'''; always 3
|-
| 0x4
| 4
| '''"STRG" fourCC'''
|-
| 0x8
| 4
| '''Named Resources section size'''
|-
| 0xC
| 4
| '''"RSHD" fourCC'''
|-
| 0x10
| 4
| '''Resource Table section size'''
|-
| 0x14
| 4
| '''"DATA" fourCC'''
|-
| 0x18
| 4
| '''File data section size'''
|-
| 0x1C
| colspan=2 {{unknown|End of ToC; pad to 64 bytes}}
|}

=== Named Resources ===

This section, always starting at 0x80, lists named resources. These are the files that the game has direct access to; every other file in the pak will be a dependency of one of these.

It starts with a 32-bit count, followed by the table itself; each entry of the table is structured as follows:

{| class="wikitable"
! Type
! Size
! Description
|-
| string
| -
| '''Name'''; zero-terminated
|-
| fourCC
| 4
| '''Resource type'''
|-
| u64
| 8
| '''Resource ID'''
|}

=== Resource Table ===

The final table contains a list of every resource in the pak. Following a 32-bit count value, each resource entry is structured as follows:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Compression flag'''; this will either be 0 or 1, with 1 denoting a compressed file.
|-
| 0x4
| 4
| '''Resource type''' fourCC.
|-
| 0x8
| 8
| '''Resource ID'''
|-
| 0x10
| 4
| '''Size''' (note: always a multiple of 64; the end of the file is padded with 0xFF if necessary)
|-
| 0x14
| 4
| '''Offset''' (relative to the start of the DATA section)
|-
| 0x18
| colspan=2 {{unknown|End of entry}}
|}

== Compression ==

Some files within paks are compressed; in Prime 3, files are compressed with segmented LZO1X, just like Prime 2. In DKCR, on the other hand, files are compressed as a single zlib stream, like Prime 1. In either game, every compressed file is formatted the same way, starting with some metadata detailing the structure of the compressed data.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''"CMPD" fourCC'''
|-
| 0x4
| 4
| '''Compressed block count'''
|}

Each compressed block is structured as follows.

For each block, if the compressed and decompressed sizes match, that indicates the block is uncompressed.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 1
| '''Flag'''
|-
| 0x1
| 3
| '''Compressed size'''
|-
| 0x4
| 4
| '''Decompressed size'''
|-
| 0x8
| colspan=2 {{unknown|End of entry}}
|}

The flag value can be set to the following possible values:

* If the block count is 1, it will be 0xA0 on block 1.
* If blocks 2/3 are compressed, they will have it set to 0xC0.
* If blocks 2/3 are uncompressed, they will have it set to 0x40.
* 0 in all other circumstances.

Files are left uncompressed if the compressed data is larger than the uncompressed data. Barring that, the following formats are always compressed:

* [[TXTR (Metroid Prime)|TXTR]]
* [[CMDL (Metroid Prime)|CMDL]]
* [[CSKR (File Format)|CSKR]]
* [[CHAR (File Format)|CHAR]]
* [[SAND (File Format)|SAND]]
* [[ANIM (File Format)|ANIM]]
* [[SCAN (Metroid Prime 2)|SCAN]]
* [[FONT (File Format)|FONT]]
* [[CSMP (File Format)|CSMP]]
* [[STRG (File Format)|STRG]]
* [[CAAD (File Format)|CAAD]]
* [[DCLN (File Format)|DCLN]]
* [[USRC (File Format)|USRC]]

The following formats are compressed when their uncompressed size is at least 0x80 bytes:

* [[PART (File Format)|PART]]
* [[ELSC (File Format)|ELSC]]
* [[SWHC (File Format)|SWHC]]
* [[WPSC (File Format)|WPSC]]
* [[CRSC (File Format)|CRSC]]
* [[BFRC (File Format)|BFRC]]
* [[SPSC (File Format)|SPSC]]
* [[DPSC (File Format)|DPSC]]

== File Order ==

File order matters significantly and easily makes the difference between a pak loading quickly and optimally, or taking 30+ seconds on every door. While more research is required to figure out exactly how files should be ordered to optimize loading, the game generally clusters together resources that are used together, and a file's dependencies generally appear directly before the file itself. The game also often duplicates assets that are used multiple times within the same pak; there might be 10-11 copies of the same model file in order to allow the game to more easily find and load that file when it needs it.

== Tools ==

* [https://drive.google.com/file/d/0B9MLV21H7SDvcGc1QjRfSTFJNk0/view?usp=sharing PakTool] by Parax

[[Category:File Formats]]
[[Category:Metroid Prime 3: Corruption]]
[[Category:Donkey Kong Country Returns]]

HINT (File Format)

2015-03-14T15:06:14Z

Embyr 75: {{research}}

The '''HINT format''' is used to manage the hint system, controlling what hints pop up, what they say, and where they point to.

{{research|1|There are a couple unknown fields.}}

__TOC__

== Format ==

=== Header ===

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Magic'''; always 0x00BADBAD
|-
| 0x4
| 4
| '''Version'''; 1 in Prime/Echoes, 3 in Corruption
|-
| 0x8
| 4
| '''Hint count'''
|-
| 0xC
| colspan=2 {{unknown|Hint entries start}}
|}

=== Hint ===

{| class="wikitable"
! Type
! Count
! Description
! Metroid Prime 1/2
! Metroid Prime 3
|-
| string
| 1
| '''Hint name'''
| {{check}}
| {{check}}
|-
| float
| 1
| {{unknown|'''Unknown'''}}
| {{check}}
| {{check}}
|-
| float
| 1
| '''Appear time'''; the amount of time that passes from when the hint is activated to when it appears on the HUD
| {{check}}
| {{check}}
|-
| u32/u64
| 1
| '''Pop-up text STRG ID'''; u32 in Metroid Prime 1/2, u64 in Metroid Prime 3
| {{check}}
| {{check}}
|-
| u32
| 1
| {{unknown|'''Unknown'''}}
| {{check}}
| {{check}}
|-
| u32
| 1
| {{unknown|'''Unknown'''}}
| {{check}}
| {{check}}
|-
| u32
| 1
| '''Target world MLVL ID'''
| {{check}}
| {{nocheck}}
|-
| u32
| 1
| '''Target room MREA ID'''
| {{check}}
| {{nocheck}}
|-
| u32
| 1
| '''Target room index'''
| {{check}}
| {{nocheck}}
|-
| u32
| 1
| '''Map text STRG ID'''
| {{check}}
| {{nocheck}}
|-
| colspan=5 {{unknown|End of entry}}
|}

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]

CSKR (File Format)

2015-03-14T15:05:36Z

Embyr 75: {{research}}

The '''CSKR format''' contains skin bindings for rigged models. It attaches groups of vertices to bones. Note that any model being skinned needs to be exported at the same time as the skin; you can't skin a pre-existing model without modifying it. The reason is because the way the skin format works, the vertices with the same weights need to be grouped together in the model file.

{{research|1|The only thing that isn't understood about this format is, why do some CSKR files contain all the vertex coordinates and normals? Also, what's the max number of bones that can be weighted to one vertex?}}

== Format ==

CSKR is a very simple format. It begins with a 32-bit weight count, followed by a set of vertex groups. Each vertex group assigns a set of weights to a specified number of vertices; these vertices are specified simply through a count value, and are implied to begin after the end of the previous group. The total value of all the weights on all bones in a given vertex group should be 1.0.

=== Vertex Group ===

{| class="wikitable"
! Type
! Count
! Description
|-
| long
| 1
| '''Weight count''' (WC)
|-
| Weight
| WC
| '''Weights'''
|-
| long
| 1
| '''Vertex count'''
|}

=== Weight ===

{| class="wikitable"
! Type
! Count
! Description
|-
| long
| 1
| Bone ID
|-
| float
| 1
| Weight
|}

=== Footer ===

CSKR files contain a footer after all the weights are assigned. The structure is a little strange; it lists the vertex coordinate and vertex normal counts (which are often the same value). Usually each of these counts will be preceded by a value of 0xFFFFFFFF; however, if they're not, then the entire vertex coordinate/normal array from the model file will be inserted into the skin file. It's a byte-for-byte match with the data from the model. The purpose of this section is unknown.

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]
[[Category:Donkey Kong Country Returns]]

CINF (File Format)

2015-03-14T15:05:20Z

Embyr 75: {{research}}

The '''CINF format''' is for skeletons. Skeletons are associated with models and skins through [[ANCS (File Format)|ANCS]] files.

{{research|1|What is the point of the bone ID section?}}
{{todo|MP2/3/DKCR differences}}

== Format ==

The file starts with a list of all the bones in the skeleton. The first value is a 32-bit count, then the following structure loops.

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| u32
| 4
| '''Bone ID'''
|-
| 0x4
| u32
| 4
| '''Parent Bone ID'''
|-
| 0x8
| float[3]
| 0xC
| '''Position'''
|-
| 0x14
| u32
| 4
| '''Linked bone count''' (LC); includes parent + children
|-
| 0x18
| u32[]
| 4 × LC
| '''Linked bone ID array'''
|}

After this is an array listing every bone ID in the skeleton. The first bone is the root bone, then the rest are listed in reverse numerical order.

{| class="wikitable"
! Type
! Count
! Description
|-
| u32
| 1
| '''Bone ID count''' (BC)
|-
| u32
| BC
| '''Bone ID array'''
|}

Finally, the end of the file sets bone names. After the traditional count value, this short structure loops:

{| class="wikitable"
! Type
! Count
! Description
|-
| string
| 1
| '''Bone name'''
|-
| u32
| 1
| '''Bone ID'''
|}

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]
[[Category:Donkey Kong Country Returns]]

Geometry (Metroid Prime)

2015-03-14T15:04:59Z

Embyr 75: {{research}}

The format for '''geometry''' appears in both the [[CMDL (File Format)|CMDL]] and [[MREA (File Format)|MREA]] formats, and is identical between both. This format is used in all three Prime games, and is largely unchanged between all of them (with the exception of an extra vertex attribute that was added in Echoes and Corruption).

{{research|1|There's a couple unknowns in the submesh headers.}}

__TOC__

== Format ==

An important thing to note off the bat is that both CMDL and MREA files are split up into a number of 32-byte-aligned ''sections''; their respective headers both declare a section count, and list the sizes of each section contained in the file. This is required to navigate to different parts of the file, and is required in order to read the geometry data correctly. Sections are generally split based on the type of data contained in them, so one section might contain vertex coordinates, while another contains a submesh definition. For the purposes of this article, each subheader will mark the start of a new section; use that as your cue to advance to the next one. Check the CMDL or MREA pages for more info on how the sections work.

For vertex attributes, note that there's no count value present anywhere. If you want a rough count, you can divide the size of that attribute's section by the attribute's size.

=== Vertex Coordinates ===

These are stored as a sequence of three floats.

=== Normals ===

Normals can appear as either floats or shorts. In CMDL, this usually corresponds to the 0x2 bit in the flags value, and in MREA they will always appear as shorts; this is technically supposed to be set by the vertex format flag in the primitive data, though. If they appear as shorts, they should be divided by the mantissa value that appears on each submesh (that value is almost always 0x8000).

=== Vertex Color ===

These are theoretically stored as 32-bit RGBA values, but vertex color isn't actually used by any mesh in any Retro games, so this section usually appears completely empty.

=== Float UV Coordinates ===

These are stored as a sequence of two floats.

=== Short UV Coordinates ===

These are stored as a sequence of two shorts. Like normals, these should be divided by the submesh's mantissa value. The short UV array is generally only used by terrain lightmaps, and as such this section always appears completely empty (listed with a size of 0) on CMDL. This array can only be used by the first UV coordinate on a given vertex, and whether it's used or not depends on one of the flags on the material. The rest will use the float array.

=== Submesh Definitions ===

This section is very small and simple; it simply declares a submesh count and then lists the offsets to the end of each submesh. Following this section, there'll be one additional section per submesh.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Submesh count''' (SC)
|-
| 0x4
| 4 × SC
| '''Submesh offsets''' (relative to the start of the first submesh)
|-
| colspan=3 {{unknown|Submesh sections begin}}
|}

=== Submesh ===

There will be one of these sections per submesh. Each submesh starts with a small header; following the end of the header, the file is padded with 0s to the next 32-byte boundary, then the primitive data begins.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 0xC
| '''Position''' (or pivot location; unknown purpose)
|-
| 0xC
| 4
| '''Material ID'''
|-
| 0x10
| 2
| '''Mantissa''' - divide short normals/UVs by this value; always 0x8000
|-
| 0x12
| 2
| '''Primitive table size''' (important note: ''this value is not always reliable'')
|-
| 0x14
| 4
| {{unknown|'''Unknown''' - always 0?}}
|-
| 0x18
| 4
| {{unknown|'''Unknown''' - always 0?}}
|-
| 0x1C
| 4
| '''Extra data size''' (ES); this isn't 100%, but seems to be correct
|-
| 0x20
| 0xC
| {{unknown|'''Unknown'''; seems to be a normalized vector}}
|-
| 0x2C
| 2
| {{unknown|'''Unknown''' ''(note: not in Prime 1)''}}
|-
| 0x2E
| 2
| {{unknown|'''Unknown''' ''(note: not in Prime 1)''}}
|-
| 0x30
| ES
| Extra data; usually empty on CMDL, contains a bounding box used for depth sorting on MREA
|-
| colspan=3 {{unknown|End of submesh header; pad to multiple of 32 before primitive data starts}}
|}

The primitive data is a standard GX display list. Each primitive begins with a byte that contains the primitive type in the upper 5 bits, and the vertex format setting in the lower 3; see below for possible settings. After that is a 16-bit vertex count, followed by a series of 16-bit vertex attribute indices.

Note that you'll need to check some settings on the material to read the primitive data properly; the material determines which vertex attributes are present. The material also determines whether the submesh is using lightmaps; if it is, then the first UV coordinate will be read out of the short UV array instead of the float one.

There is no primitive count value; you'll need to continue reading data until you hit the end of the primitive table. There are a couple values you can use for reference; either the submesh's section size, or the submesh's end offset. '''Do not use the primitive table size setting from the submesh header, though'''; it's usually accurate, but on some models it will give you a size smaller than the table actually is, and you'll miss a bunch of data. See Metroid3/4a11192a.CMDL from Prime 1 (icicle Ridley) or Metroid1/05778239.CMDL from Echoes (Samus's gunship) for an example of this.

There are 7 primitive types supported by GX, indicated in the upper 5 bits of the flag value. Note that the game only ever actually uses triangles, triangle strips, and triangle fans; however, all of these primitives are supported by GX and are therefore supported by the game, and so they could be used in custom model files.

{| class="wikitable"
! Value
! Primitive
|-
| 0x80
| Quads
|-
| 0x90
| Triangles
|-
| 0x98
| Triangle strip
|-
| 0xA0
| Triangle fan
|-
| 0xA8
| Lines
|-
| 0xB0
| Line strip
|-
| 0xB8
| Points
|}

In addition, the game uses three vertex formats, indicated in the lower 3 bits of the flag value (0x7). The only attributes that change between formats are nrm and tex0, so those are the only ones listed in the table below.

{| class="wikitable"
! Format
! GX_VA_NRM type/size
! GX_VA_TEX0 type/size
|-
| 0
| GX_NRM_XYZ / GX_F32
| GX_TEX_ST / GX_F32
|-
| 1
| GX_NRM_XYZ / GX_S16
| GX_TEX_ST / GX_F32
|-
| 2
| GX_NRM_XYZ / GX_S16
| GX_TEX_ST / GX_S16
|}

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]

AFSM (File Format)

2015-03-14T15:04:41Z

Embyr 75: {{research}}

The '''AFSM format''' controls AI behavior; it stands for '''A'''I '''F'''inite '''S'''tate '''M'''achine. AI-controlled creatures have a limited number of possible states they can be in. The AFSM file defines those states, and what triggers can cause it to transition to another state.

{{research|1|We should have a list of possible states and triggers and a short explanation of what they generally do on this page somewhere. Also, the float settings on conditions is unknown.}}

__TOC__

== Format ==

=== Header ===

The format first defines a list of states, then defines the triggers for each transition attached to each state. There are no state/trigger type IDs; rather, the name string itself is used as an identifier to fetch the corresponding AI function. It starts with a short header listing each state and then providing a trigger count. Note that the trigger count isn't actually used to parse the file; it's present merely because the game uses it to allocate space for each trigger ahead of time.

{| class="wikitable"
! Type
! Count
! Description
|-
| long
| 1
| '''State count''' (SC)
|-
| string
| SC
| '''State names''' (each zero-terminated)
|-
| long
| 1
| '''Trigger count'''
|}

=== State Transitions ===

Following that, it iterates through each state, defining the transitions associated with each one. Transitions are composed of a target state index and a number of triggers; when all the triggers associated with a transition are satisfied, it advances to the targeted state. The state transitions are structured like this:

{| class="wikitable"
! Type
! Count
! Description
|-
| long
| 1
| '''Transition count''' (TC)
|-
| Transition
| TC
| '''Transitions'''
|}

=== Transitions ===

{| class="wikitable"
! Type
! Count
! Description
|-
| long
| 1
| '''Trigger count''' (TC)
|-
| Trigger
| TC
| '''Triggers'''
|}

=== Trigger ===

{| class="wikitable"
! Type
! Count
! Description
|-
| string
| 1
| '''Trigger name''' (zero-terminated)
|-
| float
| 1
| {{unknown|'''Unknown''' (possibly AI function parameter)}}
|-
| long
| 1
| '''Target state index''' (note: this is ONLY present on the first trigger for each transition!)
|}

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]

ATBL (File Format)

2015-03-14T15:03:48Z

Embyr 75: {{research}}

The '''ATBL format''' contains a list of every sound effect in the game, corresponding to the sounds from AGSC files. It is by far the most complex and difficult format in the game.

{{research|1|Verify that these are actually sound IDs, and figure out why a lot of them are FF'd out.}}

__TOC__

== Format ==

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Sound count''' (SC)
|-
| 0x4
| 2 × SC
| '''Sound ID array'''
|-
| colspan=3 {{unknown|End of file}}
|}

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]

FONT (File Format)

2015-03-14T15:02:45Z

Embyr 75: {{research}}

The '''FONT format''' defines fonts that can be used to display text in-game.

{{todo|Notate differences between different versions of the format. Only Metroid Prime's FONT version is documented at the moment. Character definition structure should be expanded on; there should be a section explaining what each value does, and it should be made more clear which UV coordinate corresponds to which vertex.}}
{{research|2|There's some unknowns in the header, and some of the values in the character definition structure should be double-checked.}}

__TOC__

== Format ==

=== Header ===

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''"FONT" magic fourCC'''
|-
| 0x4
| 4
| '''Version'''; see below
|-
| 0x8
| 4
| '''Max glyph height''' (plus padding, in points)
|-
| 0xC
| 4
| '''Min glyph height''' (plus padding, in points)
|-
| 0x10
| 4
| '''Max glyph width''' (plus padding, in points)
|-
| 0x14
| 4
| '''Min glyph width''' (plus padding, in points)
|-
| 0x18
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x1C
| 2
| {{unknown|'''Unknown'''}}
|-
| 0x1E
| 4
| '''Font Size''' (in points)
|-
| 0x22
| N
| '''Font name'''; zero-terminated string
|-
| 0x22+N
| 4
| '''[[TXTR (Metroid Prime)|TXTR]] file ID'''
|-
| 0x26+N
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x2A+N
| 4
| '''Glyph Count'''
|-
| 0x2E+N
|
| '''Glyphs''' ([[#Glyph Entry (Version 2)|Version 2]], [[#Glyph Entry (Version 4)|Version 4]])
|}

==== Version ====

{| class="wikitable"
! Version
! Game
|-
| 1
| ''Metroid Prime'' Kiosk Demo
|-
| 2
| ''Metroid Prime''
|-
| 4
| ''Metroid Prime 2'' (and demo), ''Metroid Prime'' Wii releases
|-
| 5
| ''Metroid Prime 3'', ''DKCR''
|}

=== Glyph Entry (Version 2) ===

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| u16
| 2
| '''UTF-16 character'''
|-
| 0x2
| float
| 4
| '''Left UV coordinate'''
|-
| 0x6
| float
| 4
| '''Top UV coordinate'''
|-
| 0xA
| float
| 4
| '''Right UV coordinate'''
|-
| 0xE
| float
| 4
| '''Bottom UV coordinate'''
|-
| 0x12
| u32
| 4
| '''Glyph left padding'''
|-
| 0x16
| u32
| 4
| '''Print head advance'''
|-
| 0x1A
| u32
| 4
| '''Glyph right padding'''
|-
| 0x1E
| u32
| 4
| '''Glyph width'''
|-
| 0x22
| u32
| 4
| '''Glyph height'''
|-
| 0x26
| u32
| 4
| '''Kerning index'''
|-
| 0x2A
| colspan=3 {{unknown|End of glyph definition}}
|}

=== Glyph Entry (Version 4) ===

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| u16
| 2
| '''UTF-16 character'''
|-
| 0x2
| float
| 4
| '''Left UV coordinate'''
|-
| 0x6
| float
| 4
| '''Top UV coordinate'''
|-
| 0xA
| float
| 4
| '''Right UV coordinate'''
|-
| 0xE
| float
| 4
| '''Bottom UV coordinate'''
|-
| 0x12
| u8
| 1
| '''Layer Index'''
<ol start="0">
<li>TXTR Red channel is fill, Green channel is outline</li>
<li>TXTR Blue channel is fill, Alpha channel is outline</li>
</ol>
|-
| 0x13
| u32
| 4
| '''Glyph left padding'''
|-
| 0x17
| u32
| 4
| '''Print head advance'''
|-
| 0x1B
| u32
| 4
| '''Glyph right padding'''
|-
| 0x1F
| u32
| 4
| '''Glyph width'''
|-
| 0x23
| u32
| 4
| '''Glyph height'''
|-
| 0x27
| u32
| 4
| '''Kerning index'''
|-
| 0x2B
| colspan=3 {{unknown|End of glyph definition}}
|}

=== Kerning Table ===

This table is at the end of the file, and defines kerning pairs. It starts with a 32-bit count value and then loops the following structure:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 2
| '''Character 1'''
|-
| 0x2
| 2
| '''Character 2'''
|-
| 0x4
| 4
| '''Kerning adjust'''
|-
| 0x8
| colspan=2 {{unknown|End of entry}}
|}

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]
[[Category:Donkey Kong Country Returns]]

MREA (Metroid Prime)

2015-03-14T15:02:16Z

Embyr 75: {{research}}

''See [[MREA (File Format)]] for the other revisions of this format.''

The '''MREA format''' defines areas (rooms) in Metroid Prime. It's a massive format that contains tons of different data, including terrain geometry, collision, objects, lights, and more.

{{todo|There's a LOT of sections that are mostly known, but need some documentation written up. SCLY and collision need separate articles (although the unique parts of the collision format, like the octree, could maybe be documented here). The rest should probably stay on this page.}}
{{research|2|The AROT section is largely unknown, there's a lot of unknowns in the lights section, and we don't know what the unknown/empty sections are for. That's not even touching on how much is unknown in SCLY.}}

== Format ==

Like [[CMDL (Metroid Prime)|CMDL]], MREA files are split up into a number of 32-byte aligned sections. Every section both starts and ends on a 32-byte boundary. These are used to separate different parts of the file; different types of sections typically indicate different sets of data. The header declares the section count and the size of each one; using these is the only way to navigate the file.

=== Header ===

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Magic'''; always 0xDEADBEEF
|-
| 0x4
| 4
| '''Version'''; see [[MREA (File Format)|hub article]]
|-
| 0x8
| 4 × 12
| '''Transform matrix'''
|-
| 0x38
| 4
| '''Mesh count'''
|-
| 0x3C
| 4
| '''Section count''' (SC)
|-
| 0x40
| 4
| '''Geometry section number''' (starts on materials)
|-
| 0x44
| 4
| '''SCLY section number'''
|-
| 0x48
| 4
| '''Collision section number'''
|-
| 0x4C
| 4
| '''Unknown section number'''
|-
| 0x50
| 4
| '''[[Lights_(Metroid_Prime)|Light]] section number'''
|-
| 0x54
| 4
| '''VISI section number'''
|-
| 0x58
| 4
| '''PATH section number'''
|-
| 0x5C
| 4
| '''AROT section number'''
|-
| 0x60
| 4 × SC
| '''Section sizes'''
|-
| colspan=3 {{unknown|End of header; pad to 32 bytes before first section begins}}
|}

=== Geometry ===

''See [[Materials (Metroid Prime)]] and [[Geometry (Metroid Prime)]]''

MREA files have one material section, followed by a number of meshes, each of which has its own set of geometry sections. Each mesh starts with an extra header section which is formatted like this:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| {{unknown|'''Unknown (flags?)'''}}
|-
| 0x4
| 4 × 12
| '''Transform matrix'''
|-
| 0x34
| 4 × 6
| '''Axis-aligned bounding box'''
|-
| 0x4C
| colspan=2 {{unknown|End of mesh header section}}
|}

There's couple small differences you'll usually see on MREA meshes compared to CMDL ones:

* Normals are ''always'' shorts, so vertex format 0 is never used.
* Most MREA meshes use lightmaps, so normally the first UV coordinate on each texture will read from the short UV array. This isn't always the case, though; you need to make sure you check the material so you know where to read from.
* Submeshes will usually have a bounding box in the extra data in the submesh header. This bounding box is used for depth sorting.

=== AROT ===

The AROT section operates on terrain geometry; it's used to implement things like projectile collision with terrain. It's mostly unknown.

=== SCLY ===

{{todo|SCLY is definitely complicated enough to need its own article.}}

The SCLY section contains data for objects.

=== Collision ===

{{todo|Collision needs a separate article because it shares so many similarities with DCLN. How should we document the parts where the format diverges, though?}}

You have three guesses what the collision section is for, and the first two don't count.

=== Unknown Section ===

This one is sandwiched between collision and lights, and usually just contains a single 32-bit "1". Purpose is unknown.

=== Lights ===

This section is for dynamic lights, see the [[Lights_(Metroid_Prime)|Light]] article for details.

=== Visibility Tree ===

This section is labeled "VISI". This section is sometimes not actually present in the file, labeled with a size of 0.

=== Path ===

This is the final section in the file; it's always 0x20 bytes, and its only value is a single [[PATH (File Format)|PATH]] file ID.

== Tools ==

* [https://drive.google.com/file/d/0B9MLV21H7SDvMk9PN1lrM1g3ZVE/view?usp=sharing Parax's MREA maxscript] can import MREA terrain geometry into 3DS Max.

[[Category:File Formats]]
[[Category:Metroid Prime]]

SCAN (Metroid Prime)

2015-03-14T15:01:50Z

Embyr 75: {{research}}

The '''.SCAN file format''' describes scannable objects and has references to several resources. It is a relatively simple format and has a static size.

{{research|2|Too many unknowns.}}

__TOC__

== Format ==

The SCAN format is very simple; it has a header with data that contains general settings related to the scan, and then four structs defining how the scan images work. Even if a scan doesn't use four images, there are always four image structs, which means that the SCAN format has a static size; every SCAN file is 0x89 bytes (or 0xA0 bytes padded).

=== Header ===

The header is rather simple, and consists of the following:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Version'''; 3 for the demo, 5 for the final
|-
| 0x4
| 4
| '''Magic'''; always 0x0BADBEEF
|-
| 0x8
| 4
| '''[[FRME (File Format)|FRME]] ID'''
|-
| 0xC
| 4
| '''Scan text [[STRG (File Format)|STRG]] ID'''
|-
| 0x10
| 4
| '''Scan Speed Flag'''; 0 = normal fast scan, 1 = slower scan (usually found in boss fights)
|-
| 0x14
| 4
| '''Logbook Category'''; see below
|-
| 0x18
| 1
| '''Scan Icon Flag'''; 0 = orange icon, 1 = red icon
|-
| 0x19
| colspan=2 {{unknown|End of header}}
|}

==== Logbook Category ====

There are five possible values:

{| class="wikitable"
! ID
! Category
|-
| 0
| Not a logbook scan
|-
| 1
| Space Pirate Data
|-
| 2
| Chozo Lore
|-
| 3
| Creatures
|-
| 4
| Research
|}

=== Scan Images ===
Following the header is an array of four structs that contain settings for up to four scan images. Although there can be anywhere from 0 to 4 scan images attached to a scan, there are always four scan image entries here. Entries that aren't used have their TXTR ID set to 0xFFFFFFFF, with the rest of the settings mostly left at defaults. They follow this format:

{| class="wikitable"
! Offset
! Size
! Type
! Description
|-
| 0x0
| 4
| long
| '''[[TXTR (Metroid Prime)|TXTR]] ID'''
|-
| 0x4
| 4
| float
| '''Appearance %'''; image will appear when the scan is this% complete. Should range from 0 to 1.
|-
| 0x8
| 4
| long
| '''Image Position'''; See below.
|-
| 0xC
| 4
| long
| {{unknown|'''Unknown'''}}
|-
| 0x10
| 4
| long
| {{unknown|'''Unknown'''}}
|-
| 0x14
| 4
| long
| {{unknown|'''Unknown'''}}
|-
| 0x18
| 4
| float
| {{unknown|'''Unknown'''}}
|-
| 0x1C
| colspan=3 {{unknown|End of entry}}
|}

==== Image Position ====

There are 20 possible values for the scan image's position; there are ten for the left side, and ten for the right:
{| class="wikitable"
! Value
! Size
! Position
! FRME_ScanHud Widget
|-
| 0x00
| 1/4
| Top-left corner
| imagepane_pane0
|-
| 0x01
| 1/4
| Upper-middle-left
| imagepane_pane1
|-
| 0x02
| 1/4
| Lower-middle-left
| imagepane_pane2
|-
| 0x03
| 1/4
| Bottom-left corner
| imagepane_pane3
|-
| 0x04
| 1/2
| Top-left corner
| imagepane_pane01
|-
| 0x05
| 1/2
| Middle-left
| imagepane_pane12
|-
| 0x06
| 1/2
| Bottom-left corner
| imagepane_pane23
|-
| 0x07
| 3/4
| Top-left corner
| imagepane_pane012
|-
| 0x08
| 3/4
| Bottom-left corner
| imagepane_pane123
|-
| 0x09
| 1
| Left side
| imagepane_pane0123
|-
| 0x0A
| 1/4
| Top-right corner
| imagepane_pane4
|-
| 0x0B
| 1/4
| Upper-middle-right
| imagepane_pane5
|-
| 0x0C
| 1/4
| Lower-middle-right
| imagepane_pane6
|-
| 0x0D
| 1/4
| Bottom-right corner
| imagepane_pane7
|-
| 0x0E
| 1/2
| Top-right corner
| imagepane_pane45
|-
| 0x0F
| 1/2
| Middle-right
| imagepane_pane56
|-
| 0x10
| 1/2
| Bottom-right corner
| imagepane_pane67
|-
| 0x11
| 3/4
| Top-right corner
| imagepane_pane456
|-
| 0x12
| 3/4
| Bottom-right corner
| imagepane_pane567
|-
| 0x13
| 1
| Right side
| imagepane_pane4567
|-
|}

<gallery mode=packed heights=200px>
File:Scan_offsets_1.png|Image positions 0x00, 0x01, and 0x02
File:Scan_offsets_3.png|Image positions for 0x04, 0x06, 0x0E, and 0x10
File:Scan_offset_101.png|Image positions for 0x03, 0x05, and 0x0F. Note that 0x03 appears only for this scan (Omega Pirate's projectiles) and no others.
File:Scan_offsets_10.png|Image positions for 0x09 and 0x13
File:Scan_position_10000.png|This unused Chozo Elder scan (hacked onto Parasite Queen) shows image positions 0x0A and 0x0D. This scan is the only one where these positions are used.
File:Scan_position_99.png|Image positions for 0x0B and 0x0C (unused)
File:Scan_offset_11.png|Image positions for 0x07 and 0x11 (unused)
File:Scan_offset_12.png|Image positions for 0x08 and 0x12 (unused)
</gallery>

==== Fly In Behavior ====

The first scan image to appear (based on the appearance percent value) will "fly in" from the side of the screen toward the center. The remaining images will "fade in" without moving. The only exception to this is when the first image to appear is a "blank" image with no associated [[TXTR (Metroid Prime)|TXTR]]. In this case, no image will fly in (i.e., all images will fade in).

[[Category:File Formats]]
[[Category:Metroid Prime]]

FRME (File Format)

2015-03-14T15:01:23Z

Embyr 75: {{research}}

The '''FRME format''' is used to create frames for the GUI and HUD.

{{research|2|We don't know a lot of settings in a lot of the widgets. Also, a lot of the widget structures are incomplete.}}

__TOC__

== Format ==

The FRME format is composed of a short header and then a number of widgets.

=== Header ===

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x4
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x8
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xC
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x10
| 4
| '''Widget count'''
|}

=== Widgets ===

Each widget has a fourCC denoting its type, a name, and usually a parent widget name. There are no IDs or indices used in the file; widgets reference each other by name. The following values are set on every widget:

{| class="wikitable"
! Type
! Count
! Description
|-
| char
| 4
| '''Widget type''' fourCC
|-
| string
| 1
| '''Widget name'''
|-
| string
| 1
| '''Parent name'''
|}

Following this are a list of parameters; the number, type, and usage of the parameters is different for different widgets.

==== Head Widget (HWIG) ====

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 2
| {{unknown|'''Unknown'''}}
|-
| 0x2
| 2
| {{unknown|'''Unknown'''}}
|-
| 0x4
| 4
| '''R''' (float)
|-
| 0x8
| 4
| '''G''' (float)
|-
| 0xC
| 4
| '''B''' (float)
|-
| 0x10
| 4
| '''A''' (float)
|-
| 0x14
| 4
| {{unknown|'''Unknown'''; doesn't seem to do anything}}
|-
| 0x18
| 1
| {{unknown|'''Unknown'''; tends to crash the game if modified}}
|-
| 0x19
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x1D
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x21
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x25
| 4
| '''X Scale'''
|-
| 0x29
| 4
| '''X Position'''
|-
| 0x2D
| 4
| {{unknown|'''X Unknown''' (creates a skew effect)}}
|-
| 0x31
| 4
| {{unknown|'''X Unknown''' (creates a scale effect)}}
|-
| 0x35
| 4
| '''Y Scale'''
|-
| 0x39
| 4
| '''Y Position'''
|-
| 0x3D
| 4
| {{unknown|'''Y Unknown''' (creates a skew effect)}}
|-
| 0x41
| 4
| {{unknown|'''Y Unknown''' (creates a scale effect)}}
|-
| 0x45
| 4
| '''Z Scale'''
|-
| 0x49
| 4
| '''Z Position'''
|-
| 0x4D
| 4
| {{unknown|'''Z Unknown''' (creates a skew effect)}}
|-
| 0x51
| 4
| {{unknown|'''Z Unknown''' (creates a scale effect)}}
|-
| 0x55
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x59
| 2
| {{unknown|'''Unknown'''}}
|-
| 0x5B
| colspan=2 {{unknown|End of widget}}
|}

==== Base Widget (BWIG) ====

Incomplete. This widget might have the same parameters as HWIG.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 2
| {{unknown|'''Unknown'''}}
|-
| 0x2
| 2
| {{unknown|'''Unknown'''}}
|}

==== Table Group (TBGP) ====

==== Camera (CAMR) ====

Incomplete.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''R''' (float) (RGBA settings don't seem to do anything on cameras)
|-
| 0x4
| 4
| '''G''' (float)
|-
| 0x8
| 4
| '''B''' (float)
|-
| 0xC
| 4
| '''A''' (float)
|-
| 0x10
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x14
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x18
| 4
| {{unknown|'''Something - Left'''}}
|-
| 0x1C
| 4
| {{unknown|'''Something - Right'''}}
|-
| 0x20
| 4
| {{unknown|'''Something - Top'''}}
|-
| 0x24
| 4
| {{unknown|'''Something - Bottom'''}}
|}

==== Light (LITE) ====

==== Model (MODL) ====

==== Text Pane (TXPN) ====

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 2
| {{unknown|'''Unknown'''}}
|-
| 0x2
| 2
| {{unknown|'''Unknown'''}}
|-
| 0x4
| 4
| '''R''' (float)
|-
| 0x8
| 4
| '''G''' (float)
|-
| 0xC
| 4
| '''B''' (float)
|-
| 0x10
| 4
| '''A''' (float)
|-
| 0x14
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x18
| 4
| '''Width''' (float)
|-
| 0x1C
| 4
| '''Height''' (float)
|-
| 0x20
| 4
| '''X Offset''' (float)
|-
| 0x24
| 4
| {{unknown|'''Unknown''' (float)}}
|-
| 0x28
| 4
| '''Y Offset''' (float)
|-
| 0x2C
| 4
| {{unknown|'''Unknown''' (float)}}
|-
| 0x30
| 2
| {{unknown|'''Unknown'''}}
|-
| 0x32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x36
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x3E
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x42
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x46
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x4A
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x4E
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x52
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x56
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x5A
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x5E
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x62
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x63
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x67
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x6B
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x6F
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x73
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x77
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x7B
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x7F
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x83
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x87
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x8B
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x8F
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x93
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x97
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x9B
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x9F
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xA3
| 2
| {{unknown|'''Unknown'''}}
|-
| 0xA5
| colspan=2 {{unknown|End of widget}}
|}

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]
[[Category:Donkey Kong Country Returns]]

CMDL (Tropical Freeze)

2015-03-14T15:00:07Z

Embyr 75: {{research}}

''See [[CMDL (File Format)]] for the other revisions of this format.''

The '''CMDL, SMDL, and WMDL''' format are Tropical Freeze's three model formats; CMDL is a generic model format, SMDL is for skinned models, and WMDL is for world (terrain) models. All three are the same basic format, with SMDL and WMDL each containing an extra data section at the start of the file. With the Wii U's graphics system being updated from GX to GX2, the Retro model format has been dramatically overhauled, bearing little to no resemblance to the previous CMDL format found in DKCR and the Prime series.

{{research|2|There's still a lot of unknown data. The entire optional section at the end of HEAD is completely unknown to me and there's lots of scattered unknown values.}}

__TOC__

== Format ==

After the [[RFRM Header]], the first section of the file is SKHD in SMDL, and WDHD in WMDL. Following those extra sections, all three formats start with a header.

=== HEAD ===

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 24
| '''"HEAD" [[Section Header (Tropical Freeze)|section header]]
|-
| 0x18
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x1C
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x20
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x24
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x28
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x2C
| 24
| '''Axis-aligned bounding box'''
|-
| 0x30
| 4
| '''Extra data flag'''
|}

If the ending flag is 1, then a large chunk of extra data follows before the next section begins; otherwise, the HEAD section ends.

=== MTRL ===

The MTRL section has a 32-bit material count, then lays out its materials one after the other. The material structure is somewhat complicated; each material has a name, something that wasn't present in Retro's previous material formats, as well as a shader ID. The rest of the material structure appears to be defining parameters to pass to the shader. This needs a lot more research to determine what the parameters are and what the different data is.

{| class="wikitable"
! Type
! Size
! Description
|-
| string
| -
| '''Name''' (zero-terminated)
|-
| [[MTRL (File Format)|MTRL]]
| 16
| '''Shader ID'''
|-
| char[4]
| 4
| '''Shading type fourCC'''; can be PHNG, LAMB, SURF, or FURM
|-
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| u32
| 4
| '''Subsection count'''
|}

Material subsections each have a fourCC name and a type identifer, followed by a set of parameters. The type and number of parameters is dependent on the subsection type; there are five known types currently.

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| char[4]
| 4
| '''Section name fourCC'''
|-
| 0x4
| u32
| 4
| '''Section type'''
|-
| 0x8
| struct
| -
| '''Section data struct'''; type varies based on the section type value
|-
| colspan=4 {{unknown|End of subsection; next one begins}}
|}

==== Type 0: Texture Map ====

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| [[TXTR (Tropical Freeze)|TXTR]]
| 0x10
| '''Texture ID'''
|-
| 0x10
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x14
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x18
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x1C
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x20
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x24
| colspan=3 {{unknown|End of struct}}
|}

==== Type 1: Unknown ====

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x4
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x8
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xC
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x10
| colspan=3 {{unknown|End of struct}}
|}

==== Type 2: Unknown ====

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x4
| colspan=3 {{unknown|End of struct}}
|}

==== Type 4: Unknown ====

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x4
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x8
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xC
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x10
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x14
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x18
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x1C
| float
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x20
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x24
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x28
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x2C
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x30
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x34
| u8
| 1
| {{unknown|'''Unknown'''}}
|-
| 0x35
| [[TXTR (Tropical Freeze)|TXTR]]
| 0x10
| {{unknown|'''Unknown Texture ID'''}}
|-
| 0x45
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x49
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x4D
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x51
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x55
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x59
| [[TXTR (Tropical Freeze)|TXTR]]
| 0x10
| {{unknown|'''Unknown Texture ID'''}}
|-
| 0x69
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x6D
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x71
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x75
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x79
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x7D
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x81
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x85
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x89
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x8D
| colspan=3 {{unknown|End of struct}}
|}

==== Type 5: Unknown ====

{| class="wikitable"
! Offset
! Type
! Size
! Description
|-
| 0x0
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x4
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x8
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xC
| u32
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x10
| colspan=3 {{unknown|End of struct}}
|}

=== MESH ===

The MESH section does what the name suggests: it defines submeshes. The MESH section header is as follows:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 24
| '''"HEAD" [[Section Header (Tropical Freeze)|section header]]
|-
| 0x18
| 4
| Submesh count
|-
| 0x1C
| colspan=2 {{unknown|End of MESH header}}
|}

Each submesh definition is structured as follows:

{|class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| {{unknown|'''Unknown'''; always 3?}}
|-
| 0x4
| 2
| '''Material ID'''
|-
| 0x6
| 1
| '''Vertex buffer ID'''
|-
| 0x7
| 1
| '''Index buffer ID'''
|-
| 0x8
| 4
| '''Start index'''
|-
| 0xC
| 4
| '''Index count'''
|-
| 0x10
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x14
| 1
| {{unknown|'''Unknown'''; usually seems to be either 0 or 1, possibly a bool value}}
|-
| 0x15
| colspan=2 {{unknown|End of submesh definition}}
|}

=== VBUF ===

The VBUF section defines vertex buffers; each buffer can have different vertex types, with different strides and attributes.

==== Header ====

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 24
| '''"VBUF" [[Section Header (Tropical Freeze)|section header]]
|-
| 0x18
| 4
| Vertex buffer count
|-
| 0x1C
| colspan=2 {{unknown|End of VBUF header}}
|}

==== Vertex Buffer ====

{|class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Vertex count'''
|-
| 0x4
| 4
| '''Attrib count''' (AC)
|-
| 0x8
| 0x14 × AC
| '''Vertex attributes'''
|-
| colspan=3 {{unknown|End of vertex buffer}}
|}

==== Vertex Attribute ====

{|class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x4
| 4
| '''Offset'''
|-
| 0x8
| 4
| '''Stride'''
|-
| 0xC
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x10
| 4
|{{unknown|'''Unknown''' (likely attrib type/format)}}
|-
| 0x14
| colspan=2 {{unknown|End of attribute}}
|}

=== IBUF ===

Just like how the VBUF section defines vertex buffers, the IBUF section defines index buffers. Each index buffer only has one value associated with it, so it's fairly simple, and you generally will only see one or two index buffers per file.

==== Header ====

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 24
| '''"IBUF" [[Section Header (Tropical Freeze)|section header]]
|-
| 0x18
| 4
| Index buffer count
|-
| 0x1C
| colspan=2 {{unknown|End of IBUF header}}
|}

==== Index Buffer ====

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Format''' (1 means unsigned short; 2 means unsigned long)
|-
| 0x4
| colspan=2 {{unknown|End of index buffer}}
|}

=== GPU ===

The GPU section contains raw buffer data that's fed to the GPU. It's essentially just a giant blob with all the vertex and index buffers laid out next to each other. The tricky part is, all the buffer data is [[LZSS Compression|LZSS-compressed]], and the metadata needed to decompress it is stored in the pak rather than in the files themselves; not only that, but that metadata is also the only way to distinguish the different buffers from each other.

As such, this section can't be read correctly if the model file is unpacked and completely left as-is; it needs to be either read directly from the pak, or the metadata needs to be added to the file in some way. A good unpacker should append the metadata to the end of the file; a pre-decompressed file needs the buffer sizes or offsets inserted into the file data somewhere.

== PAK Metadata ==

The pak metadata for the model formats contains mainly information related to the size and layout of the GPU section, and the metadata required to locate and decompress specific buffers within it.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| {{unknown|'''Unknown'''; always 4?}}
|-
| 0x4
| 4
| '''GPU section offset'''
|-
| 0x8
| 4
| '''GPU chunk count''' (CC)
|-
| 0xC
| 8 × CC
| '''GPU chunk definitions'''
|-
| -
| 4
| '''Compressed vertex buffer count''' (VC)
|-
| -
| 0x10 × VC
| '''Vertex buffer definitions'''
|-
| -
| 4
| '''Compressed index buffer count''' (IC)
|-
| -
| 0x10 × IC
| '''Index buffer definitions'''
|-
| colspan = 3 {{unknown|End of pak metadata}}
|}

=== GPU Chunk ===

For large models, the GPU section might be split up into multiple chunks, rather than read as one data buffer; all offsets into the GPU section will be relative to the start of the chosen chunk.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Size'''
|-
| 0x4
| 4
| '''Offset'''
|-
| 0x8
| colspan=2 {{unknown|End of GPU chunk definition}}
|}

=== Compressed Buffer ===

The format for compressed buffer definitions is the same regardless of buffer type (vertex/index).

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''GPU chunk index'''
|-
| 0x4
| 4
| '''Start offset''' (relative to the start of the chosen GPU chunk)
|-
| 0x8
| 4
| '''Compressed size'''
|-
| 0xC
| 4
| '''Decompressed size'''
|-
| 0x10
| colspan=2 {{unknown|End of compressed buffer definition}}
|}

[[Category:File Formats]]
[[Category:Donkey Kong Country: Tropical Freeze]]

Chunk Descriptor (Tropical Freeze)

2015-03-14T14:59:11Z

Embyr 75: {{research}}

The '''section header''' is a very common 24-byte header that denotes different data sections, found in many different Donkey Kong Country: Tropical Freeze formats.

{{research|2|A few unknown values.}}

__TOC__

== Format ==

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Section type''' fourCC
|-
| 0x4
| 8
| '''Section size'''
|-
| 0xC
| 4
| {{unknown|'''Unknown'''; usually 1}}
|-
| 0x10
| 4
| {{unknown|'''Unknown'''; usually 0}}
|-
| 0x14
| 4
| {{unknown|'''Unknown'''; usually 0}}
|-
| 0x18
| colspan=2 {{unknown|End of header}}
|}

[[Category:Donkey Kong Country: Tropical Freeze]]

Form Descriptor (Tropical Freeze)

2015-03-14T14:58:33Z

Embyr 75: {{research}}

RFRM is a common header located in most Donkey Kong Country: Tropical Freeze formats, and serves as a container for most data in the game.

{{research|2|Some unknown values.}}

__TOC__

== Format ==

The RFRM header is always 0x20 bytes large.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''"RFRM" tag'''
|-
| 0x4
| 8
| '''Data size'''
|-
| 0xC
| 8
| {{unknown|'''Unknown'''; always 0?}}
|-
| 0x14
| 4
| '''Data type''' fourCC
|-
| 0x18
| 4
| {{unknown|'''Unknown'''}}
|-
| 0x1C
| 4
| {{unknown|'''Unknown'''; always matches the previous value}}
|-
| 0x20
| colspan=2 {{unknown|End of header}}
|}

[[Category:File Formats]]
[[Category:Donkey Kong Country: Tropical Freeze]]

AGSC (File Format)

2015-03-14T14:57:52Z

Embyr 75: {{research}}

'''AGSC''' is the sound effect format for Metroid Prime and Metroid Prime 2: Echoes. Each AGSC file contains a group of sound effects. The first two Metroid Prime games utilize the MusyX audio engine created by Factor5 and as a result, AGSC files are essentially just embedded MusyX files.

The audio codec used in AGSC is the standard GameCube DSP ADPCM codec.

{{todo|Better descriptions for how SoundMacros work and a description for what each command does.}}
{{research|2|The proj chunk and the sdir chunk still need some reverse-engineering.}}

__TOC__

== Format ==

The AGSC format is essentially four data chunks combined into one resource, each of which is a standard MusyX file. Of the four data chunks (pool, proj, samp, and sdir), there's one for sound engine scripts, one for sound properties, one for actual ADPCM sound data, and one for sound metadata. The main difference between Prime 1 and 2 is the header, and some slight changes in the way the four chunks are organized. In Metroid Prime, each chunk begins with its own size value; in Metroid Prime 2, every chunk instead has its size listed at the beginning of the file, at the end of the header. In addition, in Metroid Prime, the third chunk is samp, and the fourth is sdir; in Metroid Prime 2, it's the other way around.

=== Header ===

==== Metroid Prime ====

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| '''D'''
| '''Audio Directory'''. Always "Audio/." Zero-terminated.
|-
| 0x0 + D
| '''N'''
| '''Audio Group Name'''. Zero-terminated.
|-
| 0x0 + D + N
|colspan=2 {{unknown|End of header}}
|}

==== Metroid Prime 2 ====

{|class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| {{unknown|'''Unknown'''; always 1}}
|-
| 0x4
| D
| '''Audio Group Name'''. Zero-terminated.
|-
| 0x4 + D
| 4
| '''Pool size'''
|-
| 0x8 + D
| 4
| '''Project size'''
|-
| 0xC + D
| 4
| '''Sample directory size'''
|-
| 0x10 + D
| 4
| '''Sample size'''
|-
| 0x14 + D
| colspan=2 {{unknown|End of header}}
|}

=== Pool ===

The Pool chunk contains tables for SoundMacros, ADSR, keymaps, and layers, if applicable. It starts with a 16-byte header before the different data tables begin.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''SoundMacros Offset''' (always 0x10)
|-
| 0x4
| 4
| '''Tables Offset'''
|-
| 0x8
| 4
| '''Keymaps Offset'''
|-
| 0xC
| 4
| '''Layers Offset'''
|-
| 0x10
| colspan=2 {{unknown|End of entry}}
|}

==== SoundMacros ====

The first Pool table denotes MusyX's '''SoundMacros''', small scripts that apply various effects on the sounds in the game. Each macro is composed of a header followed by a number of commands; each command specifies its type through a single-byte command ID, then specifies the parameters of that particular command, which vary.

The header of each SoundMacro is eight bytes, and is structured as follows:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''SoundMacro size''' ''(note: includes the size value itself)''
|-
| 0x4
| 2
| '''SoundMacro ID'''
|-
| 0x6
| 2
| {{unknown|'''Unknown'''; usually 0}}
|-
| 0x8
| colspan=2 {{unknown|Commands begin}}
|}

On the commands, each 4 bytes were originally little endian, but have been swapped to big endian in the AGSC files (despite not being longs). To read the data as originally formatted, every four bytes needs to be byte-swapped. Each command is 8 bytes, and is structured as follows:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 1
| '''Command ID''' (varies; there are 79 known commands in the MusyX audio engine.)
|-
| 0x1
| 7
| '''Command arguments''' (varies between commands)
|-
| 0x8
| colspan=2 {{unknown|End of entry}}
|}

The SoundMacro will continue with commands until it terminates when the END command is executed. The command ID for END is 0 and has null command arguments; the next SoundMacro begins after reading it.

These are the possible commands:

{| class="wikitable"
! width="2%" | ID
! width="7%" | Name
! colspan="91%" | Arguments
|-
| 0x1
| STOP
| width="13%" {{unknown|}}
| width="13%" {{unknown|}}
| width="13%" {{unknown|}}
| width="13%" {{unknown|}}
| width="13%" {{unknown|}}
| width="13%" {{unknown|}}
| width="13%" {{unknown|}}
|-
| 0x2
| SPLITKEY
| Keynumber
| colspan="2" | SoundMacro ID
| colspan="2" | SoundMacro step
| colspan="2" {{unknown|}}
|-
| 0x3
| SPLITVEL
| Velocity
| colspan="2" | SoundMacro ID
| colspan="2" | SoundMacro step
| colspan="2" {{unknown|}}
|-
| 0x4
| WAIT_TICKS
| Keyoff
| Random
| Sampleend
| Absolute
| ms switch
| colspan="2" | Ticks/Millisec.
|-
| 0x5
| LOOP
| Keyoff
| Random
| Sampleend
| colspan="2" | SoundMacro step
| colspan="2" | Times
|-
| 0x6
| GOTO
| {{unknown|}}
| colspan="2" | SoundMacro ID
| colspan="2" | SoundMacro step
| colspan="2" {{unknown|}}
|-
| 0x7
| WAIT_MS
| Keyoff
| Random
| Sample end
| Absolute
| {{unknown|}}
| colspan="2" | Millisec.
|-
| 0x8
| PLAYMACRO
| Addnote
| colspan="2" | SoundMacro ID
| colspan="2" | SoundMacro step
| Priority
| MaxVoices
|-
| 0x9
| SENDKEYOFF
| Variable
| Last started
| colspan="5" {{unknown|}}
|-
| 0xA
| SPLITMOD
| Mod value
| colspan="2" | SoundMacro ID
| colspan="2" | SoundMacro step
| colspan="2" {{unknown|}}
|-
| 0xB
| PIANOPAN
| Scale
| Centerkey
| Centerpan
| colspan="4" {{unknown|}}
|-
| 0xC
| SETADSR
| colspan="2" | Table-ID (ADSR)
| DLS mode
| colspan="4" {{unknown|}}
|-
| 0xD
| SCALEVOLUME
| Scale
| Add
| colspan="2" | Table-ID (Curve)
| Org vol
| colspan="2" {{unknown|}}
|-
| 0xE
| PANNING
| Pan position
| colspan="2" | Time ms
| Width
| colspan="3" {{unknown|}}
|-
| 0xF
| ENVELOPE
| Scale
| Add
| colspan="2" | Table-ID (Curve)
| Org vol
| colspan="2" {{unknown|}}
|-
| 0x10
| STARTSAMPLE
| colspan="2" | Sample-ID
| Mode
| colspan="4" | Offset
|-
| 0x11
| STOPSAMPLE
| colspan="7" {{unknown|}}
|-
| 0x12
| KEYOFF
| colspan="7" {{unknown|}}
|-
| 0x13
| SPLITRND
| RND
| colspan="2" | SoundMacro ID
| colspan="2" | SoundMacro step
| colspan="2" {{unknown|}}
|-
| 0x14
| FADE-IN
| Scale
| Add
| colspan="2" | Table-ID (Curve)
| ms switch
| colspan="2" | Ticks/Millisec.
|-
| 0x15
| SPANNING
| Pan position
| colspan="2" | Time ms
| Width
| colspan="3" {{unknown|}}
|-
| 0x16
| SETADSRCTRL
| Attack
| Decay
| Sustain
| Relase
| colspan="3" {{unknown|}}
|-
| 0x17
| RNDNOTE
| Note Lo
| Detune
| Note Hi
| Fixed/Free
| Abs/Rel
| colspan="2" {{unknown|}}
|-
| 0x18
| ADDNOTE
| Add
| Detune
| org key
| {{unknown|}}
| ms switch
| colspan="2" | Ticks/Millisec.
|-
| 0x19
| SETNOTE
| Key
| Detune
| colspan="2" {{unknown|}}
| ms switch
| colspan="2" | Ticks/Millisec.
|-
| 0x1A
| LASTNOTE
| Add
| detune
| colspan="2" {{unknown|}}
| ms switch
| colspan="2" | Ticks/Millisec.
|-
| 0x1B
| PORTAMENTO
| Port. State
| Port. Type
| colspan="2" {{unknown|}}
| ms switch
| colspan="2" | Ticks/Millisec.
|-
| 0x1C
| VIBRATO
| Level note
| Level fine
| Modwheel flag
| {{unknown|}}
| ms switch
| colspan="2" | Ticks/Millisec.
|-
| 0x1D
| PITCHSWEEP1
| Times
| colspan="2" | Add
| {{unknown|}}
| ms switch
| colspan="2" | Ticks/Millisec.
|-
| 0x1E
| PITCHSWEEP2
| Times
| colspan="2" | Add
| {{unknown|}}
| ms switch
| colspan="2" | Ticks/Millisec.
|-
| 0x1F
| SETPITCH
| colspan="3" | Frequency (Hz)
| colspan="2" | Fine
| colspan="2" {{unknown|}}
|-
| 0x20
| SETPITCHADSR
| colspan="2" | Table-ID (ADSR)
| {{unknown|}}
| Note range
| Detune range
| colspan="2" {{unknown|}}
|-
| 0x21
| SCALEVOLUME DLS
| colspan="2" | Scale
| Org vol
| colspan="4" {{unknown|}}
|-
| 0x22
| MOD2VIBRANGE
| Key range
| Cent range
| colspan="5" {{unknown|}}
|-
| 0x23
| SETUP TREMOLO
| colspan="2" | Tremolo scale
| {{unknown|}}
| colspan="2" | Modw. add scale
| colspan="2" {{unknown|}}
|-
| 0x24
| RETURN
| colspan="7" {{unknown|}}
|-
| 0x25
| GOSUB
| {{unknown|}}
| colspan="2" | SoundMacro ID
| colspan="2" | SoundMacro step
| colspan="2" {{unknown|}}
|-
| 0x28
| TRAP_EVENT
| Event
| colspan="2" | SoundMacro ID
| colspan="2" | SoundMacro step
| colspan="2" {{unknown|}}
|-
| 0x29
| SEND_MESSAGE
| IsVar
| colspan="2" | Macro
| VID
| Varibale
| colspan="2" {{unknown|}}
|-
| 0x2A
| GET_MESSAGE
| Varibale
| colspan="6" {{unknown|}}
|-
| 0x2B
| GET_VID
| Varibale
| PLAY_MACRO
| colspan="5" {{unknown|}}
|-
| 0x30
| ADDAGECOUNT
| {{unknown|}}
| colspan="2" | Add
| colspan="4" {{unknown|}}
|-
| 0x31
| SETAGECOUNT
| {{unknown|}}
| colspan="2" | Counter
| colspan="4" {{unknown|}}
|-
| 0x32
| SENDFLAG
| Flag-ID
| Value
| colspan="5" {{unknown|}}
|-
| 0x33
| PITCHWHEELR
| Range up
| Range down
| colspan="5" {{unknown|}}
|-
| 0x34
| SETPRIORITY
| Prio
| colspan="6" {{unknown|}}
|-
| 0x35
| ADDPRIORITY
| {{unknown|}}
| colspan="2" | Add
| colspan="4" {{unknown|}}
|-
| 0x36
| AGECNTSPEED
| colspan="3" {{unknown|}}
| colspan="4" | Time
|-
| 0x37
| AGECNTVEL
| {{unknown|}}
| colspan="2" | AGE Base
| colspan="2" | AGE Scale
| colspan="2" {{unknown|}}
|-
| 0x40
| VOL_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x41
| PAN_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x42
| PitchW_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x43
| ModW_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x44
| PEDAL_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x45
| PORTA_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x46
| REVERB_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x47
| SPAN_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x48
| DOPPLER_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x49
| TREMOLO_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x4A
| PREA_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x4B
| PREB_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x4C
| POSTB_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x4D
| AUXAFX_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x4E
| AUXBFX_SELECT
| MIDI Contr.
| colspan="2" | Scaling percentage
| Combine
| is var.
| Fine scaling
| {{unknown|}}
|-
| 0x50
| SETUP_LFO
| LFO Nr.
| colspan="2" | Period in ms
| colspan="4" {{unknown|}}
|-
| 0x58
| MODE_SELECT
| DLS vol
| ITD
| colspan="5" {{unknown|}}
|-
| 0x59
| SET_KEYGROUP
| group
| kill
| colspan="5" {{unknown|}}
|-
| 0x5A
| SRCMODE_SELECT
| SRC type
| Type 0 SRC filter
| colspan="5" {{unknown|}}
|-
| 0x60
| ADD_VARS
| Var/Ctrl
| A =
| Var/Ctrl
| B +
| Var/Ctrl
| C
| {{unknown|}}
|-
| 0x61
| SUB_VARS
| Var/Ctrl
| A =
| Var/Ctrl
| B -
| Var/Ctrl
| C
| {{unknown|}}
|-
| 0x62
| MUL_VARS
| Var/Ctrl
| A =
| Var/Ctrl
| B *
| Var/Ctrl
| C
| {{unknown|}}
|-
| 0x63
| DIV_VARS
| Var/Ctrl
| A =
| Var/Ctrl
| B /
| Var/Ctrl
| C
| {{unknown|}}
|-
| 0x64
| ADDI_VARS
| Var/Ctrl
| A =
| Var/Ctrl
| B +
| colspan="2" | Immediate
| {{unknown|}}
|-
| 0x70
| IF_EQUAL
| Ctrl
| A ==
| Ctrl
| B
| Not
| colspan="2" | SoundMacro Step
|-
| 0x71
| IF_LESS
| Ctrl
| A <
| Ctrl
| B
| Not
| colspan="2" | SoundMacro Step
|-
| 0x0
| END
| colspan="7" {{unknown|}}
|}

After the last soundmacro, the table terminated by a value of 0xFFFF.

==== Tables ====

'''Tables''' have two functions: for defining curves for volume scaling, or to be used as ADSR envelopes.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Table size'''; (usually 0x10)
|-
| 0x4
| 2
| '''Table ID'''
|-
| 0x6
| 2
| {{unknown|'''Unknown'''}}; (always 0)
|-
| 0x8
| 1
| '''Attack time (0-255 milliseconds)'''; no multiplication is done to the value
|-
| 0x9
| 1
| '''Attack time (0-65280 milliseconds)'''; multiply value by 256
|-
| 0xA
| 1
| '''Decay time (0-255 milliseconds)'''; no multiplication is done to the value
|-
| 0xB
| 1
| '''Decay time (0-65280 milliseconds)'''; multiply value by 256
|-
| 0xC
| 1
| '''Sustain (percentage)'''; multiply value by 0.0244
|-
| 0xD
| 1
| '''Sustain (percentage)'''; multiply value by 6.25
|-
| 0xE
| 1
| '''Release time (0-255 milliseconds)'''; no multiplication is done to the value
|-
| 0xF
| 1
| '''Release time (0-65280 milliseconds)'''; multiply value by 256
|-
| 0x10
| colspan=2 {{unknown|End of entry}}
|}

The entire Pool chunk is terminated by a value of 0xFFFF.

=== Project ===

The Project properties chunk contains values for the sounds, including priority, polyphony, volume, etc.

{|class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''Proj chunk size'''
|-
| 0x2
| 2
| {{unknown|'''Unknown'''}}
|-
| 0x4
| 2
| {{unknown|'''Unknown'''}}; Always 0x1
|-
| 0x8
| 4
| '''SoundMacro ID table offset'''
|-
| 0xC
| 4
| '''Sample ID table offset'''
|-
| 0x10
| 4
| '''Tables table offset'''
|-
| 0x14
| 4
| '''Keymaps table offset'''
|-
| 0x18
| 4
| '''Layers table offset'''
|-
| 0x1C
| 4
| '''SoundMacro Settings Table offset'''
|-
| 0x20
| 4
| '''Unknown Table D offset''' ''(usually 0, indicating table is not present)''
|-
| 0x24
| 4
| '''Unknown Table E offset''' ''(usually 0, indicating table is not present)''
|-
| 0x20
| colspan=2 {{unknown|End of proj header}}
|}

After the header are a number of data tables.

==== SoundMacro ID Table ====

This is a table of shorts; there's no count value, so it's terminated with a value of 0xFFFF. It's a list of SoundMacro IDs present in the file. Occasionally there's gaps in the list; these gaps are signified by the top bit, 0x8000, being set on the size value preceding the gap.

==== Sample ID Table ====

This functions the same way as the SoundMacro ID table, but it contains a list sample IDs instead.

==== SoundMacro Settings ====

This table begins with a 16-bit count value, then 16 bits of padding. Each entry in the table is 10 bytes.

{|class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 2
| '''ID'''; referenced in [[EVNT]]
|-
| 0x2
| 2
| '''SoundMacro ID'''
|-
| 0x4
| 1
| '''Max number of voices'''
|-
| 0x5
| 1
| '''Priority'''; voices are limited, so priority is used to play more important sounds over others
|-
| 0x6
| 1
| '''Definite Velocity'''; volume (usually 7F)
|-
| 0x7
| 1
| '''Panning'''
|-
| 0x8
| 2
| '''Definite Key'''; The default pitch (usually 0x3C00... the second byte may possibly be the MIDI channel)
|}

=== Sample ===

The Sample chunk is all the sound data encoded using the standard Gamecube DSP ADPCM codec. It can be decoded the same way as a [[DSP (File Format)|DSP]] file. Each sound's size is padded to 32 bytes before the next sound's data begins.

=== Sample Directory ===

The Sample Directory chunk (chunk 4 in Metroid Prime, chunk 3 in Metroid Prime 2) is made up of two sets of tables. The structure of both these tables is identical between both games.

==== Table A ====

The first metadata table has one entry per sound, and is terminated with 0xFFFFFFFF; since there's no known sound count anywhere in the file, the only way to read this correctly is to read until you reach the terminator value. Each entry is 0x20 bytes long.

{|class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 2
| '''Sound ID'''
|-
| 0x2
| 2
| '''Padding'''; always 0
|-
| 0x4
| 4
| '''Sound start offset''', relative to the start of the ADPCM chunk
|-
| 0x8
| 4
| {{unknown|'''Unknown'''}}
|-
| 0xC
| 2
| '''Pitch'''; stored as a half-float, always 0x3C00 (1.0)
|-
| 0xE
| 2
| '''Sample rate'''
|-
| 0x10
| 4
| '''Number of samples'''
|-
| 0x14
| 4
| '''Loop start sample'''
|-
| 0x18
| 4
| '''Loop length''', in samples. To get the loop end sample, add this to the start sample and subtract 1.
|-
| 0x1C
| 4
| '''Table B entry offset''', relative to the start of the sound metadata chunk
|-
| 0x20
| colspan=2 {{unknown|End of entry}}
|}

==== Table B ====

These are accessed through the offsets in table A's entries; note that it might not match the sound count, because the same entry in this table can be used with multiple sounds. Each entry is 0x28 bytes long.

{|class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 2
| {{unknown|'''Unknown'''; always 8}}
|-
| 0x2
| 1
| '''Initial predictor/scale''' (matches first frame header)
|-
| 0x3
| 1
| '''Loop predictor/scale''' (matches loop start frame header)
|-
| 0x4
| 2
| '''Loop context sample history 1'''
|-
| 0x6
| 2
| '''Loop context sample history 2'''
|-
| 0x8
| 2 × 16
| '''Decode coefficients'''
|-
| 0x28
| colspan=2 {{unknown|End of entry}}
|}

== Tools ==

* [https://drive.google.com/file/d/0B9MLV21H7SDvemgwN1daYnliSjA/view?usp=sharing Prime Audio Decoder] by Parax will dump all sound effects contained in a given AGSC file.

[[Category:File Formats]]
[[Category:Audio]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]

CTWK (File Format)

2015-02-01T07:37:35Z

Embyr 75: {{research}}

The '''CTWK format''' is used to store tweak data in Metroid Prime, which allows the modification of lots of small things like the amount and type of damage each weapon does, the Hard Mode damage multiplier, etc. Each CTWK file is essentially a data dump, so there's no real structure.

{{todo|Documenting what tweaks are available in which files. Also, see talk page.}}
{{research|3|Someone needs to figure out what each tweak does, which unfortunately can only really be done either through trial and error or by disassembling the game.}}

[[Category:File Formats]]
[[Category:Metroid Prime]]

WPSC (File Format)

2015-02-01T07:37:23Z

Embyr 75: {{research}}

The '''WPSC format''' is used for weapon projectile data in the Prime series.

{{research|3|There is nothing known about this format.}}

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]

SWHC (File Format)

2015-02-01T07:37:04Z

Embyr 75: {{research}}

The '''SWHC format''' is used for swoosh particle data in the Prime series.

{{research|3|Nothing is known about this format.}}

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]
[[Category:Donkey Kong Country Returns]]

CSNG (File Format)

2015-02-01T07:36:53Z

Embyr 75: {{research}}

The '''CSNG format''' contains MIDI data. It appears in Metroid Prime 1 and 2.

{{research|3|Nothing is known about this format.}}

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]

ANCS (File Format)

2015-02-01T07:36:19Z

Embyr 75: {{research}}

The '''ANCS format''' defines characters for animation in Metroid Prime 1 and 2. Starting in Metroid Prime 3, it was replaced by the [[CHAR (Metroid Prime 3)|CHAR]] format. The extension stands for '''AN'''imation '''C'''haracter '''S'''et.

{{todo|Notate Metroid Prime 2 differences.}}
{{research|3|Most of the file structure is known, but we still don't know what any of it actually is! Also, the table at the end of the file is unknown.}}

__TOC__

== Header ==

The ANCS format is split up into multiple nodes. Each node defines a character - a model, a skeleton, and a skin - and then sets a number of animation-related parameters on each one. At the end of the file, after every node, is a listing of [[ANIM (File Format)|ANIM]] and [[EVNT (File Format)|EVNT]] files.

There's a very short 8-byte header before the nodes begin.

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 2
| {{unknown|'''Unknown'''; always 1}}
|-
| 0x2
| 2
| {{unknown|'''Unknown'''; always 1 (maybe actually one 32-bit magic?)}}
|-
| 0x4
| 4
| '''Node count'''
|-
| 0x8
| colspan=2 {{unknown|Nodes begin}}
|}

== Nodes ==

{| class="wikitable"
! Type
! Count
! Description
|-
| u32
| 1
| '''Node number'''; starts at 0, increases by 1 on each subsequent node
|-
| u16
| 1
| {{unknown|Flags? This value can alter the structure of the file. Usually 6.}}
|-
| string
| 1
| '''Node name''' (zero-terminated)
|-
| [[CMDL (Metroid Prime)|CMDL]]
| 1
| '''Model'''
|-
| [[CSKR (File Format)|CSKR]]
| 1
| '''Skin'''
|-
| [[CINF (File Format)|CINF]]
| 1
| '''Skeleton'''
|-
| u32
| 1
| '''Animation count'''
|}

This struct then repeats ''animation count'' times:

{| class="wikitable"
! Type
! Count
! Description
|-
| u32
| 1
| '''Animation number'''; starts with 0, increases by 1 on each subsequent animation
|-
| u8
| 1
| {{unknown|'''Unknown'''; usually 0}}
|-
| string
| 1
| '''Animation name''' (zero-terminated)
|}

=== PAS Database ===

The next part of the file is the PAS Database, which creates animation states and sets parameters on them. The PAS Database header is structured:

{| class="wikitable"
! Offset
! Size
! Description
|-
| 0x0
| 4
| '''"PAS4" magic''' fourCC
|-
| 0x4
| 4
| '''Anim state count'''
|-
| 0x8
| 4
| '''Default state''' (will be 0xFFFFFFFF on files with no anim states)
|}

==== Anim State ====

{| class="wikitable"
! Type
! Count
! Description
|-
| u32
| 1
| {{unknown|'''Unknown'''}}
|-
| u32
| 1
| '''Parm Info count''' (PC)
|-
| u32
| 1
| '''Anim Info count''' (AC)
|-
| [[#Parm Info|Parm Info]]
| PC
| '''Parm Info'''
|-
| [[#Anim Info|Anim Info]]
| AC
| '''Anim Info'''
|}

===== Parm Info =====

{| class="wikitable"
! Type
! Count
! Description
|-
| u32
| 1
| '''Parm Type'''; enum ranging from 0 to 4, see below for possible values
|-
| u32
| 1
| {{unknown|'''Unknown'''}}
|-
| float
| 1
| {{unknown|'''Unknown'''}}
|-
| ParmType
| 2
| '''Parms'''
|}

These are the possible types that can be specified by Parm Type:

{| class="wikitable"
! Value
! Size
! Type
|-
| 0
| 4
| s32
|-
| 1
| 4
| u32
|-
| 2
| 4
| float
|-
| 3
| 1
| bool
|-
| 4
| 4
| enum
|}

===== Anim Info =====

The Anim Info structure is a little unorthodox. It starts with an unknown 32-bit value, and then is followed by a set of values. There's one value present per Parm Info instance, and the type of each value corresponds to that Parm Info's Parm Type setting.

=== Particles ===

Note: if the flag value at the start of the node is 5 instead of 6, when of these values is missing. It's currently not known specifically which one it toggles, so be careful.

{| class="wikitable"
! Type
! Count
! Description
|-
| u32
| 1
| '''Particle count''' (PC)
|-
| [[PART (File Format)|PART]]
| PC
| '''Particle file IDs'''
|-
| u32
| 1
| '''Swoosh particle count''' (SC)
|-
| [[SWHC (File Format)|SWHC]]
| SC
| '''Swoosh particle file IDs'''
|-
| u32
| 1
| {{unknown|'''Unknown'''}}
|-
| u32
| 1
| '''Electric particle count''' (EC)
|-
| [[ELSC (File Format)|ELSC]]
| EC
| '''Electric particle file IDs'''
|-
| u32
| 1
| {{unknown|'''Unknown'''}}
|}

=== Animations ===

This section begins with a 32-bit count value, then this struct repeats:

{| class="wikitable"
! Type
! Count
! Description
|-
| string
| 1
| '''Animation name'''
|-
| float
| 6
| {{unknown|'''Unknown'''; possibly an AABB}}
|}

=== Effects ===

This section is used for effect placement - binding particles to bones, which is used for things like Space Pirate eye fire. It starts with a 32-bit count value, then this stuct repeats:

{| class="wikitable"
! Type
! Count
! Description
|-
| string
| 1
| '''Effect name'''
|-
| u32
| 1
| {{unknown|'''Unknown'''}}
|-
| string
| 1
| '''Effect name 2'''
|-
| char
| 4
| '''"PART" fourCC'''
|-
| [[PART (File Format)|PART]]
| 1
| '''Particle file ID'''
|-
| string
| 1
| '''Bone name'''
|-
| float
| 1
| {{unknown|'''Unknown'''}}
|-
| u32
| 1
| {{unknown|'''Unknown'''}}
|-
| u32
| 1
| {{unknown|'''Unknown'''}}
|}

=== Footer ===

The end of the node structure contains this data:

{| class="wikitable"
! Type
! Count
! Description
|-
| [[CMDL (Metroid Prime)|CMDL]]
| 1
| {{unknown|'''Unknown model'''}}
|-
| [[CSKR (Metroid Prime)|CSKR]]
| 1
| {{unknown|'''Unknown skin'''}}
|-
| u32
| 1
| {{unknown|'''Unknown count''' (UC)}}
|-
| u32
| UC
| {{unknown|'''Unknowns'''}}
|}

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]

SCAN (Metroid Prime 2)

2015-02-01T07:35:39Z

Embyr 75: {{research}}

{{research|3|Crack SNFO}}

The '''.SCAN file format''' describes SCAN POI data and has references to several resources. This variation of the format is completely different than its [[SCAN (Metroid Prime)|Metroid Prime]] counterpart.

__TOC__

=Header=
The header is rather simple and consists of the following:
{|class="wikitable"
!Offset
!Size
!Description
|-
|0x0
|4
|'''Magic''' FourCC
|-
|0x4
|4
|'''Version''' Always 2, no matter what game
|-
|0x8
|1
|{{unknown|Boolean?}}
|-
|0x9
|4
|{{unknown|Unknown}}
|}

=SNFO Chunk=
The SNFO header is simply a FourCC and the total length in bytes. Due to the fact that there is nothing in the header to determine which version of SCAN we're working with, we have to rely on the size of the SNFO chunk. If it's less than 0x0251 bytes, it's Metroid Prime 2. Otherwise it's Metroid Prime 3.

Other than that, SNFO is entirely unknown.

=Dependency List=
The dependency list follows the same format as [[DGRP (File Format)|DGRP]]
[[Category:File Formats]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]
[[Category:Major research needed]]

CRSC (File Format)

2015-02-01T07:35:02Z

Embyr 75: {{research}}

{{research|3|Nothing is known about this format yet.}}

The '''CRSC format''' is used for collision response data.

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]

ELSC (File Format)

2015-02-01T07:34:39Z

Embyr 75: {{research}}

{{research|3|There is nothing known about this format.}}

The '''ELSC format''' is used for electric particle data in the Prime series.

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]

DPSC (File Format)

2015-02-01T07:33:33Z

Embyr 75: {{research}}

{{research|3|Nothing is known about this format.}}

The '''DPSC format''' contains decal data. It hasn't been researched as of yet.

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]

Animation Events (File Format)

2015-02-01T07:32:50Z

Embyr 75: {{research}}

{{research|3|Basically everything.}}

The '''EVNT format''' is for animation POI data. Very little is known about it.

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]

ANIM (File Format)

2015-02-01T07:32:09Z

Embyr 75: {{research}}

{{research|3|Basically everything.}}

The '''ANIM format''' is for animations. There's very little known about this format, currently.

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]
[[Category:Donkey Kong Country Returns]]
[[Category:Donkey Kong Country: Tropical Freeze]]

PART (File Format)

2015-02-01T07:31:27Z

Embyr 75: {{research}}

{{research|3|We don't know anything about this format.}}

The '''PART format''' controls particles. The format is nearly entirely unknown.

[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime 2: Echoes]]
[[Category:Metroid Prime 3: Corruption]]
[[Category:Donkey Kong Country Returns]]

User talk:Aruki

2015-01-30T04:20:29Z

Embyr 75: /* Research Categories */

==Research Categories==
Hey Parax, do you want the Research categories to be narrow (ex: File Formats Needing Major Research) or broad (ex: Major Research Needed)? [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 20:39, 29 January 2015 (CST)
:Uhh, whatever they were before was good. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 21:32, 29 January 2015 (CST)

::Roger that. Let me know if you have any other templates you want designed or if you want me to implement anything else. [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 22:20, 29 January 2015 (CST)

Template:Research

2015-01-30T02:48:50Z

Embyr 75: It categorizes into three categories now

{{Box
|gradient1=cce8ff
|gradient2=64b8ff
|image={{#switch:{{{1|}}}|1|minor|Minor=File:Morphball render.png|2|moderate|Moderate=File:Morphball_wirerender.png|3|major|Major=File:Morphball_wire.png}}
|text={{#switch:{{{1|}}}|1|minor|Minor='''This file format is almost completely documented'''|2|moderate|Moderate='''This file format needs more research'''|3|major|Major='''This file format needs a lot of research'''}} {{{2|}}}
}}
<includeonly>{{#switch:{{{1|}}}|1|minor|Minor=[[Category:Minor Research Needed]]|2|moderate|Moderate=[[Category:Moderate Research Needed]]|3|major|Major=[[Category:Major Research Needed]]}}</includeonly>
<noinclude>

==Usage==
This template can be used to indicate the degree of research required on a file type or article and categorize it accordingly. Use the following code.

<nowiki>{{Research |</nowiki> ''Degree'' <nowiki>|</nowiki> ''Supplementary text'' <nowiki>}}</nowiki>

''Degree'': Three available options, designated by Minor, Moderate, or Major (or 1, 2, or 3). 
''Supplementary text'': Optional additional text to specify required research.

[[Category:Notice Templates]]
</noinclude>

User talk:Aruki

2015-01-30T02:40:00Z

Embyr 75: Created page with "==Research Categories== Hey Parax, do you want the Research categories to be narrow (ex: File Formats Needing Major Research) or broad (ex: Major Research Needed)? ~~~~"

Template talk:Filedone

2015-01-30T01:09:17Z

Embyr 75: Created page with "==Necessary?== Is this template really necessary? There are a lot of other ways to denote that a file type is documented; for example, by tagging a Category on the article, or..."

==Necessary?==
Is this template really necessary? There are a lot of other ways to denote that a file type is documented; for example, by tagging a Category on the article, or by creating a parameter in the infoboxes I'm assuming we'll eventually use that indicates whether the file type is fully documented or not. Having a notice template on every single page seems kind of unnecessary to me, which the proliferation of this template would eventually cause. Any thoughts? [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 19:09, 29 January 2015 (CST)

User:Embyr 75

2015-01-30T00:51:31Z

Embyr 75: Adding a link to my sandbox, just in case

A girl who knows nothing about modding but a lot about wikis. :3

Me on [http://www.metroidwiki.org/wiki/User:Embyr_75 Metroid Wiki]

* [[User:Embyr_75/Sandbox|Sandbox]]

Template talk:Research

2015-01-30T00:49:04Z

Embyr 75: Input please!!!!

User:Embyr 75/Sandbox

2015-01-30T00:45:01Z

Embyr 75: Looks like it works!

'''My Sandbox!'''

==Research Template Text==
{{Research|1|Here's why}}
{{Research|2|Here's why}}
{{Research|3|Here's why}}

Template:Research

2015-01-30T00:43:07Z

Embyr 75: This template replaces the three existing Research templates (assuming I did it correctly...)

{{Box
|gradient1=cce8ff
|gradient2=64b8ff
|image={{#switch:{{{1|}}}|1|minor|Minor=File:Morphball render.png|2|moderate|Moderate=File:Morphball_wirerender.png|3|major|Major=File:Morphball_wire.png}}
|text={{#switch:{{{1|}}}|1|minor|Minor='''This file format is almost completely documented'''|2|moderate|Moderate='''This file format needs more research'''|3|major|Major='''This file format needs a lot of research'''}} {{{2|}}}
}}

<includeonly>[[Category:Research needed]]</includeonly>

<noinclude>
==Usage==
This template can be used to indicate the degree of research required on a file type or article. Use the following code.

<nowiki>{{Research |</nowiki> ''Degree'' <nowiki>|</nowiki> ''Supplementary text'' <nowiki>}}</nowiki>

''Degree'': Three available options, designated by Minor, Moderate, or Major (or 1, 2, or 3). 
''Supplementary text'': Optional additional text to specify required research.

[[Category:Notice Templates]]
</noinclude>

Template:Filepartial

2015-01-30T00:17:35Z

Embyr 75:

<includeonly>{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball_model.png|50px|link=]]
|'''This file format is partially documented''' This file format may have some functionality but is still not completely understood and still needs further research.
|}</includeonly>

<noinclude>
{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball_model.png|50px|link=]]
|'''This file format is partially documented''' This file format may have some functionality but is still not completely understood and still needs further research.
|}

==Usage==
If the file format is only partially understood or some parts of the file work and other parts don't, use this notice to denote it.

[[Category:Notice Templates]]
</noinclude>
<includeonly>[[Category:Partially Documented File Formats]]</includeonly>

Template:Filedone

2015-01-30T00:17:13Z

Embyr 75:

<includeonly>{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball render.png|50px|link=]]
|'''This file format has been completely documented''' This file format is now completely understood and no further research is needed.
|}</includeonly>

<noinclude>
{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball render.png|50px|link=]]
|'''This file format has been completely documented''' This file format is now completely understood and no further research is needed.
|}

==Usage==
Once a file format is completely documented, use this notice to denote it.

[[Category:Notice Templates]]
</noinclude>
<includeonly>[[Category:Documented File Formats]]</includeonly>

Template:Box

2015-01-30T00:15:39Z

Embyr 75: +Category

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#{{{gradient1|}}}, #{{{gradient2|}}}); /* Standard syntax */" ! width="55%"
| width="10%" |{{#if:{{{image|}}}|[[{{{image}}}|x50px|link=]]}}
|{{{text|}}}
|}

<noinclude>
===Usage===
This is a basic template which can be modified to create a variety of simple [[:Category:Notice Templates|Notice Templates]]. In most cases, it should be used in lieu of wikitext for uniformity.

<pre>
{{Box
|gradient1=
|gradient2=
|image=
|text=
}}
</pre>

''gradient1:'' Starting color for the gradient background. Should be hexadecimal. 
''gradient2:'' Ending color for the gradient background. Should be hexadecimal. 
''image:'' Filepath for the image, ex: File:ImageName.png 
''text:'' Text to be displayed.

[[Category:Notice Templates]]
</noinclude>

Template:Todo

2015-01-30T00:13:48Z

Embyr 75: Implemented {{Box}}. Seems to work! Imported the colors and icon from the discussion page.

{{Box
|gradient1=eb752f
|gradient2=ffd78a
|image=file:VariaSuitIcon.png
|text='''To do:''' {{{1}}}
}}

<noinclude>

==Usage==
This template can be used to generate a to-do list for an article. Use the following code.

<nowiki>{{Todo|</nowiki> ''list of items'' <nowiki>}}</nowiki>

[[Category:Notice Templates]]
</noinclude>

Template:Box

2015-01-30T00:08:25Z

Embyr 75: Let's give this a whirl

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#{{{gradient1|}}}, #{{{gradient2|}}}); /* Standard syntax */" ! width="55%"
| width="10%" |{{#if:{{{image|}}}|[[{{{image}}}|x50px|link=]]}}
|{{{text|}}}
|}

<noinclude>
===Usage===
This is a basic template which can be modified to create a variety of simple [[:Category:Notice Templates|Notice Templates]].

<pre>
{{Box
|gradient1=
|gradient2=
|image=
|text=
}}
</pre>

''gradient1:'' Starting color for the gradient background. Should be hexadecimal. 
''gradient2:'' Ending color for the gradient background. Should be hexadecimal. 
''image:'' Filepath for the image, ex: File:ImageName.png 
''text:'' Text to be displayed.
</noinclude>

User talk:Bearborg

2015-01-27T23:29:34Z

Embyr 75: /* Breaking Tables with Style Transclusions */

==Breaking Tables with Style Transclusions==
Hey Bearborg, I was wondering if you could take a look at [[:Template:RMWBorder]]. It's just a string of numbers (a hex color code), but whenever I try to use it in a style tag my tables explode ([[User:Embyr_75/Sandbox|example]]). It's an extremely simple template so I don't get what would cause it to do that. Same thing happens with [[:Template:Border]]. Could it be a MediaWiki issue? I need a fresh set of eyes (or just a better brain); care to take a look? [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 22:41, 26 January 2015 (CST)

:Well, I did take a look, but I don't think I can really help much- I'm not too proficient with wiki markup, and it all looks to me like it should work. [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 13:28, 27 January 2015 (CST)

::I know, right? It's a pain because if ''that'' template isn't working, then inclusions in a universal template might break too, and now I'm second guessing everything I do. Hmm. =P Oh well, thanks for looking. [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 17:29, 27 January 2015 (CST)

User talk:Bearborg

2015-01-27T04:41:54Z

Embyr 75: Created page with "==Breaking Tables with Style Transclusions== Hey Bearborg, I was wondering if you could take a look at :Template:RMWBorder. It's just a string of numbers (a hex color code..."

User:Embyr 75/Sandbox

2015-01-27T04:36:43Z

Embyr 75: Think we got a handle on the Notice Templates. If anyone needs to refer to that code again, the revision is in the history.

'''My Sandbox!'''

==Universal Box==



{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #{{RMWBorder}}; background: linear-gradient(#{{{gradient1|}}}, #{{{gradient2|}}}); /* Standard syntax */" ! width="55%"
| width="10%" |{{#if:{{{image|}}}|[[{{{image}}}|x50px|link=]]}}
|{{{text|}}}
|}

<noinclude>
===Usage===
This is a basic template which can be modified to create a variety of simple [[:Category:Notice Templates|Notice Templates]].

<pre>
{{Box
|gradient1=
|gradient2=
|image=
|text=
}}
</pre>

''gradient1:'' Starting color for the gradient background. Should be hexadecimal. 
''gradient2:'' Ending color for the gradient background. Should be hexadecimal. 
''image:'' Filepath for the image, ex: File:ImageName.png 
''text:'' Text to be displayed.
</noinclude>

User:Embyr 75/Sandbox

2015-01-26T08:39:52Z

Embyr 75:

'''My Sandbox!'''

==Notice Templates==

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7" ! width="55%"
|[[file:RetroModding.png|100px|link=]]
|'''To do:''' Current template colors. (Alignment drifts)
|}

{| cellpadding="5" cellspacing="3" style="border:2px solid #446fa7;" align="center" width="55%"
| width="20%"|[[file:RetroModding.png|100px|link=]]
| '''To do:''' Current template colors. (Fixed alignment, 20%/80%)
|}

{| cellpadding="5" cellspacing="3" style="border:2px solid #446fa7;" align="center" width="55%"
| width="10%"|[[file:RetroModding.png|100px|link=]]
| '''To do:''' Current template colors. (Fixed alignment, 10%/90%)
|}

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background-color:#ffc8c8" ! width="55%"
|[[file:RetroModding.png|100px|link=]]
|'''To do:''' This template has background color #ffc8c8, as requested.
|}

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background-color: #b9e9ff" ! width="55%"
|[[file:RetroModding.png|100px|link=]]
|'''To do:''' Color #b9e9ff, as requested.
|}

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background-color:#ffc8c8" ! width="55%"
| width="5%" |[[file:VariaSuitIcon.png|50px|link=]]
|'''To do:''' Red with Varia Suit icon.
|}

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background-color: #b9e9ff" ! width="55%"
| width="5%" |[[file:GravitySuitIcon.png|50px|link=]]
|'''To do:''' Blue with Gravity Suit icon.
|}

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background-color: #d2d2ff;" ! width="55%"
| width="5%" |[[file:GravitySuitIcon.png|50px|link=]]
|'''To do:''' More purplish to match the icon better.
|}

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#d2d2ff, #FFFFFF); /* Standard syntax */" ! width="55%"
| width="5%" |[[file:GravitySuitIcon.png|50px|link=]]
|'''To do:''' Gradient sweeping down to white.
|}

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(red, #FFFFFF); /* Standard syntax */" ! width="55%"
| width="5%" |[[file:GravitySuitIcon.png|50px|link=]]
|'''To do:''' SO VERY VERY RED.
|}

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#FFFFFF, #d2d2ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[file:GravitySuitIcon.png|50px|link=]]
|'''To do:''' Sweeping up to white.
|}

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#FFFFFF, #a067d6); /* Standard syntax */" ! width="55%"
| width="5%" |[[file:GravitySuitIcon.png|50px|link=]]
|'''To do:''' This color was pulled directly from a pixel on the icon. Could probably even go a shade lighter?
|}

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#FFFFFF, #9c72ca); /* Standard syntax */" ! width="55%"
| width="5%" |[[file:GravitySuitIcon.png|50px|link=]]
|'''To do:''' Lighter shade, pulled from pixel on icon.
|}

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#d2d2ff, #9c72ca); /* Standard syntax */" ! width="55%"
| width="5%" |[[file:GravitySuitIcon.png|50px|link=]]
|'''To do:''' Light purple to lighter purple.
|}

==Universal Box==



{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#{{{gradient1|}}}, #{{{gradient2|}}}); /* Standard syntax */" ! width="55%"
| width="10%" |{{#if:{{{image|}}}|[[{{{image}}}|x50px|link=]]}}
|{{{text|}}}
|}

<noinclude>
===Usage===
This is a basic template which can be modified to create a variety of simple [[:Category:Notice Templates|Notice Templates]].

<pre>
{{Box
|gradient1=
|gradient2=
|image=
|text=
}}
</pre>

''gradient1:'' Starting color for the gradient background. Should be hexadecimal. 
''gradient2:'' Ending color for the gradient background. Should be hexadecimal. 
''image:'' Filepath for the image, ex: File:ImageName.png 
''text:'' Text to be displayed.
</noinclude>

User talk:Embyr 75/Sandbox

2015-01-26T08:23:11Z

Embyr 75:

==Gradient Colors==
Adding gradient colors for backgrounds for these templates, hope to eventually make a universal "box" template that can be used to create new Notice Templates, with the gradient-color-functionality built in. Colors can be chosen and changed later, more concerned with if people like the gradient function right now. We could probably discuss the progression here, so others can input their opinions. [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 12:37, 25 January 2015 (CST)

: To have it out in the open, my two cents are mainly that I like the light colors, and the gradient is nice but I'm split on whether I prefer the flat color or the gradient; gradient's definitely nice but I like the simplicity and uniformity of the flat colors. Interested to hear other peoples' input. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 12:46, 25 January 2015 (CST)

: Personally, I prefer the gradients. Sweeping up to white looks particularly good, but if you want something more eyecatching, maybe go from one shade of purple to another? IMO, going straight from purple to white looks a little weird. [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 12:55, 25 January 2015 (CST)

::I also prefer the gradients, and sweeping up to white. The colors are flexible, I just think they should match the icon for each template. I don't mind the purple pixels I pulled but I also see the appeal of the lighter, more subtle colors. [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 13:10, 25 January 2015 (CST)

::I kinda agree with purple to white being a little weird. I'd be curious to see what a purple-to-purple gradient might look like. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 13:19, 25 January 2015 (CST)

:::Kinda meh on the purple to purple one. The darker purple doesn't really work IMO, especially since it starts to clash with the black text. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 14:36, 25 January 2015 (CST)

::::Maybe something like this? [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 14:44, 25 January 2015 (CST)
{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#f5e0fc, #c68cd9); /* Standard syntax */" ! width="55%"
| width="5%" |[[file:GravitySuitIcon.png|50px|link=]]
|'''To do:''' Light purple to lighter purple.
|}

:::::Definitely like the lighter to darker purple gradient more than the purple to white. I made some morphball images that I thought would work great for noticed that pertain to showing the file format progress. For example:

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball_wire.png|50px|link=]]
|'''This file format is not documented''' This file format has either no or very little documentation. More research is needed.
|}
 
{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball_model.png|50px|link=]]
|'''This file format is partially documented''' This file format may have some functionality but is still not completely understood and still needs further research.
|}
 
{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball render.png|50px|link=]]
|'''This file format has been completely documented''' This file format has been completely understood and no further research is needed.
|}

:::::Note how the ball goes from wireframe, to untextured, to fully rendered, to denote the progress of the file. Hope you guys like it! --[[User:MrSinistar|MrSinistar]] ([[User talk:MrSinistar|talk]]) 15:06, 25 January 2015 (CST)

::::::Oh wow, those look excellent. I'd definitely support implementing them ASAP. [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 15:09, 25 January 2015 (CST)

:::::::Ooh that's actually a really neat concept. I like it. Also liking the gradients a lot. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 15:11, 25 January 2015 (CST)

:::::::The only issue I have with the purple gradient is I feel like once it starts getting to be darker it starts clashing with the black text a little bit. It's still completely readable, but makes me feel like even that shade of purple is just a bit too dark.

:::::::I wonder if we could expand on MrSinistar's idea with the morph ball a little to display smaller versions of that on the category pages. That way someone could go take a look at the Metroid Prime category, for instance, and quickly see the status for every format right from the category page. --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 15:15, 25 January 2015 (CST)

::::::::Thanks everyone! I'll go and make the templates for the file formats notices, if that's cool with everyone. As for the purple gradient, how about inverting it like this?

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#c68cd9, #f5e0fc); /* Standard syntax */" ! width="55%"
| width="5%" |[[file:GravitySuitIcon.png|50px|link=]]
|'''To do:''' Light purple to lighter purple.
|}

::::::::I'll look into see if we can add small icons like that to the article names in the categories. Just to make sure we're on the same page, something like this?

[[File:Forum_idea.png|center]]

::::::::If so, I think that requires a fair amount of CSS and extra programming. But I think it's doable. --[[User:MrSinistar|MrSinistar]] ([[User talk:MrSinistar|talk]]) 15:26, 25 January 2015 (CST)

:::::::::I was thinking of having it before the link instead of after, but yeah, basically that. Also, I think I like sweeping down to the darker color better. Go ahead and implement the templates, would like to start sticking these on some pages. I think embyr was going to make a universal box template for this kind of thing though, and I'm not sure if she's done with that, so we might need to remake it later? --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 15:30, 25 January 2015 (CST)

::::::::::Hey MrSinistar, I think it'd be nice to have one or two more intermediate notices. Can you think of what could be used as icons for that? Maybe vertices? Like in the pak format, for example, the structure is 100% known; it's just file ordering that needs a slight bit more research. But it's small enough that I don't think it's really accurate to say we only have a partial understanding of it. Also, I don't think we should ever really say no more research is needed. No matter how much we know about a given format, there's always the chance that there's something we missed about it. Also also, I'd kind of like to try changing the names of the templates if that's alright with you :P --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 15:48, 25 January 2015 (CST)

::::::::::Actually come to think of it, that's not the only thing - it'd be helpful to write directly into the message box what specifically needs research. That doesn't really mesh with the icon idea, though. Any idea how we could do that? --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 15:50, 25 January 2015 (CST)

:::::::::The CSS side of that would actually be pretty simple, I've [http://i.imgur.com/nKm5btY.png already written it]. The hard part would be the code that determines which image to show. Maybe Parax or someone who knows more than me could implement custom CSS classes for the file progress? [[User:Bearborg|Bearborg]] ([[User talk:Bearborg|talk]]) 15:51, 25 January 2015 (CST)

:::::::::::Perhaps a div class that denotes what status the progress is on the article? I swear I've seen other wikis do this before. I added two new images:
[[File:Morph wiremodel.png|center|150px]]
[[File:Morph modelrender.png|center|150px]]
:::::::::::Also, I'm MrSinistar64 on skype, if you want to add me. I keep typing stuff and it gets deleted whenever the talk page is updated, ROFL. --[[User:MrSinistar|MrSinistar]] ([[User talk:MrSinistar|talk]]) 16:01, 25 January 2015 (CST)

'''Ok guys whoa whoa whoa!!''' I opened this talk page up for some discussion on the ''gradient colors'' but this is still my personal sandbox, not the discussion center!! Please keep conversations relevant to this project page. <s>And resize your images...</s>

I'm still working on the universal box, you can go ahead and make the templates and I'll rewrite them with the universal code later. However, there isn't a need to create a new template for each of those; just a template that has toggles for the level of research that will swap out the images for you. Also, LOVE the purples you chose Bearborg. I personally like the sweep down (dark top to light bottom) only because it makes the black text easier to read.

Also, templates shouldn't be categorized under "templates," because there will likely be hundreds of templates eventually. I'll create a category tree for templates too. [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 18:03, 25 January 2015 (CST)

:It is kinda relevant though. It's your personal sandbox, but you opened it up to discussion on a wiki-wide issue. We were discussing what the templates should look like, weren't we? So if we're talking about it here and someone has another idea, it makes sense to put it here; there isn't any discussion about it happening anywhere else. We could maybe move this discussion over to another page if you'd like.

:In any case it seems like it's mostly done now. Only question is what colors/icon are we going to use for the todo template? --[[User:Parax0|Parax0]] ([[User talk:Parax0|talk]]) 19:46, 25 January 2015 (CST)

::Er, I guess I was ambiguous. My objection isn't that this is MY page and how DARE you discuss things on MY page. =P What I'm saying is: this is ''just'' my personal sandbox. It's an unimportant page that's subject to change completely based solely on my whim and isn't a great place to have larger discussions for wiki-wide implementation. A discussion center, preferably one with a link on the sidebar, would probably be a better situation. This discussion has way outgrown a userpage talkpage and needs to be in a central location that's more easily accessible (and easier to archive). [[User:Embyr 75|Embyr 75]] ([[User talk:Embyr 75|talk]]) 02:23, 26 January 2015 (CST)

User:Embyr 75/Sandbox

2015-01-26T00:24:27Z

Embyr 75: /* Universal Box */ Pretty basic

Template:Researchmoderate

2015-01-26T00:08:26Z

Embyr 75: changing cat

<includeonly>{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball_wirerender.png|50px|link=]]
|'''This file format needs more research''' {{{reason|}}}
|}
</includeonly>
<noinclude>

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball_wirerender.png|50px|link=]]
|'''This file format needs more research''' {{{reason|}}}
|}

==Usage==
Copy and paste the following into the article and fill in the fields.
<pre>

{{researchmoderate
|reason=
}}
</pre>

[[Category:Notice Templates|{{PAGENAME}}]]
</noinclude>
<includeonly>[[Category:File Formats needing Research]]
[[Category:Moderate research needed]]</includeonly>

Template:Researchminor

2015-01-26T00:08:10Z

Embyr 75: changing cat

<includeonly>{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball render.png|50px|link=]]
|'''This file format is almost completely documented''' {{{reason|}}}
|}
</includeonly>
<noinclude>

{| cellpadding="5" cellspacing="3" align="center" style="border:2px solid #446fa7; background: linear-gradient(#cce8ff, #64b8ff); /* Standard syntax */" ! width="55%"
| width="5%" |[[File:Morphball render.png|50px|link=]]
|'''This file format is almost completely documented''' {{{reason|}}}
|}

==Usage==
Copy and paste the following into the article and fill in the fields.
<pre>

{{researchminor
|reason=
}}
</pre>

[[Category:Notice Templates|{{PAGENAME}}]]
</noinclude>
<includeonly>[[Category:File Formats needing Research]]
[[Category:Minor research needed]]</includeonly>

Category:Formatting Templates

2015-01-26T00:07:38Z

Embyr 75: +root

Formatting templates belong in this category.

[[Category:Templates]]