Sample Game 1 PAK: Difference between revisions
Jump to navigation
Jump to search
imported>Dinoguy1000 No edit summary |
imported>Dinoguy1000 No edit summary |
||
| 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|{{ | 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. | ||
Block section descriptions should | Block section descriptions should use the {{BlockDescription}} template, like in the example above. | ||
Field tags can be one of the following: | Field tags can be one of the following: | ||
| Line 40: | Line 40: | ||
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 | ||
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 {x} or something like uint48 {6}. If you use | |||
uintx {x} or intx {x}, note that the first number in the tag (the first x) is equal to the field's length * 8, so if a field is 4 bytes long, the first number would be 32. The second number (the second x) should be the field's actual length in bytes. Field tags themselves should be thirteen characters long from the beginning of the tag to the dash, inclusive, with multiple spaces using , as seen in the above example. | |||
Unknown values should use the {{Unknown}} template. If you have an educated guess for what an unknown value might be, you should use | |||
{{Unknown| '' Educated guess '' }}, where Educated guess is, of course, your educated guess. | |||
Any short notes should be enclosed in parenthesis and use the InlineComment template after the field description, e.g. {{InlineComment|(This is a comment)}}. Longer notes should go in the "Notes and Comments" section. | Literal strings, such as "Hello world" or "Wuzup?" should be purple and enclosed within parenthesis following the field description. E.g. | ||
{{Purple|("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, | |||
{{Purple|("Hello world" 00 21)}} or | |||
{{Purple|("Hello world" null 21)}} | |||
Any short notes should be enclosed in parenthesis and use the InlineComment template after the field description, e.g. | |||
{{InlineComment|(This is a comment)}}. Longer notes should go in the "Notes and Comments" section. | |||
--> | --> | ||
=== Notes and Comments === | === Notes and Comments === | ||
None | None | ||
<!-- | |||
You can create new section headings in this section, if necessary. If you do this, you should start with level four headings, e.g. | |||
==== This is a level four heading ==== | |||
and working farther in (with level five, etc. headings) if necessary. You can name these section headings whatever way suits you best, so long as they are somewhat descriptive of the notes in that section. | |||
--> | |||
=== MultiEx BMS Script === | === MultiEx BMS Script === | ||
| Line 117: | Line 131: | ||
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, 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. [[Category: | Keep in mind that all category tags should include the line {{subst:PAGENAME}} after the pipe character (|), e.g. | ||
[[Category:Cat Name Here|{{subst:PAGENAME}}]]. After a page is saved, the WIKI automatically replaces this line with the page's name. In general, category tags should take the form | |||
[[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), 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. | ||
As for BMS scripts, there are only | 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 compressioon/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 the 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 137: | Line 153: | ||
When adding platform categories, just use all of them that apply. For instance, if a format I was working on was used on the PC and the Gamecube, I would use the categories Platform PC and Platform Gamecube. | When adding platform categories, just use all of them that apply. For instance, if a format I was working on was used on the PC and the Gamecube, I would use the categories Platform PC and Platform Gamecube. | ||
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 | Next to last, these categories depend on the number of games known to use a given format. If a format is used by between four and twenty games, you should use the category Format Common. However, if a format is used by more than twenty games, or if it enjoys widespread use outside of the game development community, you should use the category Format Standard. Formats used by fewer than four games shouldn't be worried about. | ||
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. | |||
--> | --> | ||
Revision as of 19:01, 23 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