Sample Game 1 PAK: Difference between revisions
Jump to navigation
Jump to search
imported>Dinoguy1000 No edit summary |
imported>Dinoguy1000 No edit summary |
||
| Line 21: | Line 21: | ||
=== Format Specifications === | === Format Specifications === | ||
{{GRAFPageFormat|1=char {15} - Header {{ | {{GRAFPageFormat|1=char {15} - Header {{Constant|(Sample Game PAK)}}<br> | ||
byte {1} - null Padding<br> | byte {1} - null Padding<br> | ||
| Line 29: | Line 29: | ||
:byte {x} - File data}}<!-- | :byte {x} - File data}}<!-- | ||
Note that when you use the {{GRAFPageFormat}} template, if you use any other templates within it, such as {{InlineComment}} or {{Unknown}}, you need to place a 1= right after the pipe character (|). For instance, {{GRAFPageFormat|{{BlockDescription|This is a block description}}}} will display as '''None written yet'''. However, {{GRAFPageFormat|1={{BlockDescription|This is a block description}}}} will display as '''This is a block description''', in blue text. | Note that when you use the {{GRAFPageFormat}} template, if you use any other templates within it, such as {{InlineComment}} or {{Unknown}}, you need to place a 1= right after the pipe character (|). For instance, {{GRAFPageFormat|{{BlockDescription|This is a block description}}}} will display as '''None written yet'''. However, {{GRAFPageFormat|1={{BlockDescription|This is a block description}}}} will display as '''This is a block description''', in blue text. If no other templates are used, the 1= is completely optional, but it should still be left in. | ||
Block section descriptions should use the {{BlockDescription}} template, like in the example above. | Block section descriptions should use the {{BlockDescription}} template, like in the example above. | ||
| Line 36: | Line 36: | ||
uint16 {2} for 2-byte-long unsigned integers | uint16 {2} for 2-byte-long unsigned integers | ||
uint32 {4} for 4-byte-long unsigned integers | uint32 {4} for 4-byte-long unsigned integers | ||
char {x} for character data | char {x} for x-byte-long character data | ||
byte {x} for hexadecimal data | byte {x} for x-byte-long hexadecimal data | ||
int16 {2} for 2-byte-long signed integers | int16 {2} for 2-byte-long signed integers | ||
int32 {4} for 4-byte-long signed integers | int32 {4} for 4-byte-long signed integers | ||
float {x} for x-byte-long floats | |||
char {1} or byte {1} should be used for any 1-byte-long fields, and if you need a tag for fields 3 bytes long, or 5 bytes or longer, you can use | char {1} or byte {1} should be used for any 1-byte-long fields, and if you need a tag for fields 3 bytes long, or 5 bytes or longer, you can use | ||
| Line 49: | Line 50: | ||
Literal strings, such as "Hello world" or "Wuzup?" should be purple and enclosed within parenthesis following the field description. E.g. | Literal strings, such as "Hello world" or "Wuzup?" should be purple and enclosed within parenthesis following the field description. E.g. | ||
{{ | {{Constant|("Hello world")}} Non-printable characters (NPC's), such as nulls, should be written as just the character's ASCII code in hexadecimal, e.g. 00 for a null. Nulls themselves can also be represented by the word "null". Multiple NPC's should be seperated from each other and any literal strings with spaces. For instance, | ||
{{ | {{Constant|("Hello world" 00 21)}} or | ||
{{ | {{Constant|("Hello world" null 21)}} | ||
Any short notes should be enclosed in parenthesis and use the InlineComment template after the field description, e.g. | Any short notes should be enclosed in parenthesis and use the InlineComment template after the field description, e.g. | ||
| Line 129: | Line 130: | ||
<!-- | <!-- | ||
Categories are used for... what do you know... categorizing WIKI pages. There are a number of categories used on the WIKI (somewhere around 50, IIRC), but by the time your page is finished, it will only have between 7 to 10 categories listed in most cases, and you will have to manually list even fewer. The categories you should worry about are those concerning how complete the Format Specifications are, those concerning a BMS script, those concerning what platform the game(s) using the format are for, and those concerning whether the format uses compression/encryption. | Categories are used for... what do you know... categorizing WIKI pages. There are a number of categories used on the WIKI (somewhere around 50, IIRC), but by the time your page is finished, it will only have between 7 to 10 categories listed in most cases, and you will have to manually list even fewer. The categories you should worry about are those concerning how complete the Format Specifications are, those concerning a BMS script, those concerning what platform the game(s) using the format are for, those concerning how widely used a format is, and those concerning whether the format uses compression/encryption. | ||
Keep in mind that all category tags should include the line {{subst:PAGENAME}} after the pipe character (|), e.g. | Keep in mind that all category tags should include the line {{subst:PAGENAME}} after the pipe character (|), e.g. | ||
| Line 135: | Line 136: | ||
[[Category:Cat Name Here|{{subst:PAGENAME}}]] | [[Category:Cat Name Here|{{subst:PAGENAME}}]] | ||
The specification completion categories are fairly straightforward to use. If most of a file's format is unknown (and chances are therefore good that it can't be supported by MexCom), one should use the category Complete WIP, indicating that the format is a work in progress. If the format is reasonably complete (few unknown values), you should use the category Complete Almost Done, and if the format is completely known, you should use Complete Complete. | The specification completion categories are fairly straightforward to use. If most of a file's format is unknown (and chances are therefore good that it can't be supported by MexCom yet), one should use the category Complete WIP, indicating that the format is a work in progress. If the format is reasonably complete (few unknown values), you should use the category Complete Almost Done, and if the format is completely known (no unknowns), you should use Complete Complete. | ||
As for BMS scripts, there are only three things you should worry about: if there's no BMS script for a given format, you should have used the template {{NoBMSScript}}, and the appropriate category is added automatically. Similarly, if a BMS script can't be used for a given format, because it's too complex, uses | As for BMS scripts, there are only three things you should worry about: if there's no BMS script for a given format, you should have used the template {{NoBMSScript}}, and the appropriate category is added automatically. Similarly, if a BMS script can't be used for a given format, because it's too complex, uses compression/encryption, wrong format type, etc., you should have used the template {{BMSNotApplicable}}, which also automatically adds the appropriate category. If you added a new script for a given format, you should add the category BMS New to the end of the page. Otherwise, don't worry about adjusting this category tag. | ||
Moving on to platforms a given format is used on, in general, category names take the form of Platform *platform name*, e.g. Platform PC or Platform PS2. A full list of appropriate categories follows: | Moving on to platforms a given format is used on, in general, category names take the form of Platform *platform name*, e.g. Platform PC or Platform PS2. A full list of appropriate categories follows: | ||
| Line 156: | Line 157: | ||
Finally, the categories for compression and encryption are quite simple. Most of the time, the format you're working on won't use compression or encryption, so you should use the category CE None. If it uses unknown compression/encryption, you'll want to use the category CE Unknown. If you know for sure that a given format uses compression, use the category CE Compressed, and similarly, CE Encrypted for encryption. If a format uses both compression and encryption, skip the individual CE Compressed/CE Encrypted categories and just use CE Both. | Finally, the categories for compression and encryption are quite simple. Most of the time, the format you're working on won't use compression or encryption, so you should use the category CE None. If it uses unknown compression/encryption, you'll want to use the category CE Unknown. If you know for sure that a given format uses compression, use the category CE Compressed, and similarly, CE Encrypted for encryption. If a format uses both compression and encryption, skip the individual CE Compressed/CE Encrypted categories and just use CE Both. | ||
After all of this, if you really want to dig deeper into the category system on the WIKI, start your explorations at Category:Categories. | |||
--> | --> | ||
Revision as of 21:58, 29 January 2007
Back to index | Edit this page
NOTE: This is only an example of a GRAF page. As far as I know, there is no game called "Sample Game 1", and no game uses the exact archive format given below.
PAK
- Format type: Archive
- Endianness: Little-endian
Format Specifications
char {15} - Header (Sample Game PAK)
byte {1} - null Padding
// For each file
- char {16} - File name (null padded)
- uint32 {4} - File size
- byte {x} - File data
Notes and Comments
None
MultiEx BMS Script
None written yet.
Supported by Programs
Unknown
Links
None